Category Archives: java

Standard

Posted by

Posted on

2008/10/28

Posted under

java

Comments

Leave a comment

Sun’s Java ME Marketing Blogs Going Off The Rails

Java ME has served me reasonably well as a platform to develop Hecl on over the years. It certainly has some problems, but it has two huge advantages: it’s everywhere, and it’s reasonably accessible, in that I can develop for it on Linux.

Lately, all the buzz has been about the iPhone, and Android, and this seems to be irritating the guys at Sun who are tasked with creating interest around Java ME. Some of what they’ve been putting out in response is pretty weak. Look at this:

http://blogs.sun.com/hinkmond/entry/google_phone_needs_work

Don’t they have better things to do than sitting around drawing dead Androids? Here are a few things that I can think of for them to be doing:

  • http://java.sun.com/javafx/downloads/ – No Linux version. This is supposed to be ‘the future’, but it all looks murky to me. What is it, exactly? Who will be running it? When can I get a phone?

  • Clarify what the deal with open source and Java is. I go here: http://www.sun.com/software/opensource/java/ and I see some stuff about open sourcing implementations, but it takes a lot of clicking to anything that looks like what I might actually want. I finally get to a phoneme thing, and that looks interesting, but kind of buried off in a corner.

  • Get out there and talk with developers. Google has several ‘developer advocates’ on Freenode’s #android irc channel, as well as various people involved in different aspects of the effort who drop by from time to time. #j2me is fairly quiet, and I’ve never seen hide nor hair of anyone from Sun.

  • Stop ragging on Android and iPhone. Be proud of what you’ve got, but realize that like everything out there, you can’t rest on your laurels. Talk about the cool things you’re doing, and spell it out clearly why I should be interested, or how it will make my life better.

  • Fix up your web sites. There are a ton of pages on Java ME and JFX and this that and the other thing. Make it clearer, simpler, more direct.

Here’s are a couple more “nyah nyah nyah” pieces. In this one he even quotes John “SCO has something on Linux” Dvorak:

http://blogs.sun.com/hinkmond/entry/stop_the_gphone_madness_says

http://blogs.sun.com/hinkmond/entry/i_love_google_because_google

They’re catching flack in the comments because of the attitude. The last post above is about how Google released a new Java ME version of their gmail application. Duh, of course they did; they want to make their stuff as widely available as possible, and no one disputes that Java ME is all over the place. But Sun can sit there and pat themselves on the back, or they can concentrate on what their vision of mobile programming for the future is. We know that Java ME is currently what’s out there, and widely deployed. Pointing that out with regards to what Google is shipping is pointless.

To be fair, there are plenty of posts are about interesting things they have going on, but there have been too many of these “mud slingers” about the competition, and it makes Sun look scared. Take the lead, show the stuff you’re working on, tell us when we can expect it, show us the source code, show us the vibrant community, tell us about the events. Also, admit your mistakes. Everyone makes them – the difference is in how you deal with them. Tell us how you’re going to improve stuff in the future so they won’t happen again.

Apple and Google have done some nice stuff with the iPhone and Android. If all Sun does is say nasty things about platforms that a lot of people are clearly interested in and like, it looks like they’re out of touch with reality. The reality is that Sun does have good tech and good people, but they need to do a more effective job with what they have, and push a more positive message about what they’re doing.

Standard

Posted by

Posted on

2008/10/07

Posted under

hecl, java

Comments

Leave a comment

Making Applets Suck Less

With all the effort being poured into Javascript lately, it’s pretty evident that that’s the way forward. However, there are still some neat things you can do with applets that you can’t do with Javascript. For instance, I use the microemulator applet to let people play with a simulated phone on the Hecl web site.

Unfortunately, the user experience hasn’t that good. While playing around with the code for that site, Firefox crashed a number of times, and I’ve heard other browsers have trouble as well. No fun.

So it is with some satisfaction that I found this:

https://jdk6.dev.java.net/plugin2/

It’s an updated Java plugin that seems to work much, much better than the old one. Unfortunately it doesn’t appear as if it will be in the new Ubuntu, as it was released recently, but I’m quite happy to have something a bit more stable to develop with.

You can download that version of the Java SDK or JRE here:

http://download.java.net/jdk6/

It’s good to see this effort, even if it may be a bit late.

Standard

Posted by

Posted on

2008/02/18

Posted under

android, java

Comments

Leave a comment

Looking under the Android hood

Here’s one way of having a look under the android hood:

mkdir /tmp/android/
cp .../android.jar /tmp/android
cd /tmp/android
unzip android.jar
... lots of files unzipped ...
for c in `find  android/ -name "*.class" | sed -e 's/.class//'`; do nice javap "$c" ; done > androidclasses.txt

That gives you a nice dump of all the classes available. It’s a useful way to get an idea of some of the under the hood capabilities of Android. Perhaps someone wiser in the ways of Java hacking can suggest even better ways of accomplishing the same thing.

Of course, anything that’s not officially documented is liable to change!

Standard

Posted by

Posted on

2007/12/05

Posted under

android, hecl, java

Comments

Leave a comment

Hecl Java Integration

Yesterday, I took the Java integration I’d been building into the Hecl Android port, and moved it into its own directory, so now it’s built in to the command line/j2se (non JavaME) version of Hecl for people to experiment with. Here’s a slightly modified version of my posting on the subject:

I created a java/ subdirectory with an org.hecl.java package that does a few things. The core of the system is in JavaCmd and Reflection. The first creates commands out of Java classes. It utilizes, obviously, the reflection stuff in Reflection. Both are, at the moment, sort of hacky and tentative, but work. For instance, I checked in this bit of test suite today:

test java-2 {
   java java.util.Hashtable ht
   set hasht [ht -new {}]
   $hasht put foo "bar"
   $hasht get foo
} {bar}

The ‘java’ command takes a class, and string, and creates a new Hecl command ‘ht’ that is tied to the Hashtable class.

ht -new {} (could have been -new [list]) is how we call the constructor. After this, $hasht points to a Hashtable, and we can utilize its methods. Up to a point, at least – there have to be mappings in Reflection to deal correctly with types. For instance, there isn’t a mapping for Enumeration right now, so calling the
.keys() method wouldn’t do the right thing.

There are some more bits and pieces of magic:

  • Static methods are called like this:

      java java.lang.System sys
  sys gc

    Which calls System.gc().

  • Static fields, for now, are called like this, although once again, I’m still thinking about the syntax:

      sys -field err

    Which is of course System.err

  • In addition to -new, when you instantiate an object, you can pass in things like -text "foo", and that will attempt to call setText("foo"). This is a convenient way, in Android, at least, of setting up an object from within Hecl, without requiring the use of the XML layout files.

  • Furthermore, in order to deal with constants in a convenient way, something that’s reasonably common in certain types of API’s (like Android), the following pieces of code are equivalent:

      layout.setOrientation(LinearLayout.VERTICAL);
  $layout setorientation VERTICAL

    What’s happening in the Hecl code is that VERTICAL is looked up in the context of the class that’s calling it, so as to avoid having to do [layout -field VERTICAL] to fetch the value. This won’t work everywhere, and I suppose it could be criticized as too much ‘magic’. Naturally, these sorts of things will evolve as the code does, and survive if they’re useful and don’t create problems, or die out if they cause bugs and aren’t utilized.

There are some open issues with the ongoing work:

  • I like the API for already instantiated objects, but I’m not 100% wedded to the idea of -new for instantiation. The fact that it takes a list is also a bit tricky, because if you want to do something like construct an argument to be passed in, you might end up with something like this:

      callback -new [list [list SelectDemo $spinner]]

    which I don’t find all that pleasant. You can’t just do -new [list
    SelectDemo $spinner]     because then it thinks it’s got two arguments,
    when it really only has one, which happens to be a list.

  • The APIs created like this tend to follow Java pretty closely, for obvious reasons, and can be a bit verbose at times. I’m still thinking about this. One idea might be to provide Hecl wrappers that make common operations easier.