These are currently being standardized but I gather there are implementations available already. If you want to read the specs you can find them here.
Whilst I understand the technical reasons for having these API’s – basically that a “managed environment” can’t support the existing equivalent API’s in the JDK (java.util.Timer and java.util.concurrent.*) there are some other things about this work that I find a little concerning.
Firstly, that part of the justification is about having simpler API’s than what’s in the JDK. What does that say about what’s in the JDK? Which programmers are the intended audience for the JDK API’s versus those in the JSRs which are J2EE oriented. And what does that say about the respective levels of ability of these audiences? Are we really suggesting that J2EE programmers aren’t as smart as those that might use the JDK? That doesn’t sound like a good thing to me for all sorts of reasons.
Secondly, these JSR’s are to all intents and purposes replicating API’s we already have in the standard JDK. Were I to see this kind of duplication in a customer’s architecture I’d be seriously concerned and quoting such things as the DRY principle (which actually goes way beyond the simple issue of not duplicating code). Is it really a good thing for J2EE to be going down a path of duplicating existing standardized functionality bent to it’s own needs? Might there not be something wrong with the model?
I gotta say that these JSR’s have a bit of an odour to them – good or bad I haven’t decided yet……….
Entries (RSS)