magpiebrain

Sam Newman's site, a Consultant at ThoughtWorks

JSR 270 covers the proposal for the J2SE 6.0 release. Unlike most other JSR’s, it is not defining any new API’s, rather it is defining which JSR’s are being considered for inclusion in what will no-doubt be called Java 6. Looking down the list I was struggling to find much on the list I actually wanted…

<a href="http://jcp.org/en/jsr/detail?id=105

JSR 105: XML Digital Signature APIs>

Got to admit, this seems inoffensive. It implements a W3C spec from 2002, which given how fast these things move is about par for the course. It’ll probably be handy for people doing web services and such, but does it need to be in the core JDK?

<a href="http://jcp.org/en/jsr/detail?id=268

JSR 268: JavaTM Smart Card I/O API>

So, hands up those of us who are programming for Smart Cards. Now keep your hands up if the lack of inclusion of the Smart Card I/O API into J2SE is causing you a problem. While I don’t dispute we’ll see more Smart Cards about in the future, is this really core functionality? More core than, oh I don’‘t know, being able to work out how much disk space is free?

<a href="http://jcp.org/en/jsr/detail?id=199

JSR 199: JavaTM Compiler API>

Something interesting, and what in my mind new releases of J2SE should really be about.

While the existing command-line versions of compiler receive their inputs from the file systems and deposit their outputs there, reporting errors in a single output stream, the new compiler API will allow a compiler to interact with an abstraction of the file system. This abstraction will likely be provided by an extension of the NIO facilities in Tiger (1.5), and allow users to provide source and class files (and paths) to the compiler in the file system, in jar files, or in memory, and allowing the compiler to deposit its output similarly. Diagnostics will be returned from a compiler as structured data, with both pre- and post-localization messages available.

In addition, the new API should provide a facility for a compiler to report dependency information among compilation units. Such information can assist an integrated development environment in reducing the scope of future recompilations.

Sounds good to me, especially the bit about the compiler reporting dependencies. No complaints here.

<a href="http://jcp.org/en/jsr/detail?id=202

JSR 202: JavaTM Class File Specification Update>

I’m a little confused about this – I thought these changes were required for Tiger, and as such would already be included – JSR-heads feel free to put be straight on this.

<a href="http://jcp.org/en/jsr/detail?id=221

JSR 221: JDBCTM 4.0 API Specification>

This version focuses on making API access simpler, and improving connection management, all while being backwards compatible. No complaints.

<a href="http://jcp.org/en/jsr/detail?id=222

JSR 222: JavaTM Architecture for XML Binding (JAXB) 2.0>

This has stumped me a bit. JAXB is a nice idea, but the generated classes suck and it has a whole load of dependencies. I suppose if JAXB is the way to go, then including it allows it to compete with the (nicer) XSD functionality in .NET. As for how much space adding all the JAXB dependencies will add to the overall JDK size…

<a href="http://jcp.org/en/jsr/detail?id=223

JSR 223: Scripting for the JavaTM Platform>

Fear not, this is not the inclusion of Groovy (or, horror of horrors BeanShell) in J2SE, it is actually about exposing Java objects to scripting languages. PHP will be supported by the specification (although the capacity will be there to support other languages). Whilst the JSR talks mostly about web-scripting, it should work equally well within a standard JVM. I don’t object to the concept, and am neutral to it’s inclusion in the core J2SE.

<a href="http://jcp.org/en/jsr/detail?id=224

JSR 224: JavaTM API for XML-Based RPC (JAX-RPC) 2.0>

Another focus on supporting ease of development, as well as supporting the newer W3C specs, and will support non-HTTP transports, so I guess it’s no bad thing – if the Java->WSDL->Java stuff gets improved and simplified too I’m happy, but again it does seem like this is being included to compete feature to feature with .NET rather than focusing on what most Java developers want in the core.

<a href="http://jcp.org/en/jsr/detail?id=260

JSR 260: JavadocTM Tag Technology Update>

