Friday September 22, 2006
Channeling Java SE 7
Filed under: javase7
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.
