Friday August 18, 2006
Open Source Java SE: Who gives a fig ?
Filed under: opensource
Who cares ? Five days after our announcement on Monday, I felt it was time to digest the reactions around the Java world to the news.
Missed opportunity for word playI was all geared up for a slew of press headlines marrying 'Sun' with some combination of 'rise', 'set', 'shine', 'burn', 'spot' or 'screen'. And, you know, a graphic of a sun cresting over a choppy sea full of joyous penguins or something.
But instead we've had a real treat of a large number of articles that mostly accurately represent the plan we announced on Monday. For example: CNET, Internetnews, eWeek, TecnNewsWorld, DevX, all with sober headlines.
(OK, one of them couldn't resist.)
You did ask...
Much of the complexity in Sun making this move is for us
to do so in a responsible manner with regard to to the other vendors
who have embraced Java technology. I imagine BEA will be pleased at
this latest news given their past
beseechings, and current 'blended
strategy' on Open Source (chirp...). A hasty reaction
from some folks from IBM
appears to have been mostly made facing
upwind, except for some free product feedback
they got. More helpfully, and critical to our getting this right, have been some very constructive assessments and advice from people like Geir, Dalibor and Tom who really know this stuff because they have or are working on open source implementations of Java SE already.
OK, but just don't break it for us
For me, the most interesting reactions have been those from Java developers. Perhaps in the long anticipation of this completion of opening up the development of the Java platform codebases, much of the heat and fire has been dissapated. So I have to say that the volume of debate in the fora that I have been following has not eclipsed other burning issues of the day. But the reactions appear to have been largely focussed on the mechanics of rolling out the
program, rather than on its merits. Though of course
there are some colorful
exceptions. Debates on the central issue of the choice
of licence appear as a popular
discussion point, though there does not appear to be a consensus.
My own suspicion as to why being that the consequences of the choice
are complex to divine. Law school anyone ? There have been a couple of sinister
theories that I probably won't lose any sleep about, and some misinformation
about Java EE [Update: That got corrected since I posted this]. And there I was, thinking everyone knew that our
implementation is already
open source. But I was happy to see that one of the potential
benefits that Java SE will go
where no Java SE has gone
before, is being discussed by others too.
Of course, what I suspect many developers feel on this topic is
indifference to mild concern: that they do not care how Java is made,
but just that
it's there
and that it
works. No surprise then that there are some
worries that it might not. We do well to keep them at the front of our minds.
Posted by dannycoward ( Aug 18 2006, 03:07:38 PM PDT ) Permalink Comments [2]
Monday August 14, 2006
Open Source: Cutting the Java SE apron strings
Filed under: opensource
Like any parent watching a child leave home for college, Sun appears to have had mixed feelings about the imminent (early 2007, to be precise) departure of its Java SE JDK
from its closed source home. Conceived in vitro, from baby steps in a new playground,
through child prodigy, with firm friendships,
and being no more trouble than some bullying at
school, Sun's prodigal child is at last standing in the doorway
ready to leave home. Just as the opinions of the Java Community
within Sun have been mixed, so have those in the wider Java Community,
although for many developers just trying to get their applications
written, they don't care
how Java is made so long as it works.
Of course some of the most recent steps in Java
SE's ten year progress into into the Wide Open World (with an eye to
its bigger sibling Java EE)
have done much to soften the blow to those who would keep it home
longer.
Much of the anxiety about open sourcing Java SE has been expressed has
been in terms of the risk of
loss of
compatibility. Which, for a technology with a complex
network of commercial and non-commercial entities depending on it,
that are able to interact as only effectively as the level of their
mutual
agreement of what it is, would be the worst outcome. Which argues for
perfecting this Matrix of
agreements. Yet keeping the screws too tight around the system could cause a slowing of innovation, and the
vital
ability of Java to flex and morph quickly enough in its ecosystem to remain relevant.
The film buffs amongst you doubtless know that any human/machine system needs some measure of chaos to remain viable, and that an overprotective mother can lead to a very unwelcoming motel.
Thankfully, Jonathan and Rich simplified our dilemma at JavaOne this year by announcing that yes we're doing it (at last). As one of
the many people at Sun working on the various and
several aspects of open sourcing Java SE, I'm telling you we're busy
packing the trunk and working through our To Do list, which we're pinning
to the front door for all the neighbors to see, to make sure the
strapping adult we have all helped in some way to grow gets the best
start possible.
For myself, I can't wait to see if completing this step of transparency of development process will produce something unexpected and delightful around or within the Java SE JDK. Just as making it easy to post video clips has created unexpected new stars in our consciousness.
If you want to watch us check off the items on our list over the next few months in the countdown to our release of a full buildable version early in 2007 of the JDK under an open source licence (nearly all, think swiss cheese), stick around here. Or better still bookmark the new Java SE Open Source site.
Oh, and can you guess which pieces we're going to open up before Christmas ? (hint: Hotspot and javac)
Posted by dannycoward ( Aug 14 2006, 05:32:58 PM PDT ) Permalink Comments [2]
Friday August 11, 2006
Validating Data Validation
Filed under: javase7
The rites of passage of a JSR are at times exhilarating and terrifying. Scary expert group rebellions, unending debates about API naming. The excitement of dozens of expert group applicants, the thrill of release of a public draft.
But did you know that the most important moments of a JSR are the three occasions it has to come before the venerable JCP Executive Committee for a vote ? Once at the start, once in the middle, and once at the end. This elected body, on which I serve (with, surprisingly, some of the nicest people), takes a vote to make sure a new JSR is not treading on the toes of anyone else's JSR, and that an existing JSR is doing what it said it would do. Many pass unscathed through these hoops of fire, some singe a little hair along the way. And occasionally EC members have even been known to forget to vote. But many a spec lead's heart skips a beat or three at the gruesome prospect of joining the charred remains of others less fortunate.
A fascinating new idea recently survived round one of this triplicate torture. One of those good ideas, one wonders, in the long lifetime of Java, that no-one had thought of making a standard API of before: a general purpose framework for Data Validation. One measure if its usefulness is the number of other technologies that could make good use of it. So when I asked around to find out who from within Sun would like to sign up for the expert group, expecting to have to twist a few arms and call in some embarrassing favors that I couldn't possibly talk about even with you, I was surprised that I had to beat them off with a stick.
From web applications
that need to check validity of the return date of your flight, to the persistence
layer double checking someone's age before it serves up a
byte-stream containing something unmentionable, to desktop
application verifying the format of the telephone number you
entered. Not forgetting the IDE that automagically attaches these
checks into any reasonably
formed component, this JSR offers the possibility of specifying and
enforcing these data validation checks easily, and hopefully in an
easily reuable way.This JSR I think will build on some great experience, and it looks like it will have a lively expert group. Good luck with the next rite of passage, Jason.
Posted by dannycoward ( Aug 11 2006, 12:33:36 PM PDT ) Permalink
Tuesday August 01, 2006
Reason #199 to Upgrade to Java SE 6
Filed under: javase6
One of the exciting things about working on the Java SE platform
is that what we do
to it affects not only the Java SE developers, but all the Java EE ones
too. That's obvious when we think about what language
changes to make, or what core libraries we might
add. But there are some APIs that enable better development
experiences and runtime attributes higher up the software stack. Even
when some
can't see it yet.Case in point being JSR 199 the JavaTM Compiler API which we're adding in Mustang. There may be some of you who want to use this in a J2SE application. But you are probably doing something fairly unusual. Its more likely that you are a J2EE developer who will notice a pleasurable and important side-effect up the stack.
The Glassfish folks can hardly believe how much faster it enables their JSP engine to be.
So reason #199 for you to upgrade (your web server) to Java SE 6 in October is the Java Compiler API.
Posted by dannycoward ( Aug 01 2006, 03:17:18 PM PDT ) Permalink Comments [4]
