Half way through EclipseCon, and I’m exhausted just blogging about it. Before we take a look at what happened yesterday, here’s my top picks for today:
The morning’s set of tutorials cover a variety of different topics, from Modular Architecture to UI Test automation. At the same time, there’s a brief Q&A for the Oracle Execs on the Future of Java, which would be a great place to pose questions on their commitment to OSGi yesterday. That’s followed by a Gemini panel session and EclipseLink/DBWS talk.
After lunch, there’s lots more OSGi goodness, but there are several other talks which are pretty interesting. For example, XQuery Development Tools talks about the functionality to do XQuery and XPath development (for XML documents, not to be confused with Xtext which has nothing to do with XML). There’s also Groovy-Eclipse, which won won best open source award on Monday.
One of the things missing in the OSGi Enterprise Spec was Composite Bundles (also known as Nested Frameworks), which is prototyped in the Equinox container already. Go to Tom’s talk to find out why, and when it will be in an OSGi standard.
Whilst you’re in Santa Clara, did you know you’re only a few minutes drive away from the Apple Company Store, which is the only store (worldwide) to sell Apple-branded apparel. If you’re a Mac fan, I strongly recommend you take the trip – and if anyone who happens to work near me wants to head there and pick up a large black mug, I’d be grateful :-) Unfortunately, they don’t stock ties just yet …
Recap of Tuesday
So, what happened yesterday probably deserves many blogs in themselves. The biggest was probably Oracle’s keynote on the future of Java (more below). Meanwhile, the OSGi enterprise specs were announced; I’ve written up an analysis of what’s new here. Interestingly, the nested frameworks/component bundles didn’t make it into the final revision of the draft, which is a shame.
It seems that JavaFX is still a highly funded project (even though it’s a dead technology to many), and they want to merge the Oracle and Sun VMs. Arguably, Sun’s hotspot was superior to JRockit (and more stable, too) so I suspect they’ll keep that part of the name, though JRockit’s garbage collection might get integrated. But most of these are so low-level technologies that I doubt that will happen any time soon.
They also want to throw JDK 7 over the wall in the shortest time possible
(read: sometime in 2011, probably) since project Coin has a number of new
invokedynamic is going to make the JRuby and
JPythons of the world more performant, and hopefully even a decent Lambda
implementation (more on those in separate blogs). There was no concrete mention
of the Apache Harmony/JCP standoff regarding the future of the Java name, which
is why it’s been called JDK 7 since its announcement. They offered the olive
branch to the community, but unfortunately took all the olives off first.
The final aspect Oracle’s commitment to make OSGi and Jigsaw play nicely together. Beware the IDEs of March, though; all may not be what it seems. It seems to be based on Qwylt, whose homepage design has been nicked from the Apple Store, and whilst it says “back soon”, Qwylt has actually lasted for some time. From the previous incarnation of the home page:
- APIs for interacting with modules
- A dependency resolution environment
- SPIs for building module systems
- A platform for module systems to share classes and resources
- APIs for services & dependency injection systems
- Qwylt is… a module system framework
- Qwylt is not a module system implementation, and is therefore not a replacement for OSGi or any other existing module system. It is a new environment in which new and existing module systems can be expressed.
- Finally, Qwylt supports multiple simultaneous module systems—it is a framework for interconnecting modules, within and across module systems…
- Qwylt is… a module system fabric.
Yes, that’s right, it’s the ghost of JSR277 rejuvenated. In fact, it says so, right here:
While this project was conceived and created over a very short time, the ideas have been brewing for far longer and have been shaped by many.
This project would not have been possible without the late JSR 277 and the many contributions of its fine expert group members and specification leads. I would particularly like to thank Stanley Ho for his dedicated leadership as well as his patience and thoughtfulness dealing with my suggestions; though the core ideas expressed here derive from my own contributions to 277, many important refinements belong to him. Thanks also to EG members Glyn Normington, Doug Lea, Richard Hall, Michal Cierniak, and Adrian Brock, all excellent collaborators who greatly helped my understanding of the problem domain, and Andy Piper, Daniel Leuck, Gordon Hirsch, Sam Pullara, Hani Suleiman, Brett Porter and Vladimir Strigun for their contributions to 277.
Perhaps this is what’s meant by Oracle encouraging open source communication, by doing JCP things outside the JCP as open-source projects, and then just folding them in as needed. Whilst Alex Buckley’s comments are specifically that neither JSR294 nor Jigsaw are meta-module systems, Qwylt quite clearly seems to be the case. Maybe it will even support Stanley Ho’s concept of largely backward compatible springs to mind again, with his concept of four version numbers (which, incidentally, still seems to be part of the Jigsaw implementation):
So the JSR 277 EDR2 proposes the format of a version number as:
major[.minor[.micro[.update]]][-qualifier]where major, minor, micro, and update are non-negative integers, i.e. 0 <= x <= java.lang.Integer.MAX_VALUE. qualifier is a string, and it can contain regular alphanumeric characters, -, and _.
- Major version number should be incremented for making changes that are not backward-compatible. The minor and the micro numbers should then be reset to zero and the update number omitted.
- Minor version number should be incremented for making medium or minor changes where the software remains largely backward-compatible (although minor incompatibilities might be possible); the micro number should then be reset to zero and the update number omitted.
- Micro version number should be incremented for changing implementation details where the software remains largely backward compatible (although minor incompatibilities might be possible); the update number should then be omitted.
- Update version number should be incremented for adding bug fixes or performance improvements in a highly compatible fashion.
- Qualifier should be changed when the build number or milestone is changed.
In fact, he demonstrated his lack of understanding immediately afterwards:
The fact that some programs cope with three or even two numbers is not a prima facie reason against four. The OSGi policy of three-number versions where the third is for bug fixes (OSGi R4.1 3.6.2) leaves only two numbers for the mainstream product version.
The key thing which eluded Stanley – and continues to elude those on the
Jigsaw team – is that there should be no relationship between the “mainstream
product version” and the module version. In fact, it’s a rookie mistake to
assume this. (Everyone makes mistakes: Eclipse re-numbered all of its bundles
through the 3.1 release with a 3.1 prefix (e.g.
even if they didn’t need it; however, by 3.2 they fixed the renumbering of
everything, which is why you now have _3.2 and _3.3 bundles in the runtime –
they’ve not changed since their initial release.) However, smart people learn
from other people’s mistakes rather than making the same ones again themselves.
I’ve made this point before that the module version should be independent of the marketing number of the system being released; sadly, if there’s one group of people who understand version numbers less than Sun, it’s Oracle, so I’m not holding my breath hoping for a good resolution here. Time will tell, but let’s conclude with the commitment to OGSi being good but that the implementation will tell.