1 2 3 Previous Next


186 posts

There appears to be over-reacting and fearism concerning a recent decision to cancel the DLJ project, and subsequently Ubuntu's plan to remove DLJ-based Java packages from their repository.  I'm totally out of the loop of this except for a couple things.  As the former DLJ Project Lead I was still vaguely involved with the management of that project, and recently there was an email exchange between myself, Dalibor and Tom where we decided it would be best to just shut down the DLJ because the OpenJDK had proceeded far enough that the DLJ was simply unnecessary.

Some blog postings on osnews.com and www.omgubuntu.co.uk came to my attention where there are many comments along the lines of "OMG THE SKY IS FALLING AND ORACLE IS EVIL".  Well, sigh. 

There's nothing to worry about here.  It's really very simple.

The DLJ Project was launched at JavaOne 2006 when it looked unlikely that Sun's Java implementation would ever be open sourced, we devised the DLJ Project to provide JDK bundles under a liberal license.  It was meant to help the community easily have a good quality Java implementation on Linux, but then the new CEO declared the creation of the OpenJDK project from the stage of that very same JavaOne.  

Over the course of time the OpenJDK project became really good and it was no longer necessary to maintain the DLJ project.

There's nothing EVIL here .. it's simply that the DLJ project became irrelevant.

Dalibor had a nice post about this a few months ago - http://robilad.livejournal.com/90792.html

Hey, it's been awhile since I last posted on this blog, largely because I didn't have much to say about Java for awhile, and partly because I've been working with Node.js over the last year.  It's a new software platform that I think the Java community needs to know about, and as the author of a book about Node (a.k.a. Node.js) I may be the person to explain a thing or two to y'all.  Since it's been so long since my last post here, a bit of re-introduction should be useful.  I'd spent 10 1/2 years working for Sun in the Java SE team, as an "architect" of the Software Quality Engineering team (SQE).  I was also someone who had some interesting ideas to share about Java (hence this blog).  Well, I hope they were interesting.  During that time, I was privileged to meet the FreeJava community (classpath, harmony, etc), participating in launching the OpenJDK project, the JDK-Distros project, the Mustang Regressions contest, and some other interesting projects.  It was an amazing time of meeting the broader Java community.  But 2.5 yrs ago things changed (ahem) and I stopped being active with Java and didn't want to post here because I wasn't sure I had anything to say.  Until now, when I feel a need to talk about Node.

