Java 7 Developer Blog

The new JavaFX Scene Builder graphical tool for editing FXML has been released.

You can read the announcement here: http://fxexperience.com/2012/04/announcing-javafx-scene-builder-public-beta/

There is a download here: http://www.oracle.com/technetwork/java/javafx/downloads/devpreview-1429449.html#sb

Looking forward to using this on some of the new JavaFX projects we’re working on.

Hi All,  (this post is x-posted from Martijn’s personal blog and the ljc blog)

Recently I’ve received a bunch of private correspondence from people confused/worried over the change in the default Java packaging for Linux. For many Linux distributions, the official Sun/Oracle version of Java has been packaged up as the default Java for the platform. However, due to a recent licensing change, this will no longer be the case! So, is this a positive or a negative thing for the Java and open source ecosystem? Read on for my take on it  

Background

Dalibor Topic announced that With Java SE 7 and JDK 7 being released, and with OpenJDK as the official Java SE 7 reference implementation, that it was finally time to retire the non open source “Operating System Distributor License for Java” (DLJ).

What does it mean for me?

The knock on effect of this is that Linux distributions will on longer package Oracle’s Java (== OpenJDK wrapped up in some proprietary bits and pieces) as the default Java. This can/will cause problems for some Java users initially as there are a smattering of bugs (especially in the Swing UI libs) still left in the OpenJDK that affect programs like PCGen. However, some Linux distributions had already taken this path some years ago, most notably Ubuntu and the last remaining bugs are being cleaned up pretty quickly.

Positive or Negative?

Overall, I think this is a positive step in the right direction for free and open Java on Linux platforms. This sentiment was welcomed by well known open source advocate Simon Phipps in a twitter post. The fact the the OpenJDK is now the reference implementation (combined with efforts to open up the issue tracker for the OpenJDK) means that means that a vast host of Java/Linux end users can now directly improve ‘official Java’ for all of us.

Opinions and further comment is welcome!

Quite a significant milestone today – The change request to switch on Java 7′s MethodHandle and invokedynamic features by default is in. Once this propagates into the OpenJDK repositories, we will see one of the largest features of Java 7 finally land ready for use.

The details of the CR are here.

MethodHandle and invokedynamic are covered in a brand-new chapter of the book “Classfiles & Bytecode” – which will be coming to a MEAP near you very soon.

One of the most interesting things about the development of Java 7 has been the open debate around language features.

However, one of the side-effects of that discussion has been a certain amount of visible frustration from some quarters about the pace of change. The process has been criticized for being too timid, too slow, too conservative by some people. There has also been rather a lot of vitriol over the scope or non-inclusion of specific features.

Language design is hard. It’s hard to think about all possible use cases for a feature up front. It’s even worse to try to think about how your language features will interact. Very smart people get this wrong. A lot.

Now stop and think for a minute about how successful a language Java is. It’s everywhere. There are at least 1 billion Java runtimes in the world today. Millions of companies deploying Java technology and 7-8 million Java developers worldwide. Stability and backwards compatibility is a huge deal.

Consider a largeish company with, say 100-1000 developers, which is introducing a new technology platform. Empirical / anecdotal data suggests this platform will probably be in use for 7+ years. Once enterprises start using a technology, it can be very difficult to get it out again. That same company will probably also spend around $2-3 million on tooling, support, etc over the lifetime of the platform within the company. Multiplying that up by the tens of thousands of such companies that exist, gives some idea of the dollar value of the corporate Java ecosystem.

Putting all of this together, and we can easily see how bad it would be if a misfeature in the language design was allowed to escape into the wild. Once a language feature is out there, the Java community basically has to live with it forever.

This is why the caretakers of the Java language tend to take the view that Java is not the right place for language feature experimentation. Every new feature interacts with the existing “feature surface” of the language, and often in surprising ways. The place we see this the clearest in Java is with the type system.

Looking at the changes in Project Coin, the new multicatch and diamond syntax features are the places where the type system is most deeply involved, and in the formal spec for each contains a large screed of type theory.

Once those features are out in the wild, any further change will now have to deal with the larger amount of type theory that now forms part of the language standard. This acts as a constraint on further language innovation.

All of this leads to a situation whereby change has to proceed slowly and calmly. Features aren’t added lightly – and the engineers who create them aren’t idiots.

Finally – if a new feature isn’t exactly as you expect, then stop, think, take a deep breath. Think about the reasons why the feature may not be precisely tuned for your use case – and about the inevitable compromises that the new feature may represent.

Language design, like legislation, can be more about tradeoffs, compromises and the art of the possible than is sometimes recognised. When combined with the engineering and project management constraints common to all software projects, the fact that we manage to get important new features out at all starts to look like a triumph.

There’s always scope for improvement, and the JCP could use more individual end user and JUG members. If you have strong opinions about new features, or want to be more involved – then this is a great time. With Java 7 just around the corner, and the work already underway for SE 8 and EE 7, this is your chance to make your views known. Early feedback from end users on proposed features is highly prized – you just need to get involved and start contributing.

Martijn and I are at TheServerSide Java Symposium in Caesar’s Palace this week.

We’re at this afternoon’s Meet The Authors session, and we have talks tomorrow (Back to the Future with Java 7) and Martijn’s Diabolical Developer talk on Friday.

If you’re around, do come and say Hi.

Hi all,

John discovered that our instructions on the Debian (and therefore Ubuntu) install was not following the de-facto standards. In short the location of where you install the JDK has been altered for more flexibility and security. The post has now been updated with the corrected details.

I also recently discovered that the Netbeans 7.0 Beta 2 won’t always start with JDK1.6.0_24 and the -J-XX:MaxPermGen parameter. If this happens to you then you can remove the -J-XX:MaxPermGen from the %Netbeans_Home%/etc/netbeans.conf file.

Hope the Java 7 explorations are going well! We’ll be posting more code samples to run with shortly as well as a later piece on project Jigsaw (which is more Java 8, but hey!)

Cheers,
Martijn

PS: If you are interested in the book, the 50% promo code runs out on the 3rd of March, so get in fast!

Martijn and I are at the LJC OpenConference today, which is taking place at the lovely IBM offices on Southbank. Some fascinating talks today – including Steve Poole from IBM and Steve Elliott from Oracle.

Our keynote seemed to go over well.

Currently in a great entry-level technical debt reduction talk from Markus K.

Glad the snow held off a bit!

This blog is where we’ll be tracking the progress of Java 7 (and 8, when it starts to appear) towards release.

It should be an interesting journey.