what may or may not be in java 7 from the java road trip

Main menu:

Topics

Recent Posts

Blog

June 2010
M T W T F S S
« May   Jul »
 123456
78910111213
14151617181920
21222324252627
282930  

Past Posts

Java/Java EE

JDBC

Other

what may or may not be in java 7 from the java road trip

June 14th, 2010 by Jeanne Boyarsky

Oracle talked about Java 7 at the first stop of the Java Road Trip. The main speaker was Brian Goetz, author of Java Concurrency In Practice.

Despite the disclaimer that everything including syntax is subject to change, the talk was pretty interesting.  Here are my notes.  (this was largely written on my iPad; please excuse any typos)

Modularity

  • The JRE download is 13mb, but most code doesn’t get run by ordinary apps
  • The monolithic jdk makes new releases of platform take longer to roll out
  • Modularizing apps helps with jar hell and finding out at runtime that something is missing/wrong
  • Will provide mechanism for apps to express dependencies in way useful to both humans and tools
  • Based on concepts in Maven and OSGI
  • Current draft has: Module-info.java defining module and version number along with what module and versions or ranges you depend on
  • Classpath will be legacy mode, preferred mode will be to turn your app into a module

Multi lingual support

  • JVM is a managed code environment
  • Scala is a lot like java, but other dynamic languages (like Ruby) run slower because need to rely on reflection or code generation.
  • JVM is more like Smalltalk than like Java , but some places is tied to Java
  • Da Vinci machine project is targeted to adding features to better support dynamic languages. In particular dynamic method linkage which is being able to select version of method based on type of arguments
  • Invokedynamic vs invokevirtual for method selection and linking. Once calls stabilize, don’t look up in vm anymore, then inlines and is as fast as in  java.  This is a goal, need to get there.

Productivity

  • Project coin – add half a dozen small language changes to simplify everyday tasks.  Would be at  level of enhanced for loop
  1. Reduce boilerplate of generics with the the diamond operator (not really an operator)
    Map<String, String> map  = new HashMap<>();
  2. Better numerical literals to make long numbers more readable.  Similarly for binary (long string of 0’s and 1’s)
    long cc= 123_5678_567;
  3. Collection literals – declare inline like we do with arrays and hard coded data.  More declarative. Like associative array in Perl, but may not go that far
  4. Automatically close resources in try/catch.  Better idiom
    try (InputStream in = createInputStream()){
    // code that reads in from stream goes here
    } // compiler will call close for you here

Performance

  • Goal: facilitate scalability across multiple cores
  • Fork join extend recursive action to split into subtasks and join to get answer.
  • Will be added to concurrency utilities.
  • Don’t have to tell it how many cores you have
  • ParallelIntArray class automates common operations filter, map and reduce so can say what want to do declaratively

Closures

  • Saving the best for last.
  • Like anonymous inner classes but without boilerplate of anonymous inner classes
  • Still debating syntax
  • Still debating whether return type should be declared
  • Still discussing how to extend interfaces (will be used to add closures for Collections).  Options are “static extension methods” like in C# where you statically “pretend there were these methods are on the class and call the static methods instead.”  Also discussing ” virtual extension methods.”  Either way the closures project will finally address the issue of api evolution
#(int x)(x*3).domorestuff()

Comments

Comment from paul wheaton
Posted: June 15, 2010 at 2:15 pm

Oracle took orion and turned it into a turkey.

Now Oracle is fondling java and I’m nervous.

Comment from Jeanne Boyarsky
Posted: June 15, 2010 at 5:25 pm

Wait until you see the videos they posted online. “Say your name and something nice about Oracle”. It is nice to see them making an effort rather than abandoning it into neglect. We’ll see what happens.

Comment from Ajith Kallambella
Posted: June 15, 2010 at 10:08 pm

OSGI and native support for multi-core processors have been due for a long time. The new OSGI module definitions will have to co-exist with classpath-based “legacy” approach at least for a while. Will be interesting to see how this behavior gets defined in JVM specs. Devil is certainly in the details!

Overall, lots of good stuff. That said, will Oracle do justice to JCP?

Comment from Jeanne Boyarsky
Posted: June 15, 2010 at 10:53 pm

Ajith: “for a while” – if history is any indication, it’ll be forever. when was the last time Sun got rid of anything? Come to think of it, I’m not familiar with oracle’s thoughts on deprecation. I guess I’ll post on JavaRanch to inquire.

Comment from Ajith Kallambella
Posted: June 15, 2010 at 11:17 pm

Jean: What about the Java Language Specs? Have any/all of these made it in to the Spec? Will Oracle release a formal language spec for 7 so that there can be “other” implementations too?

Comment from Jeanne Boyarsky
Posted: June 16, 2010 at 9:16 pm

Ajith: Per Oracle, this is an implementation and not yet in the formal language spec. A schedule for that will be announced soon. Or rather a correct schedule; there’s one out there already that says it happened already.

Pingback from java 7 from the nyjavasig | Down Home Country Coding With Scott Selikoff and Jeanne Boyarsky
Posted: August 17, 2011 at 11:10 pm

[...] 7 has come a long way since the Java road show 14 months ago when I blogged about what may or may not be in Java 7. And not always forwards. Oracle sent Donald Smith (director of project management with some coding [...]

Write a comment