Node (a.k.a. Node.js) is a new software development platform where the main talking points are:-

  • Server-side JavaScript executing on a fast JavaScript virtual machine (Chrome's V8)
  • Asynchronous execution model that's claimed to be light-weight and highly scalable
  • A no-threads mantra that synergistically works with the asynchronous model to make each connection low cost for high scalability
  • Excellent network I/O event handling event dispatching asynchronous runtime library that makes it amazing easy to develop succinctly implemented server software
  • Growing ecosystem of add-on modules and web frameworks and more
  • Excellent module system and package management system; cures dependency hell

Node's "hello world" is a 6 line script that also implements an HTTP web server.

var http = require('http');
http.createServer(function (req, res) {
  res.writeHead(200, {'Content-Type': 'text/plain'});
  res.end('Hello World\n');
}).listen(1337, "");
console.log('Server running at');

While most of the attention is on Node as a means to implement server applications, that's not all.  It's a general purpose programming platform akin to the Perl or Python or Tcl or Java model of use.  That is, you write your code and rather than compile it to object code it's run with an execution engine.  The Node execution engine is Chrome's V8 virtual machine wrapped with the layers that make Node what it is - namely the core runtime packages which come baked into the executable.

Okay, great.  What does that mean and how to contrast it with Java? 

One thing that leapt to mind early on was the old dream of the same language on both client and server side.  This dream perhaps dates back to the early days of Java, where Applets were to be how we'd implement dynamic stuff in a browser, and Servlets would be how we'd do it on the server.  The same language on both client and server could/should/would/maybe give us some goodness.  Who knows, but something in that dream failed along the way and we ended up with JavaScript in the browser and various languages on the server.  With Node we have a new chance for this dream to occur, but this time the language is JavaScript and in the browser JavaScript+DOM and asynchronous requests have given us some amazing web experiences.  Maybe we'll be able to write JavaScript code which could execute either in the browser or on the server depending on some conditions, or maybe not.  But having the same language at both sides should make it easier for different implementation teams to communicate and work closely together.

I think an area where Node can shine extremely well is in implementing the real time web.  Okay, sure, Twitter implemented their real time web with Ruby and Scala, but they started on that before Node existed.  I base my thinking in part on some 2006 blog posts that led to the COMET protocol, and in part the architectural choices in the Node platform. 

Those 2006 blog posts described problems with thread-based architectures when there are 10's of thousands of connections to a single web server.  Why that many?  Because the goal was for websites to be asynchronously popping messages onto screens and doing various other things which required holding a connection open to each web browser for a long time.  Think Facebook and their ability to tell you that so-and-so liked something you posted earlier, that's implemented with a long running connection over which messages are sent. 

In a thread-based system the overhead of one thread per connection means a server can't scale to very many connections, resource utilization is low and you're having to buy excess servers to get the job done, which cooks the planet because of too much electricity consumed to drive the Internet.  The 2006 COMET blog posts described a different asynchronous architecture that removes overhead implementing the real time web more efficiently for better resource utilization.  Okay, I hope I'm characterizing those posts correctly.

In any case those posts discuss implementing this in Java - Java's nio package lets you implement asynchronous I/O and Java is a powerful platform.  It begs the question, why do I think Node is great for the real time web, and why didn't Node's authors (especially Ryan Dahl) use Java as its foundation rather than JavaScript.

I don't know why Ryan Dahl didn't do Node with Java but instead used V8.  I did read all his blog posts and know he was really interested in high performance web service development along the lines of those COMET blog posts.  He was also hot on "no threads" because threads incur memory/CPU/complexity overhead.   What I can say is that JavaScript is highly suited to this task, in a way that Java is very clunky at.

What I mean is that closures (anonymous functions) come baked into JavaScript and are routinely used for event handling.  I don't know diddly about the technical definition of closures, but can say that anonymous functions are quite fun to use for writing what's essentially a Listener function.

In Java implementing an event handler is done by defining a Listener interface class, then importing that interface, implementing a subclass of the interface, and filling in one or more functions with your business logic.  Along the way you have to dot every i and cross every t with correct type signatures.  Isn't it tiring just listening to how this is done?

In JavaScript an event handler is as simple as "function(arg, list) { code .. }" .. no muss .. no fuss .. quite easy and fun.

It's possible to rathole down a discussion of dynamic typing versus rigid static typing ... I don't want to go there.  If you look in the back history of my blog posts on java.net I think you'll find me arguing the other side, that we have to have rigid static typing to help us steer clear of broken code.  I can say that this dynamic coding methodology is a heck of a lot of fun, and wish my former "rigid static typing" self would just get over it. 

Something that helps a lot is Node's excellent module system.  Modules themselves are pretty straight-forward.  The design was borrowed from CommonJS and implements a strong encapsulation around each module.  The code that's internal to a module simply cannot be reached from outside the module, and you export explicitly the functions you want to expose.

What makes it excellent is the algorithm for finding modules.  It's flexible enough that an application could have within its code tree several different versions of the same module, to allow fine grained dependency resolution.

Because HTTP is a built in core module it's amazingly simple to write REST-based server (or client) applications with Node.  The "req" and "res" objects shown in the hello world above abstract the HTTP protocol conversation.  All a service function does is fill in data in the res object, add data to the body, and that's it.  The HTTP object takes care of serializing the data down to the HTTP protocol for you.

In my book, Node Web Development, I was able to demonstrate in 6 pages refactoring a web application to move a heavy computation to a back end server using a REST service.  That 6 pages included a REST server, a small client application to test the back end server, and to refactor the application to use the REST server.  Six pages.  To me that demonstrates the power and flexibility of Node because of how easy it was to do all that.

This post has gotten a little long in the tooth, so I want to draw it to a close.  I hope y'all found it useful.  I've been working with Node for almost a year and the whole time in the back of my mind I was going on and on comparing back and forth between Java and Node and... Node is freeing JavaScript from being trapped in the browser, and letting it shine in a new place.  Yes, I know about the largely unknown history of server-side-javascript, but SSJS has had very little impact on computing and JavaScript has become synonymous with client side programming.  Node is the first serious outing of SSJS and it's a platform with great potential.  If you want to follow my adventure with Node head over to http://nodejs.davidherron.com and look for my book as well.


 Last week Apple released their latest product destined to change the world (the iPad).  At least that's what they want us to believe.  Perhaps the biggest controversy over the thing is the lack of Flash capability.  However this being java.net I have to wonder out loud, where is Java capability, and more importantly why isn't as much controversy being raised over Java being missing? But I think we all can enumerate some reasons for both being missing.  And it's worth it for the Java community to ponder this issue.

A couple weeks ago I attended a meeting of the Silicon Valley Web JUG (yes: Java User Group).  (The Future of the Web According to Dion Almaer and Ben Galbraith)  A very interesting meeting with a great overview of advances in HTML5 with an eye on the great possibilities it holds.

The interesting thing is they began the evening with a question:  How many of you are interested in JavaFX?  A meeting of 100+ geeks in Silicon Valley who are associated with a Java User Group, you'd think a few of them would be interested in JavaFX.  One person raised their hand.  I think that says a LOT.

Their presentation said a LOT about why Java and Flash both are missing from the iPad and iPod, and why we shouldn't care about that functionality gap, and indeed should feel liberated at their absence.

The key is web components built using standardized web technologies (a.k.a. The Open Web).  That's HTML, XML, HTTP, JavaScript and that ilk.  Flash, not being standardized by anybody, is not part of the Open Web.  Despite Java having a standards body behind it and being treated/delivered by Sun as an Open Standard, it was never accepted by the tech/web community as part of the Open Web.  And.. uh.. JavaFX.. sheesh, that's nowhere near being treated/delivered by Sun as any kind of Open Standard, instead it's being treated as a proprietary product where Sun is the big gorilla.  Oh, wait, that's Oracle now.  Sigh.  In any case the Open Web should most certainly ignore JavaFX just like it calls for Flash to be eschewed.

By being based on Open Standards the Open Web has tooling available from many organizations and a rich ecosystem of experience and adoption.  

An issue traditionally with HTML+JavaScript was speed.  Javascript has historically been an interpreted only language and anybody who tried Java 1.0 knows how glacial that can be.  Lately some Javascript implementations have been developing JIT and bytecode interpretation capabilities that eerily echo the development of Java virtual machines.  According to Ben Galbraith some of those teams are staffed with former Java VM developers.  In any case it means faster HTML+JavaScript execution with more capability to provide a rich GUI experience using just HTML+JavaScript.  (FWIW I'm typing this in Google's Chrome browser)

This ain't the HTML+JavaScript of yesteryear.  This is a brave new world.  It seems in retrospect the promise of Flash and Java was speedier UI experience than the HTML+JavaScript of yesteryear, and that if the HTML+JavaScript of the future is good enough, then both Flash and Java will be rendered irrelevant.  Yes, sure, of course both Adobe and Sun have over a decade of virtual machine implementation experience.  But neither can achieve the tight browser integration that JavaScript can.

HTML vs. Flash: Can a turf war be avoided? That's an interesting article covering the current stance where Adobe is saying "HEY WAIT A MINNIT" about the lack of Flash in the iPad.  e.g. "We are now on the verge of delivering Flash Player 10.1 for smartphones with all but one of the top manufacturers," Lynch said, specifically mentioning the Nexus One as one such device and adding that the software also works on tablets, Netbooks, and Net-enabled TVs. "Flash in the browser provides a competitive advantage to these devices because it will enable their customers to browse the whole Web...We are ready to enable Flash in the browser on these devices if and when Apple chooses to allow that for its users, but to date we have not had the required cooperation from Apple to make this happen."  I happen to know for certain that Sun could say the very same thing about Java on iPhone/iPod/iPad.  

Where is the truth between these possible states:-

  • The Web only has components standardized by standards bodies
  • All the tools and components are completely open source under OSI approved licenses
  • There is a mix of open standardized components, semi-open proprietary components and completely closed components (todays situation) 
  • Every web site has its own incompatible standard (the fate we fortunately avoided several years ago)




(tangential digression

Open Source != Open Standard.  For a long time the hue and cry was for Sun to Open Source Java, and that would ensue a brave new era of wonderful harmony across the planet or some such.  In practice Sun didn't quite open source Java, instead it created an Open Source project on a specific implementation of Java (OpenJDK) but "Java" (in my mind) was explicitly not open sourced.  As a result while the resulting situation was much better than before the wonderful era of harmony did not ensue.

In any case an Open Standard can be delivered by closed source software so long as it obeys the standard.  An Open Standard still allows wide use of the software and a huge amount of freedom in lots of practical forms of freedom.  But Open Standards don't allow things like forking that Open Source explicitly allows.  

I'm drawing on several threads of thinking in several presentations and conversations this week at JavaOne, and am thinking the Java Community Process (JCP) no longer serves the needs of the Java ecosystem.  I'm not the first to say this, not the last, but here's a few thoughts anyway. Sun (soon Oracle) is the owner and for the process to work out well the owner has to be enlightened enough to serve the needs of others as well as their own needs.  In reaping rewards from building an ecosystem requires having the wisdom that your benefit comes from everybody happily using your ecosystem, and always acting to nurture the ecosystem you've built.  Some styles of gardening (Permaculture) recognize this principle.  However administrations change and while one set of people overseeing Java might be enlightened the next set might be money grubbing short sighted opportunists.  I'm not pointing fingers at anybody, just outlining a general principle. The question is.. is it appropriate to have the foundational pieces of the Java ecosystem in the hands of one company?  Or is it better for those foundational pieces to be in the hands of a consortium whose purpose is the benefit of all? Open process - When Java was first developed in the mid 90's the open source software world was nowhere as mature as it is today.  In 1995 the open source software scene was very primitive even if some specific pieces of that scene were well developed and widely used.  The JCP was born in that environment and historically has served mostly big business and mostly acted behind closed doors and secrecy.  In todays world where the open source software scene is much more developed and accepted, is closed door secrecy of any use now?  Of course the JCP has been undergoing reforms, a good thing.  Also a language specification, VM specification, etc, those are not open source software, they are specifications.  The IETF is an example of a standards organization developing standards out in the open in a way I longingly remember from the early 90's when I was still an electronic mail expert. The JCP setup is tailored to the old model of iterating the Java platform.  There is a platform JSR to define the Java <n+1> and a passle of specific JSR's for each feature in Java n+1 are formed to steer those features through the design and development process.  This tied well with Sun's traditional 18 month or so development cycle of delivering a huge amount of change in 18-24 month cycles. Does that model still serve us?  Or is there are model with shorter cycles which would serve us better?  For that matter Sun has been successfully delivering feature changes in the "6 update" train, going against their former rules of not adding features in update releases.  (updates were only for bug fixes)  Having short cycles offers a lot of potential benefits.  Witness what the Ubuntu, Fedora, etc projects have been able to do with short cycles.  It means rapid adjustment of direction with changing conditions.  It means a bug fix has a greater chance of getting into the platform than previously.  etc.
Just a reminder to those of you a) attending JavaOne, b) interested in porting OpenJDK to other platforms, we have a BOF on thursday night.  Please attend.  The agenda is to simply bring the right people into the room and chat.  Please attend.
This session is conducted by a pair from SonyEricsson, and they're discussing Java based rich user interfaces for "mobile" devices.  As always the word "mobile" is overly constrained to mean "cell phone" which is to me a misnomer because "mobile" could clearly mean other kinds of devices than cell phones.  There are lots of portable electronics devices which would do well to have a light Java stack but for some reason the JavaME community focuses on cell phones only.  What about digital cameras and portable game devices just to name two kinds of portable devices that are not targeted by JavaME. Rich UI requirements: Richer user experience is more compelling to user more likely to be bought by users.  Users want their device to be theirs, their own colors, making it work the way they want.  Operators need to brand the device.  Usability enhancements possible with rich UI. JavaFX is a cross platform RIA stack, JavaFX Script is the language, JavaFX Mobile is for cell phones.  "All the screens of your life" are defined as "Desktop", "Mobile" and "TV" (what about digital cameras?).  JavaFX Mobile runs on top of Java ME.  Same language, same API, for the core profile. Tools: Netbeans;  JavaFX plugin for Illustrator and Photoshop (Production Suite) Capuchin: Bridge between JavaME and Flash Lite.  Design UI in Flash with Java providing services.  Combine two well known and widely spread technologies, Flash and Java.  Capuchin API presented to joint MIDlet which contains both .swf content and MIDlet class(es).  Flash can request from Java class, Java class can notify flash UI.  "MXP" components provide services e.g. to access native services like calendar, accelerometer, contacts, etc, these components also available through relevant JSR's. To aid developers to expose an Java service, they have an API generator tool which helps generate MXP components.  They did not create their own GUI authoring tool, because Adobe's Flash is a perfectly fine IDE.  SWF2JAR.  http://developer.sonyericcson.com  Requires Adobe CS. There's an interesting strategy conundrum.. would it have been better for Sun to join forces with Flash Lite?  Or is it better for Sun to attempt to own the whole stack with JavaFX.  For the demo they show a "Car Shop" application developed in both JavaFX and using Capuchin.  It shows you can use two different technology stacks to provide very similar applications.  The reason I posed that strategy conundrum is due to the expense of developing JavaFX and to ask whether that expense was worthwhile.  Why not instead collaborate with Adobe to provide rich UI experiences on mobile devices?  Clearly Sun chose to develop JavaFX. Future?  Sun's direction is clearly JavaFX and they decide JavaFX's direction.  For Capuchin: SonyEricsson has 12+ devices now, also Symbian phones will have Capuchin.  They will continue exposure of services, apparently promise to continue developing their stack.  Their demo showed JavaFX can run on SonyEricsson phones.

