Danny Coward's Sun Weblog

« Open Source Java SE:... | Main | Sampling Java SE 6... »

20060922 Friday September 22, 2006

Channeling Java SE 7

Its time for an update on where we're at with Java SE 7. Marketing would probably call this kind of early view into product planning part of a 'rolling thunder' campaign; its really just my inability to keep a secret.

Think of any interaction Sun has with people who care about Java. i.e. a massive number of conversations, comments, emails, RFEs, bugs, articles, presentations at conferences to/with/from developers/Sun customers/JCP members/my dad all being forced into a massive funnel. Otherwise known as the Java SE 7 Planning Team (with guidance from some stellar members). The first thing to pop out the other end of the funnel when we have pushed long enough on the thick end is the platform JSR. Here's the Java SE 6 one, for example, which happens to be finishing its public review. The platform JSR gives the first concrete indication of what we'd like the APIs of Java SE 7 to look like.

So we generally try to identify themes for the release, and highlight the larger API changes and additions I'll be proposing to the Java SE 7 expert group as the Java SE 7 specification lead. These of course are JSRs themselves. And many of them are of course, the larger pieces of engineering and design work in Java SE that we're helping make successful, by putting our smartest people on them. All based on all the input to our planning processes. Phew, full circle !

As we move out of the funnel (into another) I'll write about some of the non-JSR features that are high on our list too. And don't forget you'll see our implementation evolve at jdk7.dev.java.net as we get going. But its a bit early for that, so for now here are the JSRs that are high on our list for consideration.

Things to do with modularity
JSR 277 - JavaTM Module System This is the specification of 'son of JAR' i.e. a new distribution and deployment format for Java code. I keep calling them superJARs, but it hasn't caught on as nickname yet.
JSR 294 - Improved Modularity Support in the JavaTM Programming Language This is an addition to the Java language for 'superpackages'. That is, fine graned control over the visibility of APIs in packages.
Supporting other languages
JSR 292 - Supporting Dynamically Typed Languages on the JavaTM Platform This aims to add a new bytecode to instruct the JVM to make a method invocation where the return and parameter types are not known until runtime. The Java language doesn't need this, but interpreters for dynamic languages like Python and Ruby do.
Including some dynamic language engines
 By the time Java SE 7 is close to shipping in 2008, we'd expect a number of good quality engines that support other languages, other than the Javascript one we put in Java SE 6. Like JRuby, Jython or Beanshell for example. Ensuring they work really well, maybe out of the box, in Java SE 7 is looking attractive.
Thins that ease Swing App Development
JSR 295 - Beans Binding Scott's expert group is aiming to make hooking up one bean to another to keep them in sync really easy.
JSR 296 - Swing Application Framework Hans' expert group is going to take the drudgery out of Swing application development by putting all those pieces of code that pop up repetitively in every Swing application into one framework.
JSR 303 - Bean Validation Jason's expert group has just started out on this, but it could be a really useful way for developers to define easily the validation they want to have happen when binding beans with the Beans Binding APIs.
Language Changes
We haven't finalised these yet !
 We'll be bringing a small set of specific Java language proposals into Java SE 7. More on this below.
Things that I can't tie a neat ribbon around yet
JSR 220 Java Persistence Architecture
 The Java Persistence APIs that were developed in the EJB expert group look like a promising candidate for Java SE 7. With the ease of development API work for Swing, together with this, writing desktop applications with a database backend could be dramatically easier to do.
JSR 260 JavadocTM Tag Technology Update Our Java API documentation is SO nineties. Enough said.
JSR 255 - JMX 2.0
& JSR 262 - Web Services Connector for JavaTM Management Extensions (JMXTM) Agents		 Eamonn's two expert groups are making an update to the JMX programming model for instrumenting Java applications with management agents, and a Java API expression of the web services standard for managing these agents with standard tools.
JSR 203 More New I/O APIs for the JavaTM Platform ("NIO.2") Alan's expert group is defining a much requested new filesystem API, and a true asychronous IO API. Look out for an Early Access Draft soon.

