Java 7 Platform: What’s In, What’s Out!
Posted on August 8, 2008
Filed Under news |
Alex Miller maintains an unofficial Java 7 home page and recently updated his predictions about what will make it into Java 7. boy, did this spark off a discussion in the forums. So what’s the big deal?. Well, the only thing that appears clear in all of this is uncertainty. Stepping over to the official Java 7 home page is like walking through treacle. Access to information is slow, slow, slow!
Anyway, back to Alex’s post. A few things sprang out at me. First was that Closures are unlikely to make it into Java 7. Personally, I think this is a good thing. Let’s learn from the generic rollout and get it right. But Neal Gafter is chipping away at Closures. We’ll just have to wait and see.
The native language support for XML for me is just plain wrong. We need to be reducing the amount of XML we consume instead of making it easy for people to use more of it. Remember, the SAAJ Java SOAP API that made you write really verbose code. Well, with XML support you can do just as badly more easily. Why do we want to go there?
JSR-277 - Java Modules - ain’t this just the Java 7 love child. Let’s back up a bit here first. In the late nineties, after object-oriented design was well-established and component-based architectures started emerge, it was clear that modularity in Java was just not there yet. The whole class-path/class-loading was the oft-cited nightmare for component developers in the Java world, whilst the Windows guys wallowed in DLL-hell. OSGi took the bull by the horns and brushed aside a lot of these obstacles and is a core within Eclipse - invariably one of the most used and well-respected component-based, plugin-driven architectures within the Java community.
Then came JSR-277 that is a competitor (or alternative?) to OSGi. Trouble? Well, there is nothing wrong with taking a good idea and implementing it afresh, taking on board current industry thinking, tools and techniques to hand. Moreover, the folks over at OSGi are not, IMO, against JSR-277 as an alternative. In fact, it could be great for OSGi. However, given that JSR-277 will be packaged and delivered as part of the JRE, but does not interoperate with OSGi, some feel that this is no way to run a JSR, and is sad state of affairs when technology platforms submerge into the murky world of politics. However, with more examples and discussions around the new Java Module System, I think the fun and games are set to continue…
Moving on, the rather filthy date and time (JSR 310) api get a spring clean and a couple of concurrency (JSR 166) tweaks are knocking on the Java 7 door - multicore is every darling! And finally NIO 2 (JSR 203). Hands up if you have used NIO? Let me see, that’s 10% of the room. It’s just one of parts of the platform that the average Java developer either has zero knowledge and/or interest in. Why? I think this api is really for framework writers and/or vendor tool folks, that have above-average problems, not for the everyday Java developer. That said, you should really take a look at what nio is and what are its advantages and if you’ve got a spare hour (lucky you), check of the following NIO 2 presentation.
There’s plenty more meat on the Java 7 bone but I’m out of time. I’ll bury it for now and dig up for seconds sometime soon…
Comments
8 Responses to “Java 7 Platform: What’s In, What’s Out!”
Leave a Reply
Very nice post. I’m in favor of OSGi, although it has to be much further simplified.
The JSR 277 people are working on an OSGi interoperability layer. See this article… http://weblogs.java.net/blog/mandychung/archive/2008/07/osgi_repository.html
hey ted, thanks for the heads up. i read that article and it was in fact linked to in the main article above, “with more examples and discussions…”
i haven’t, however, followed up on details yet though…
> The native language support for XML for me is just plain wrong. We need to be reducing the amount of XML we consume instead of making it easy for people to use more of it. Remember, the SAAJ Java SOAP API that made you write really verbose code. Well, with XML support you can do just as badly more easily. Why do we want to go there?
That’s not the point. People are already using XML, lots of XML. Not just in Java, but in all industries that need to transmit data from one company to another.
Not supporting XML Literals only hurt Java programmers. It will do nothing to discourage the use of Java within the language, and certainly not influence anyone outside the language.
@Jonathan - maybe but I don’t buy it.
Adding XML support to the language is endorsing/promoting its use and this is really merging two syntactically disparate languages into one. It smells like Jelly and JSP Scriplets, two perfect examples of why mixing Java and XML doesn’t work.
I don’t know, but looking through small and simple example uses of it is just not pretty. But we are going to see a lot of Java code cut using it. Sigh! Hopefully, developers will box this in away and not let it pollute the other areas of the source code.
Fingers crossed they’ll run with the Java-like syntax, but I’m not sure where things are the moment there…
You’ll notice that I predicted native XML support with “0% - Not a chance”.
The response to this idea has been almost universally negative from everything I’ve seen. So, I wouldn’t worry about it too much.
I don’t see much research needed to get something good with XML support. Java just need to look at LINQ from .NET.
[...] way, from reading various breakdowns and predictions about Java 7, I decided to put together my own list of what I’d like to see [...]