Blogging from JavaOne Blog

Posted by robogeek Jun 2, 2009
I am attending JavaOne and will be posting a series of blog's about each session I attend.
So, hmm, Oracle+Sun.  Interesting twist from the IBM+Sun matchup earlier.  There has been numerous rumors over the years about SUN+xyzzy mergers such as Fujitsu, IBM, SGI, Apple, etc.  And it's finally come to Oracle.  It seems there's a lot of scratching of heads over what this will mean for the open source software projects run by Sun, and of course the back of my mind has been pondering the effect on the OpenJDK.  An article in that esteemed dumpster diver rag, The Register, is prompting me to write: Oracle suits to strap on Sun's Java sandals: leader without followers There's a meme in that article that's been in my mind a lot, especially with Stephen Colbourne's series of articles dissecting the JCP.  Maybe the JCP doesn't properly represent what the community wants regarding Java.  Many in the community regard Sun as the "steward of Java" and there are many questions over whether Sun is a good steward over Java.  But does Sun think of itself as the "steward of Java" ??  As an employee inside the Java SE team I heard different statements from different people.  Sometimes we were positioned as Stewards, other times we were positioned as Owners.  The role of a Steward is different than the role of an Owner, right?  Sun's true vision of its role in the Java ecosystem is what flavored what Sun did for/to that ecosystem.  Similarly Oracle will soon (?likely?) finish the purchase of Sun and then it will be their vision of their role in the Java ecosystem that will flavor what they do for/to that ecosystem. Some of the criticism of Sun was not properly monetizing its software, such as Java.  But would a Steward monetize fully?  Or would they hold back for the good of the community?  Is full monetization is something an Owner would do?  Think: Microsoft and Windows and programmers tools for Windows.  The big 8,000,000 lb gorilla in programmers tools for Windows is, so far as I know, Microsoft. But monetization is only part of Owner versus Steward.  Another part is feature choice, right?  I never got involved with the EE end of the Java universe, so I'll trust The Register article when it says most of the focus of Enterprise Java developers is not the EE stack but the various smaller scale open source frameworks and tools.  Hibernate, Spring, Maven, etc.  This says to me that at the EE end the community is not developing the preferred technology through the JCP but through other mechanisms (primarily open source projects).  That points to a failure of the JCP to properly represent what the community really wants. That touches on concerns I've had for a long time.  The decision making for Java SE, as I saw it occur, seemed focused on satisfying the needs of huge organizations over smaller ones.  I always heard it stated as these huge organizations are big customers of Sun, buying lots of Sun hardware/services etc, and of course we should pay attention to their needs.  Similarly it's well known that the JCP is run by the Executive Committees, and that the EC seat's are predominately held by corporate JCP members rather than individuals.  Does Java exist to enrich its owners?  Or does Java exist to enrich us all?  Who is to be making the decisions about the Java ecosystem? Sun employees were the inventor of Java and that means (because software is a work-for-hire arrangement) that Sun has had the right choose how Java is delivered to the market, and what to do with this thing.  For better or worse Sun's positioning of Java was as an open playing field for everybody to partake in (Sun==Steward).  Maybe Sun's true vision is Sun==Owner and that distinction may be the source of much of the friction in the Java ecosystem.  What Oracle do we consult to learn what Oracle's vision is?  And if the JCP truly doesn't serve our needs perhaps it needs to be killed, but what would or should replace it?  Does it serve us best for significant pieces of the Java ecosystem to continue being developed outside a shared standards process?  Or does the existing open source projects better serve the shared needs of the Java ecosystem?  And should the core pieces of the Java ecosystem, the ME/SE/EE stacks, also be defined via open source projects rather than the closed source style of the JCP?  Unfortunately we in the Java ecosystem/community cannot make some of the required choices, as they rest with the corporate overlords.
I'm listening to the 'holidays 2008ish' episode of Javaposse and in reviewing their last years predictions they have enough fumbling around the status of OpenJDK that I want to do a little bit of explaining.

