Sam Newman's site, a Consultant at ThoughtWorks

Archive for ‘February, 2005’

Well, MT Blacklist seems to be well and truly borked on this MT install, and it seems to be stopping people commenting. Until I sort the issue, blacklist is being switched off, and comment moderation is on. The problem may or may not be down to my host installing a new version of, but until I work it out it’s more hassle than it’s worth keeping blacklist on…

You know how it goes. Some days you just don’t know what the world is going to throw at you – and at some times of the month all you want is a feeling of comfort and safety, which still gives you the freedom to go roller-blading, cycling, dancing or even base jumping. Before I’d feel bloated – weighed down even. But not now – its small, cute looking, and doesn’t even need an applicator. Best of all, my partner can find it in my bag and not even know what it is!

Feel free, feel light – iPod shuffle

So that was one of the most nerve wracking (IT-related) moments of my life, but after 30 minutes of stressful, body shaking nerves, curses, and general questioning of what I was doing, I was eventually able to part the Mac mini from it’s attractive upper shell and leave it naked under the waning daylight. What followed was simple by comparison, and one false start aside the mini was dressed once again an booting up to show it’s brand new 1GB of memory.

Thanks have to go to an article at macworld, although Russell Beatie gave me a more realistic idea of what to expect, and to be honest without smashword’s video of the feat, I’d be unsure if it was even possible with the tools I had to hand. I’m glad it’s over, and have gone from questioning Apple’s decision to price memory upgrades so exorbitantly to being almost convinced that they made the mini so hard to get into to sell overly expensive upgrades in the first place. Expect a follow up on first impressions of the Mac mini soon.

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="

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="

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="

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="

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="

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="

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="

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="

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="

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="

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.


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.