Of course there are many requests and proposals to make smaller update existing APIs in addition to these.

Language Debates

I'm close in fact to having enough to write up the platform JSR for Java SE 7, except really for finalising the set of language changes we would like to include. Language changes are special because they can be powerful and popular - as the humble foreach addition in JavaSE 5.0 has proven, but finalising the set is tricky. Tricky not to trick out, so to speak.


I know which one I prefer*

Of course each language addition has to be in itself useful - and the current debates around closures, simple closures and the like, shows the difficulty in concluding on some of those even for Click and Hack. But we will be keeping sight of the language as a whole and ensure that we are sticking to its principles, and not ratcheting up its gravitational mass by adding too many new features and turning into Steelian Black Hole. In no particular order, language level XML support, closures, block constructs, strings in switch statements, language support for BigDecimal, Java property support, lightweight method references, extensions to the annotation mechanisms are the leading candidates.

I don't know about you, but I want to remain employable for many years to come.


*Updated: Thanks to David for pointing out that as beautiful as is the styling of a Ferrari (the original image I put on the left), its gas mileage ain't winning beauty contests. Unlike the Tesla I replaced it with.

Posted by dannycoward ( Sep 22 2006, 05:15:36 PM PDT ) Permalink Comments [13]

Comments:

For JSR 277, have you seen the Java Plugin Framework at http://jpf.sf.net? It's LGPL, but seems to meet a number of those requirements.

Posted by Jonathan Giles on September 22, 2006 at 05:45 PM PDT #

I sincerely, honestly believe you need to do a better job of marrying Java BACK to the DOM, and into Firefox. Right now, you're asking the world to pick between Java and the web, and they're picking the web. Let's collapse all the virtual machines delivered via the browser to one - make it Java - then allow for support of multiple presentation layers, from the DOM to SWING to gtk. Just an opinion.

Posted by Web developer on September 22, 2006 at 09:46 PM PDT #

The most popular feature request is to thin down Java and remove features not used a lot. The specific community demand is to have a minimal java download, ala flash, and then download parts of rt.jar as and if requested.
.V

Posted by Vic on September 26, 2006 at 05:22 AM PDT #

Thanks for the update. I'm surprised to see no mention of fixes for generics. Is anything in the works? Thanks, Dave

Posted by David Walend on September 26, 2006 at 05:33 AM PDT #

I, too would like to know where the fix for generics is. I think before Sun goes an adds a boatload of C# copied features, they need to get the features right in their current stack. Please go back and do it right. Break compatability if you have too, but don't give us this half assed generics implementation. Implement it into the VM and do it right. Heck, I read somewhere that Gosling does not even like generics and autoboxing because of all of the problems, which are widely known. In trying so desperately to not break compability (for fear that people will leave Java) you've made a half baked implementation that will make people leave Java. It also amazes me that the features in C# that the Java community mocked at first, are now being implemented in Java 7! LOL. If I wanted C# features (properties, assembly versioning, partial classes, etc), I would just use C#. And to top it off, a major new feature will be to have Strings in switch statements! LOL I used to be a Java zealot, but I'm quickly losing faith in the platform when M$ seems to have implemented many of these features already and done it mostly right. This is depressing. Sun, FIX WHAT YOU ALREADY HAVE BEFORE YOU GO ADDING ALL THIS CRAP IN THAT NOBODY IS ASKING FOR! Oh well, I guess I'll just have to learn ruby.

Posted by Michael McCutcheon on September 26, 2006 at 09:57 PM PDT #

Hi, can you elaborate on "lightweight method references"?

Posted by 24.125.10.53 on September 27, 2006 at 05:16 AM PDT #