OpenJDK 6 != JDK 6

There are circuitous historical reasons for this but the fact is that OpenJDK 6, as good as it is, does not correspond to JDK 6uN for any value of N.  OpenJDK 6 began as a fork of OpenJDK 7, and the team stripped out code from the OpenJDK 7 fork until it became compatible with the Java6 specification as verified by the JCK 6 test suite. Joe Darcy has posted several blogs about this OpenJDK 6 Genealogy, OpenJDK 6 and 6u10 features, OpenJDK 6: Logistics of Partial Merge with 6u10, and the most important of these is:  Forward to the Past: Toward OpenJDK 6 If you're scratching your head going "huh??", well, I don't blame you, just read Joe Darcy's blog postings and it will be clear as, well, uh, I just hope it's clear why. The bottom line is that OpenJDK 6 works rather well, several Linux distros are using it as their JDK, it can be built to pass the JCK6b test suite, meaning OpenJDK 6 can be used to build a compliant JDK, and unfortunately it is this evolutionary sidetrack which we hope will be relatively short-lived.  It serves a purpose, namely of having an fully open OpenJDK compliant with Java6 ....

OpenJDK ~=~ IcedTea

It seems some people really like typing "./configure" rather than setting up environment variables and running "make".  The IcedTea project originally began due to incompleteness in the OpenJDK (gaps due to encumbrances) and the community requirement of a fully open source toolchain and code base.  IcedTea has long been a set of patches applied to OpenJDK, along with a different build system that is "./configure" based as I just said. In OpenJDK we've replaced the encumbered code such that there are no gaps any longer.  As we've done so I believe the IcedTea project has shrunken the number of patches they use.  One nice thing seems to be that the IcedTea configure script makes it easy to build OpenJDK in many different modes such as using the Zero Assembler port to support compiling on non-x86/sparc chipsets, etc.  A big piece IcedTea provides is a plugin/java-web-start infrastructure.  We haven't been able to open source our plugin and of course for 6u10 we completely rewrote the plugin.  It is hoped we will open source the new plugin into the OpenJDK project but to my knowledge that decision has not been made concrete set in stone. I don't spend much of my time looking at IcedTea so don't be alarmed if I've missed something ...

OpenJDK 7 == JDK 7

Okay, given that there is not a Java7 JSR and all the JCP stuff related to that issue ... Hopefully all that will be straightened out and we do have a proper Java7 JSR, so for the following please assume that's the case, that Java7's JSR status is straightened out ... the plan is that beginning with OpenJDK7/JDK7 that the code bases will be nearly identical.  It is obviously expensive to maintain a fork, and if JDK7 were to diverge strongly from OpenJDK7 it would do two things: a) be very expensive, b) undermine our efforts at an open source ecosystem.  But "nearly identical" does mean it's likely there will be some differences. Remember those gaps due to encumbrances?  Some of those gaps were simply code we couldn't open source as of May 2007 but have since done so, other gaps are for code we still have to gain approval on (e.g. SNMP), but there is some code where there are open source replacements where we still use the old closed source code.  This is primarily in font and graphics rasterization.  The old closed source rasterisation code, while being encumbered, has had 10+ years of bug fixing and fine tuning etc and, for any open source replacement to displace that code in productized JDK builds, it would have to be provably as fast and stable and good quality as the existing closed code.

What took so long?

If we had followed normal release patterns JDK7 would be shipping about now.  That is, Java6 shipped in December 2006 and our normal pattern is 18-24 months between major releases meaning the JDK7 launch would have been 2-5 months ago.  What happened?  Well, clearly there was a resource crunch on several angles.  For example getting the nearly complete OpenJDK source release in May 2007 took a lot of effort from lots of people.  But there was also certain announcements at JavaONE in May 2007 (a little thing named JavaFX) which also turned into a major rethink of Java (as some have said, this ain't yer Dad's Java) and also a major piece of work to accomplish.  In other words instead of producing JDK7 we did JDK6u10 and JavaFX.

