What’s Next for Java at Oracle?

The future of Java under Oracle’s leadership is one that includes continued innovation across multiple deployment areas including servers, desktops and mobile devices. That’s the message delivered by Thomas Kurian, executive vice president, Oracle Product Development during a JavaOne keynote address detailing the road ahead for Java. New graphics, performance and enhanced programming capabilities are all on Oracle’s roadmap for Java development. Oracle took over the stewardship of Java as part of its acquisition of Sun which closed earlier this year. “We’re focused on two very fundamental things with servers and desktops,” Kurian said. “To optimize Java for new application models that are emerging classes and for new classes of hardware that we see emerging.” Kurian added that the roadmap for Java development includes an effort to enhance developer productivity. Oracle’s Project Coin which is now under development, will provide improved type inferences for instance creation as well as other innovations that are aimed at improving developer productivity with more concise code. Project Lambda on the other hand will bring closures to the Java language. Kurian noted that Lambda will provide a more concise replacement for inner classes and it will support automatically parallel operations on collections. Oracle is also planning on building new modularity into the Java Virtual Machine (JVM) by way of the new Project Jigsaw initiative. “It basically means that we’re integrating a module subsystem within the JVM enabling a JVM implementer to provide a single VM that will scale all the way from a low end notebook all the way to a high-end server,” Kurian said. “For the developer it eliminates the error prone classpath and it also makes packaging and deployment of applications a lot easier.” On the desktop, Kurian said that the time has come to provide better interoperability between Java, JavaScript and HTML5. He noted that the Java client will need to be able access HTML5 content through embedded tags. Additionally, Kurian said that developers should be enabled to take a JavaFX based layout and be able to manipulate it via JavaScript providing two-way interoperability. The graphics engine is an important part of the Java/HTML5 interoperability plan from Oracle. As part of the roadmap, Oracle is developing a brand new high performance Java graphics engine called Prism. Kurian noted that Prism will be seamlessly integrated with the JVM and the Java runtime. Prism will provide developers with 2D and 3D graphics capabilities as well as take advantage of hardware-based graphics acceleration. As part of the new Java graphics push, Oracle is also positioning Java as tool for user interface design though new JavaFX features and Netbeans IDE releases set to debut in 2011. Kurian committed to making the new JavaFX user-interface controls available under open source licenses. “We want everyone to know that we want the nine million Java developers in the world to never have to choose a different environment to build a great looking UI (user interface) again,” Kurian said. For mobile developers, Kurian sees Java being deployed on all types of consumer devices. Oracle is working an effort it calls Project Java Mobile.Next to update and expand Java for mobile devices. Kurian noted that Java Mobile.Next includes updates to the language, virtual machine, libraries and APIs. Oracle also plans on further integrating web technologies into the Java ME (mobile edition) including Webkit and JavaScript. Kurian said that there will also be a Java to JavaScript bridge to make it easier to mix and match both native Java apps and web based applications. Oracle also wants to expand Java on mobile to make regular phones into smartphones. “Our view is that all devices have intelligence emerging, all of them are connected on the network and Java can run on these devices allowing you to download intelligent applications into,” Kurian said. While Oracle is helping to direct where Java is headed, Kurian stressed that Java goes beyond Oracle. “The future of Java is not about Oracle, it’s not about any specific company,” Kurian said. “It’s about you the developer community and how you make the language great and how you build great application with it.”

NULL – a magic constant

NULL is the reserved constant used in Java to represent a void reference i.e a pointer to nothing. Internally it is just a binary 0, but in the high level Java language, it is a magic constant, quite distinct from zero, that internally could have any representation.

If

x.doSomething();

and x is null, you will raise a java.lang.NullPointerException. Note Null PointerException, not Null ReferenceException.

The difference between a null reference and a reference to an empty object, (e.g. a freshly minted default object, empty collection or empty Iterator) is a major headache in Java. When dealing with other people’s code I want to strangle them. Why won’t they tell me when a method might return null or empty? Why won’t they tell me if a method can’t accept

if ( x != null )
   {
   x.doSomething();
   }

must be the most common Java code fragment. I wish there were some more elegant way to handle this, that gives you the speed and space conservation of null, without the coding overhead bubblgum of checking for it at every turn. I have five solutions:

  1. Don’t return Lists from your methods; return Iterators instead. This way you can return the empty Iterator. The Iterator’s consumer does not need to deal specially with the null case. You don’t need the overhead of cloned empty List objects.
  2. Create a singleton empty prototype object for each class that you pass around to act like null. The catch is, it may actually need to be a subclass so that its methods don’t actually do anything. You have to make sure nobody modifies the empty object. You can safely call methods on this object and nothing will happen. You can safely retrieve its empty/default-value fields. You would need an amanuensis to compose the code for such objects. The effort of composing them manually would be even more work than dealing with null. Using this technique would be more robust however. You would make all methods final so that they would inline down to nothing. This would be even faster than checking explicitly for null! Null is typeless. Empty objects are typed. This may or may not be considered a Good Thing™.
  3. New Java syntax to insert if (x != null) more tersely: e.g. t!.doit(); is the same as if (t != null) t.doit();.
  4. Use rigid Javadoc conventions to track whether a method consumes/produces null references, empty objects, or blank Strings.
  5. Simply ignore java.lang.NullPointerExceptions. The catch is, there is no way to do that in Java. You can’t just ignore them and return to the code just after the call. You can’t turn them off. This would require a new language where NullPointerExceptions are simply treated as no-ops.