Most of the complaints that people have in relation to generics are bogus; they go away when people code 'better'. For example, nobody really complains that local variables are not available via reflection, but because they are accustomed to writing instanceof and casts, they want to be able to do that with generics too. It's better to use polymorphism (such as the visitor design pattern). Of course, Java generics could do that, but I don't think that should be a priority. Java generics work really well if you work with them, instead of moaning that they don't conform to your expectations and your sloppy coding styles. I have half a blog explaining the common generics complaints and the reasons why they're (largely) bogus, drop me a line at ricky.clarkson@gmail.com if you want to read the work-in-progress. I'm writing it very slowly..

Posted by Ricky Clarkson on September 27, 2006 at 06:01 AM PDT #

Some Human is funny and short sight. Copy from C#???? Delphin, Pascal, Object C, Python have these features already. I believe eng. from sun are making their best effort to help us not making c# clone(but it may be a ruby clone :). About ten years ago, no one asked fot GC(even someone try to add the delete keyword in java again....see the REFS DB), clear syntax version of C, richer and cleaner Object oriented support. but we have it now, Y??? Just bcuz someone on the earth are long sight and clever enought to help us.... okay, u may say "Im can see farther then these sun's eng. These new features are definately suck". Okay, how much time do u spend in the R&D on features and languages? Are you expert in computer language design? these sun's eng. got a PHD. on the language aspect. If you exclaim with no reason and supporting material to you professors in uni., Will they listen?

Posted by francis on September 27, 2006 at 12:18 PM PDT #

javadoc... we can overload methods & contructors, why not javadoc? why should I need to copy/paste @param and @throw tags between overloaded methods?

hopefully this is covered in the javadoc JSR you listed.

Posted by Jeremiah Johnson on October 23, 2006 at 06:37 AM PDT #

I always was excited when new versions of Java were coming (1.2, 1.3, 1.4) and always knew what features it had long time before. After 1.4 I started to believe Java was not evolving as it should (at least for what I expected to) and I started to see that C# was evolving that way. Still I like Java for it cross-platform (I have not tried Mono), its community, and lots of really good open-source projects. It seems Java SE 7 comes to the rescue. Is it late? Please don't let it pass one/two years until my application server supports it. My votes goes for: - Java Module System: I wanted this since version 1.4. The platform needs an easy way to package libraries, applications with easy dependency information. Hope two different versions of the same library could coexist and say good bye to the class loaders hell!! - Support for Properties. I'm envious of C# because of this. I loved Delphi in its time because of this fancy things built into the language. - Support for some kind of "typed" function pointers, delegates, ... I think listeners are overkilling. - And the last in my list. Please take the Java SE libraries, the Java EE also, call it all just Java, make the core very lightweight and the rest put into modules so you use what you need. You could release the modules separately, so for technologies that evolve more quickly (XML, WS, ..) you could release more often maybe maintaining the base with no changes at all getting better support from application server providers ... is just a thought.

Posted by Juan Hernandez Gomez on November 14, 2006 at 04:00 PM PST #

Properties! \o/ Operators for BigDecimal! \o/ Strings in switch! \o/

Posted by 143.54.83.44 on December 12, 2006 at 12:15 PM PST #

java is still far away from its ambiteous audience 1- operator overloading 2- multiple return values 3- LINQ like syntax (the one introduced for .NET) if the java community doesnt act faster and catch up and abandon this fleet of conservative old fashioned programmers it will loose the market actually its loosing the market for .NET I was applying for jobs and was surprised that the .NET vacancies are much more than the java ones hope the java executive commity stop being blind

Posted by rami on January 13, 2007 at 11:14 AM PST #

It's time to look at erlang , www.erlang.org, a language with intrinsic support for distrubuted, concurrent, scalable, fault tolerant computing. It does these things much better, Java seems to be just dreaming abt all these things. Sun , Pls wake up , the world is changing :-)

Posted by Santosh on April 30, 2007 at 05:12 AM PDT #

Post a Comment:

Comments are closed for this entry.