I use Javadoc so little, and when I do I rarely use any of it’s more advanced features. As such I think it unlikely I’ll be using any of these new tags:

* categorization of methods and fields by their target use

  • semantical index of classes and packages
  • distinction of static, factory, deprecated methods from ordinary methods
  • distinction of property accessors from ordinary methods
  • combining and splitting information into views
  • embedding of examples, common use-cases along with Javadoc

But I know someone has been waiting for this stuff for ages, right?

<a href="http://jcp.org/en/jsr/detail?id=269

JSR 269: Pluggable Annotation Processing API>

Finally we end up with this JSR, which on first glance appears to improve the handling of annotations to make it easier to build bespoke annotation handlers, which I believe brings Java closer to .NET’s annotations.

Summary

No real “hot damn, I want me one of those” moments here. Whilst it might be unfair to judge the proposed inclusions this early on (the JSR has only just been released for review) a large amount of the inclusions seem to be there to compete with similar functionality already in the .NET framework. Perhaps those of us who’ll never use this stuff won’t begrudge the larger download and the increasingly bloated feel of the JDK, or perhaps I’ll be completely wrong, and in two years from now we’ll all be developing Smartcard distributed web-services systems… J2SE 5 focused on new languages features and the improved concurrency utilities (incidentally, Doug Lea is all over allot of the above JSR’s), but so far J2SE 6.0 doesn’t seem to have as much focus. But if it can deliver on it’s promise of a better developer experience when it comes to web-services, then all those extra megabytes might be worth it.

Advertisements

10 Responses to “Sun on Mustang (J2SE 6.0) – squaring up to .NET?”

  1. nnevatie

    Aargh, for one, I would like the JDK/JRE to be modularized so that one does not have to download all the stuff(bloat) included therein. All this makes me sad really – with the Sun’s really restrictive policy regarding customization of the re-distributable JRE (making a trimmed, lightweight JRE a part of your application distribution).

    Soon the JRE alone will weight 30MB. Really nice.

    Reply
  2. Erik

    What about JSR 203 – More New I/O APIs for the JavaTM Platform (“NIO.2”).

    APIs for filesystem access, scalable asynchronous I/O operations, socket-channel binding and configuration, and multicast datagrams – stills seems to be slated for the 6.0 release.

    Would be nice to get a library during the process, as Doug made avaiable during 155…

    Reply
  3. Sam Newman

    I know – I found the exclusion of JSR 203 odd. There are still some no-brainer IO functionality that Java is lacking (such as the aforementioned ability to determine free disk space, better support for external processes etc.). For those interested, JSR 203 picks up where the original NIO work started – much of the content of JSR 203 was original scheduled to be in Tiger but was dropped due to time constraints. It includes such advanced features (note sarcasm) as the ability to set file permissions (swoon!) and support for symbolic links (gasp!).

    To be fair the mustang JSR does state that: “The final Mustang specification might not include all of these JSRs, and it might include some JSRs not listed here.”, although the popular RFE’s don’t seem to be that fairly represented in the included JSR’s.

    Reply
  4. David Flanagan

    The Class File Specification Update was originally targeted at Tiger. When it slipped, they decided to include only the (substantial) class file changes necessary to support generics, enums and annotations.

    Still to be done, however are lifting some of the hard-wired limits (no more than 64K methods, for example) and allowing split verification like J2ME does.

    So there is still plenty for this jsr to do….

    Reply
  5. Josh

    Most of these really seem like they should be 3rd party libraries, not features of the core. Just like nnevatie said, the JRE will soon be so bloated, few people (average users) will take the time to download it.

    Probably knew this was coming, when they decided to jump from verison 1.5 to 5.0 for marketing reasons. I was really hoping 1.5/5.0 was going to be the standard for future releases.

    Oh well, at least now I won’t have to worry about eagerly awaiting for 6.0

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Basic HTML is allowed. Your email address will not be published.

Subscribe to this comment feed via RSS

%d bloggers like this: