Darwin's Theories - Java category

Apple and OpenJDK

Thu, 24 Feb 2011 17:37:00 GMT

Lest anyone doubt Apple's committment to working with Oracle on the OpenJDK project, Apple just emailed me back on a bug that I filed against the Mac implementation of Java... way back... in... 2003?!? Yup. Apple BugID #3179542 has finally been closed, a just about eight years to the day after I filed it.

"Engineering believes that this issue has been resolved. Java 7 for Mac OS X as provided by Oracle will offer the directory structure that you seek."

I'd actually moved on from OS X on my desktop many of those years ago, and had utterly forgotten sending this report, but it's good to see them finally taking Java seriously, or at least making an effort.

JavaOne without Moscone Center?

Wed, 27 Jan 2010 16:50:00 GMT

After a very long and uncomfortable silence, Oracle, having passed the last(?) regulatory hurdle to their acquisition of Sun Microsystems, today announced that the JavaOne conference will in fact go ahead - this year. It will be co-located, but not merged, with Oracle OpenWorld; this year's dates are September 19-23 in San Francisco. That means there is still time for the refereed-paper approach that has been used in past JavaOnes. Partly since Moscone cannot hold all the attendees who would take part in both programs, and partly to reinforce the fact that it's not merged, JavaOne will be held in three hotels near Moscone (the huge keynotes will however be held in Moscone). I was heartened to hear Justin Kestylin of Oracle say that they want to "maintain the soul of JavaOne." We shall of course be watching to see how well they do at that.

JavaOne will also be going on the road: the "Sun Tech Days" program will be replaced by regional JavaOne conferences; the initial locations over the next year will be China, India, Russia and Brazil.

There is an FAQ coming within the next day on Oracle Developer Network. The following programs will be preserved: java.net, java.sun.com, Java Community Process, and others.

Watch otn.oracle.com for the FAQ - I'll update this with the link once it's available.

OpenMoko and Android

Tue, 21 Apr 2009 17:35:00 GMT

A few people have asked me at various times for a comparison of the OpenMoko and Android cell phone projects. Given that I advocate for the former, and also for Java which is (and is not) the base language of the latter, I am expected to be able to say something intelligible by way of comparison. So here goes.

Android is a project spearheaded by Google to make an open-source phone. It uses Linux and its own Dalvik virtual machine, and applications are written in Java against the Android API and compiled down to Dalvik bytecode. Android does not expose the rest of the Linux services and does not support other programming languages. Android phones are available from a few carriers.

Openmoko, funded by Openmoko.com, is at the other end of the spectrum: it also uses Linux, but exposes all of it to the developer. The "main" stack of phone apps has been re-written several times, using various X-based toolkits. The "official" OM2009 stack is in large part written in Python. C/C++, Java and Perl are all available. Openmoko phones are available from Openmoko.com. However, because it is all open source:

you can run Android on Openmoko hardware;
you could (people have) run Openmoko software on other devices, including Palm PDAs, other Linux phones, and software emulators;
you can probably run Openmoko software on Android hardware;
you can run QTopia on Openmoko hardware;
you can run one of half a dozen Linux distributions on your Openmoko hardware;
you can (eventually) run other OSes such as OpenBSD on Openmoko hardware;
etc.

From one point of view, they are not enemies. Both support the open source model. But as Openmoko developers have pointed out some time back, Android sits on top of Linux, abandoning most of the open source world and reinventing its own universe. Openmoko embraces all existing open source projects and any new open source comers. As a single example, communicating to your Openmoko phone from a desktop/laptop computer consists merly of running the industry-standard ssh and scp programs, included with every *Nix and readily available for those other OSes that need them. Talking to your Android phone requires finding, installing, and figuring out how to use an ad-hoc program called "adb" (at least the third use of this name, after Unix' Algol/Another DeBugger and Apple's Desktop Bus).

From another point of view, of course, they are competing. Competing for market share (neither has made much inroads in the consumer space). Competing for developer mindshare. Android tends to get a lot more press, partly because of the "big G" lineage.

People sometimes ask if I think Openmoko should just fold up and go on to something different, given how far ahead Android has moved? I've never been a fan of quitting while you're behind. Imagine if Linus Torvalds had quit while Unix was ahead; his then-little school project would never have seen the light of day, and we'd all be running BSD and System V. Nothing wrong with those - BSD was already on its way to becoming a full open source *Nix, as represented today by OpenBSD, FreeBSD and NetBSD - but things would be rather different in what is now the Linux community, to say the least. Or if Bill Gates had quit while IBM was ahead. Or if Steve Jobs had quit while MS-Windows was ahead. Or if the U.S. had quit the space race when the Russians launched Sputnik. You get the idea. Don't quit while you're behind, nor when you're ahead. As Nathaniel Branden once put it, "a beating heart is a living heart" - so keep on pumping!

And, at any rate, the "real" release of Openmoko software, OM.2009, is almost upon us; I am running a beta of it on my Freerunner (GTA02), and it's actually usable as a cell phone. Butt-ugly compared to some of the earlier releases, but it "just works". Formal release is expected this summer.

Microsoft Bites Me Again

Tue, 17 Mar 2009 20:37:00 GMT

I just created a Java application that is needed on several platforms, one of which, alas, is the ubituitous and ill-designed Microsoft Windows XP. In the project there are some classes that are auxilliary to the main program. Naturally enough I created a package for these called "aux". In Java a package name is also used as a directory name when the files are stored outside of archives, as they are during development. Hmmm. "aux". I know that Apple Computer long ago had a UNIX version called A/UX, but I didn't know anybody else had dibs on the name. But it seems Bill Gates was after Apple even back when MS-DOS was being cloned from CP/M-86. For it turns out that "aux" is a reserved filename, not just in MS-DOS, but even today in Windows XP (for all I know and don't care so please don't tell me, Vista too). It's because "aux:" is a device name, and the system is too scatterbrained to tell whether you mean that, or a file, if you just type "aux". The result is that WinZip was unable to restore all the files in this package; so I had to waste about half an hour adapting to this (including copying these files again, changing their package name, changing all the files that refer to them, making sure the changes made it back to my real OS (no extra points if you can guess which one it is) and get committed into my source repo so that I don't have to put up with this "hideous botch" ever again. Until next time we meet some screw loose in the M$ universe, that is.

Using Java enums properly in Seam

Tue, 27 Jan 2009 22:22:00 GMT

The Seam documentation covers this now, but it's a bit short of complete examples. Most of this probably applies to other JSF/JPA deployments too (but please don't ask me how). To make the list of a given enum's values available to the view, just add one new annotated method to a "Factories" class.

@Name("factories")
public class Factories {

@Factory("countries")
public Country[] getCountries() {
   return Country.values();
    }

Because you want to display a user-friendly name in the web form, but store a short and consistent name in the database, the enum must have a "label" or "name" field and a getter method (many enums already do). For example, we'll display Canada in the drop-down but enter the ISO-3166 country code CA in the database.

/** See ISO-3166 */
public enum Country {
   CA("Canada"),
   US("United States"),
   AF("Afghanistan"),
   ...
   ;
   private String longName;
   private Country(String longName) {
       this.longName = longName;
   }
   public String getLongName() {
       return longName;
   }
   @Override
   public String toString () {
       return getLongName();
   }

You typically want to save the string name rather than the ordinal value into the database (especially with Countries where the list order will change in future as countries split or join!) the @Entity class must be annotated thusly:

   @Column(name="Country")
   @Enumerated(EnumType.STRING)   // default and only other choice is ORDINAL
   public Country getCountry() {
       return this.country;
   }

Then, to select it (display a drop-down), you'd use, for example:

      <h:selectOneMenu value="#{register.personalAddress.country}">
             <s:selectItems var="country" value="#{countries}"
                        label="#{country.longName}" noSelectionLabel="-- Select --"/>
              <s:convertEnum/>
       </h:selectOneMenu>

If you've used another framework than Seam, there's a bit of Seam's beauty: the Seam convertEnum tag fixes the 'orrible mess of having your data classes be required to know about UIComponent (can nobody on the JSF standards committee spell "tier violation"?).

To display the current value in a view-only page, you just need, for example,

<h:outputText id="country"
      value="#{person.personalAddress.country.longName}"/ >

The data must be basically spotless for the enum converter to work, so - if you didn't have enumerating check constraints on the database from day one - you may e.g., have to "sanitize" the data a little to ensure there are no non-null but blank values in the database, or convert any lower-case values to upper case to match the enum constants. If not you'll get strange message like the famous "can't find resultList" - always check the JBoss console log for a stack trace!

These can be cleaned with SQL like this, using whatever tool you use to feed raw SQL into whatever database you're using:

   update address set country = 'CA' where country = ''
Or you could set these values to NULL.

   update address set country = upper(country)

To check the values, you can use SQL similar to this:

    select distinct(country) from address

Then it all works nicely, as it should, without any need for EntityConverter or for mixing UIComponents into your data layer. Seam rocks!