JavaFX 1.0 is launched Blog

Posted by robogeek Dec 4, 2008
Just in case you're not all election'd out, and just in case the recent election in the U.S. gave you some hope that things can change through elections, here's an opportunity to affect the direction of Java ME.  JCP Java ME EC Election: Vote now for a Voice for Independent Developers by Terrence Barr is a good outline of circumstances related to the JCP and Java ME.  The role of the JCP is to oversee and coordinate specifications related to Java technologies.  As Terrence said "Fundamentally, the JCP is a very open organization" and a large portion of the JCP membership is made up of individuals.  However the EC's, especially in Java ME, are dominated by industry heavyweights.  While the industry heavyweights do have a reason to be at the table and represented in decisions regarding Java technology directions, so too is there a reason and need for individuals to be represented in those same decisions.  For some things the viewpoint of the individual, rather than the industry heavyweight, is very important to have in the deliberations. Terrence makes a good case for Sean Sheedy, but since I don't know him I can't say whether or not Sean is a good choice.  I do agree wholeheartedly that having individual independent developers represented in the JCP is vital for the JCP to be more representative of the whole of the Java ecosystem.
The Sun Shows Signs of Life "After two-plus years of..generally eerie calm..sun is finally showing signs of life.."I think..minimum is behind us," says sun..statement is prompted by an October flurry.."This represents a real increase in .. activity."..Hathaway tamps down the excitement: "We're still years away from .. maximum and, in the meantime, .. sun is going to have some more quiet stretches." ..But it's a start. Stay tuned for .. activity.

Filter Blog

By date: