Wednesday Feb 05, 2014

InvokeDynamic and Java EE?

“Man cannot discover new oceans unless he has the courage to lose sight of the shore.”
(André Gide)

JSR 292 (Supporting Dynamically Typed Languages on the Java Platform), introduced in Java SE 7, is about simplifying and improving the support of dynamically typed languages on the Java Platform. JSR 292 defines a new bytecode, i.e. InvokeDynamic, that allows the execution of method invocations in the absence of static type information. So it is clearly the first bytecode that has been designed for dynamically typed language and not for the Java language.

Project Nashorn, Java 8's new JavaScript engine relies heavily on InvokeDynamic. In Fact, originally Nashorn 'was just' an InvokeDynamic Proof of Concept. The PoC was successful and Nashorn has, since then, evolved into a high-performance 100% ECMAScript compliant engine.

Despite the fact that InvokeDynamic was originally conceived for dynamically typed languages, it turns out that this bytecode could also be useful for the Java language itself. For example, Java SE 8's Lambdas are using, under the hood, InvokeDynamic.

Antoine Sabot-Durand, CDI co-spec lead, is currently conducting some experimentations around using InvokeDynamic to replace Weld's proxies. At this stage, it's just an initial Proof of Concept but it works! If his efforts goes to fruition and since Weld is the CDI Reference Implementation and is used by different Application Servers (JBoss AS, WildFly, GlassFish, WebLogic...), who knows, we might get, and not just for Lambdas support, InvokeDynamic under the hood of some Java EE Application Servers. Only the future will tell us!

Wednesday Jul 06, 2011

Reminder - Java 7 launch in 24 hours

Remember that the Java 7 launch, dubbed "Java 7, Moving Java Forward" is set for tomorrow, July 7th. In fact, in 24 hours (9am PT) you'll be able to join a live webcast.

Moving Java Forward

This live event will be hosted by Adam Messinger (Oracle) in Redwood Shores, Bruno Souza (SOUJava) in São Paulo and Ben Evans (LJC) in London. You can register for the webcast or for the in-person events from this page. The twitter hashtag for this launch is #java7.

You can also listen to the latest episode of the Java Spotlight Podcast (#37) featuring an interview with Michelle Kovac on this Java 7 Launch where she mentions Accenture, Travelex, Riot Games, HP and others as heavy Java users and participants to the live events.

The final Java 7 bits should be available on July 28th as planned.

Thursday Nov 18, 2010

Majority or 2/3rds? The JSR Inception Votes by the EC

The Java Community Process 2.7 gives the Executive Committee the responsibility to "Select JSRs for development within the JCP", as in the case of the 4 JSRs that Oracle just submitted: 334 (Coin), 335 (Lambda), 336 (Java SE 7) and 337 (Java SE 8).

Yesterday I tried to explain how the rules work but I had to correct the section twice, so here it is again after talking with the PMO (Patrick Curran):

Applying the voting rules to the quartet, we have:

  • Coin and Lambda require that
       2/3rds of the votes cast are YES, there is a minimum of 5 YES votes, and Sun/Oracle must vote YES.
  • Java SE 7 and Java SE 8 require that
       2/3rds of the votes cast are YES, there is a minimum of 5 YES votes, and Sun/Oracle must vote YES.

Yes, the same rules for the 4 JSRs.

The rationale is that Coin and Lambda propose changes to the Java language, and that since Java SE 7 and Java SE 8 include them, they also change the language. The process document is a bit ambiguous about this and Patrick said they would clarify it for the next revision.

Wednesday Nov 17, 2010

How to Read a JSR

As promised, here is a basic Reading Guide to a Java Specification Request (JSR). Technical terms are described in the JCP process (current version is 2.7); the initiation process is in Section 1. I've added some historical background and context.

Examples and comments are as applied to the 4 JSRs just submitted: 334 (Coin), 335 (Lambda), 336 (Java SE 7) and 337 (Java SE 8)

Caveat! I do not work for the JCP office and if there are any discrepancies between the excerpts below and the JCP Document, the official rules win, hands down!

The Submitting Member is the JCP member that is submitting the JSR; for these 4 JSRs, it's Oracle.

The Specification Lead is the JCP member, or the employee of a JCP member that will lead the Expert Group. In our case they are: Joe Darcy (Coin), Brian Goetz (Lambda) and Mark Reinhold (Java SE 7 and Java SE 8).

Coin targets Java SE 7; Lambda targets Java SE 8.

The Initial Expert Group Membership is an initial list of JCP members that have already expressed interest to the EG Lead to participate in the EG. Normally that list is expanded further before the EG starts working.

Increased Transparency was one of the drivers for JCP 2.7 and each JSRs must include a description of how transparency will be achieved in the EG in that is in Section 2.15. The new transparency requirements and infrastructure means that interested parties can follow the activities of the EG without being a member of the EG.

Every JSR has a link to a form to nominate experts to an EG; for instance this one is for Coin. The EG lead decides who to accept; normally it needs to balance representation and expertise with manageability.

The Supporting This JSR section lists JCP members that support the initiation of the JSR. Normally, but not always, these members will also be in the Initial EG Membership. It would be reasonable to expect that EC members that support a JSR will vote for it, but, AFAIK, there is no requirement for that.

Section 2.2 indicates the target platform and section 2.4 what Executive Committee will vote on the JSR. All 4 JSRs will be voted by the SE/EE Executive committee - see the results of the most recent election.

The JSR review is a 2 week period when anybody can review and comment on a new JSR. Comments can be posted through a BBoard; for example this one is for Coin.

EC voting is described in Section A.5; refer to it for a full description but, in a nutshell:

  • "A.5.3 EC Members may cast two types of votes: "yes" and "no". Alternatively, a Member may explicitly abstain or, in the extreme and undesirable case, not vote at all."
  • "A.5.4 Only "yes" and "no" votes count in determining the result of an EC ballot"
  • "A.5.5 Except where noted otherwise in this document, EC ballots are approved if (a) a majority of the votes cast are "yes" votes, and (b) a minimum of 5 "yes" votes are cast. Ballots are otherwise rejected.
  • "A.5.9 EC ballots to approve UJSRs for new Platform Edition Specifications or JSRs that propose changes to the Java language, are approved if (a) at least a two-thirds majority of the votes cast are "yes" votes, (b) a minimum of 5 "yes" votes are cast, and (c) Sun casts one of the "yes" votes. Ballots are otherwise rejected."
  • Note that there are a number of other rules described in that section.

Applying the voting rules to the quartet, we have (I'm awaiting confirmationCorrected!):

  • Coin and Lambda require that 2/3rds of the votes cast are YES, a minimum of 5 YES votes, and Sun/Oracle must vote YES.
  • Java SE 7 and Java SE 8 require that 2/3rds of the votes cast are YES, a minimum of 5 YES votes, and Sun/Oracle must vote YES.

Ballot Results will be posted at the JCP site, in the JCP Blog, and in the JCP Announcement Board. We will also post an update here, at TheAquarium.

I think this covers the basics. Check out the full JCP 2.7 process if you want all the details!

Added - I talked with Patrick Curran to confirm under what rule each JSR falls. Since Coin and Lambda have language changes, they require 2/3rds, and since Java SE 7 and 8 include Coin and Lambda, respectively, they also require 2/3rds.