Category Archive

We voted “Yes” for the re-submission of this specification within. Jigsaw and Java 9 will represent a solid foundation for a new evolution of the Java platform, one that is nimbler, more lightweight and more secure. Is this work complete? No, there are still outstanding issues and feature requests to go, especially as the ecosystem learns to use the new modulepath and friends. But the basis is sound and we think a large minority will take up the new module system once Java 9 goes GA.

We voted no the first time around because we wanted to see final consensus on the last few outstanding issues as well as some bedding in time of recent, far-reaching consensus decisions.

Our official comment

The LJC votes yes and echos IBM’s thanks to Oracle (as the specification leader) and those in the JSR 376 Expert Group who dedicated their time to reworking and clarifying areas of the specification that we were concerned about.

The disposition of outstanding issues as agreed amongst the Expert Group was handled really well and it was heartening to see the evident collaboration as described in the detailed minutes of the EG’s meetings in the past month.

We see this release of JPMS as the strong foundation for a new Java SE platform architecture, and expect to build upon this with feedback and experience from Java User Group members.

Further Notes

The specific technical details of what was agreed and what was deferred are in the minutes:

Agreement on rules around Automatic Module Naming and a guide on how to best use those (important for the Maven ecosystem).

Dealing with multiple versions of the same module was deferred.

Agreement on relaxing Strong encapsulation as a default (means fewer apps will break out of the box, but get a warning instead).

Tidying up on some keyword usage (allowing the Eclipse compiler to be built).

We think the Spec lead and EG did a great job in coming together to resolve the outstanding concerns and hope that this can be a model for further collaboration over particularly far-reaching / complex part of the Java ecosystem development going forwards.

We voted No because we want to see final consensus on the last few outstanding issues as well as some bedding in time of recent, far-reaching consensus decisions. No we don’t think this should or will delay Java 9 significantly, we expect a re-submission and eventual “Yes” vote to this specification within 30 days, please see the JCP Process Document for how this works. No, we don’t think JPMS/Jigsaw is fundamentally flawed. Yes we want extra time and thought going into JPMS by the wider ecosystem (and its authors) as this new module system will impact Java far more than the move to generics in Java 5.

We echo SAP’s comments in that we absolutely recognize the tremendous achievements and the great work that has been carried out until now by the EG members as well as (and especially) by the Spec Lead himself.

The LJC is voting “No” on the spec *as it was submitted* at the start of the voting period. During the 14 day voting period, great progress was made by the Spec Lead and the EG to reach consensus on some very difficult issues such as #AutomaticModuleNames. However, there are still on going conversations on some of those issues and there simply has not been enough time spent by the ecosystem to discuss some of the new designs in enough depth or enough time spent implementing and testing prototypes based on the latest spec, e.g. The Eclipse ejc compiler or the latest Automatic Module Naming design in Maven.

If required, we very much look forward to being able to vote ‘YES’ in <= 30 days on a version that has had that little bit of extra time for the EG (and the ecosystem) to discuss / implement / test some of these difficult spec items. Certainly the last 14 days have shown that consensus can be reached even when viewpoints have started in opposing corners, and we think another short time period to really bed in the last sticking points is needed.

Further Notes

We voted “No” based on careful technical analysis of JPMS, the RI (Jigsaw), comments on the mailing list as well as out in other public forums. We then put the existing specification to the test on a Java 9 hackday along with the Virtual JUG and ~15 JUGs worldwide. The conclusion was that JPMS still has some outstanding issues to be resolved or issues that (despite having recent resolutions), were still not bedded in the minds and/or prototypes of the larger ecosystem.

For our membership, interoperability with the Maven build ecosystem and the ability to build an alternative compiler implementation (i.e. Eclipse’s ejc compiler) is paramount. Although consensus is rapidly forming around those two items, our membership felt that they needed some extra time before they felt comfortable with voting “Yes”.

This is what the JCP is for (no, not just politics)

Casual observers and some parts of the tech media will likely come to the conclusion that this is all just about big company politics. Recent public blog posts and open letters will have fuelled that sentiment, but we urge people to read the comments accompanying “No” votes.

Although Oracle are the stewards of Java, the JCP Executive Committee (EC) is meant to act as guide for the Java ecosystem as a whole and we feel strongly that it is working as intended in this case.

What next?

The Spec Lead (Mark Reinhold) has publicly stated that if it needs more time, then it will get more time, so we expect to see a revised spec within the 30 days and expect to vote “Yes” in good conscience and not delay Java 9 (the spec).

Martijn’s Personal View

There was a lot deep dive technical analysis and tough discussion in the past two weeks with a lot of smart, passionate technologist’s who all love Java. This cannot be a bad thing :-). That said, I’m tired and will now have a sleep before Devoxx UK!

Discussed JSR 363 – Units and Measures. Omar pointed out that it looked good overall but he had some concerns about the verbosity / boilerplate nature of having to use Factories and Builders in order to get going. He noted that the Java 6 compatibility made sense (IoT, Android and other older platforms). Martijn commented that DI of some sort might help tackle the verbosity, but that the Spec Lead and EG had likely discounted that in order to allow it to be used across a wider set of projects. Omar will send in final feedback by Sunday the 7th.

Discussed the vote for JSR 380 – Bean Validation 2.0. Unanimous yrs, Ingo noted it was early stages and that we should have a more careful review when there was the beginnings of a RI.

Discussed the vote for JSR 367 – JSONB – Group looked at outstanding issues and send a message to the Spec Lead over a concern that JSONPointer support had not been addressed. Will wait until Sunday evening (7th) before casting final vote.

Discussed nominations for JCP awards. Unit of Measure and Jigsaw seemed to be the outstanding JSRs, more research required on the Adopt a JSR award.

Martijn will give feedback at the next meeting about the Aug 7th EC phone conference, covering Java EE 8 as Oracle sees it.

Discussed MicroProfile.io and status of JavaEE 8 – the LJC will officially support MicroProfile and run hackdays against vendor implementations of the profile. The LJC is waiting until JavaOne in Sept to see what is happening with Java EE 8 but hopes that Oracle will join the collaborative MicroProfile effort.

TLDR: Go to microprofile.io and join the mailing list there and fill out the survey!

Recently the LJC officially put its support behind MicroProfile, a new open source project and collaborration between Java EE vendors and the developer community to provide enterprise developers comfortable with Java EE a way to move into the microservices space. The LJC will host hackdays as Microprofile gets closer to its first GA release in September 2016.

JAXenter: Red Hat, IBM, Tomitribe, Payara and the London Java Community joined forces to create MicroProfile. What are the objectives of this initiative?

Martijn Verburg: The initial goal is to provide developers who are most comfortable with enterprise Java (Java EE if you will) a starting point to work with microservices in a non vendor specific way (which is what they’re used to from the Java EE world). The aim is then for the developer community to actually drive what they feel they need in microservices runtime/API, so instead of the vendors ‘guessing’ that you might want security, or logging or discovery or whatever. It’ll be up to the MicroProfile community to help define what should go in and what should stay out.

Some open standards will likely fall out of this to give businesses confidence about the longevity and the vendor neutrality, which is something they’ve enjoyed and trusted from the Java EE ecosystem.

JAXenter: What is the London Java Community’s take on the current state of Java EE? How can MicroProfile bring it forward?

Martijn Verburg: Java EE has clearly stalled with the lack of progress on Java EE 8. Although many of us feel that the time for the monolithic Java EE platform standard is possibly over, there’s still enormous value in having standards around key pieces of Java Enterprise technology. Enterprise Java does after all still drive billions of dollars worth of IT business and directly or indirectly drives trillions of dollars in the global economy.

JAXenter: How is the goal of MicroProfile different from Java EE Guardians’? What is the London Java Community’s contribution to this new initiative?

Martijn Verburg: The goal of MicroProfile is to bring collaboration around microservices for enterprise Java developers. This is very separate to the Guardians group, who are advocating Oracle to put resources back into the Java EE 8 platform.

Martijn Verburg: By asking the community what they want and releasing early and often. Then standardizing on what the community and the vendors feel are the right APIs that need longevity.

JAXenter: Do you hope to generate a reaction from Oracle?

Martijn Verburg: We hope they join in the initiative! Oracle has shown that it can lead in open source via OpenJDK and we know that like all vendors, they have an interest in microservices. Some common ground between all of the vendors and the community will help ensure that enterprise Java is well placed for the challenges going forwards.

JAXenter: How can the community participate in the MicroProfile effort?

Martijn Verburg: By going to microprofile.io and joining the mailing list there, filling out the survey and shortly contributing code!

We’ve been remiss in posting our thoughts on our official votes for various Java standards that go through the Java Community Process (JCP) Executive Committee (EC). So in order to get back into the swing of things we thought we’d start with the all important Java 9 SE vote!

For JSR 379 – Java SE 9 (See full results from all voters) we voted Yes for the JSR Review Ballot with the following comment:

We are very happy with the technical content and have high hopes that it will increase the longevity of Java in the age of containers and smaller devices.

We are disappointed with the relatively late release of this JSR. Since much of the RI and TCK has already been built, it makes it much harder for independent implementations to reach the market in a timely manner.

We see that Red Hat, IBM, Google and Oracle will likely make up the EG and we hope to also see wider participation from other JVM vendors.

In terms of technical merit we’re broadly happy. There are certainly issues with Jigsaw vs the ‘real world’, which was anticipated and hopefully will be mitigated by further early testing of JAva 9 and some compromises made by both the authors of libraries, frameworks and products and the authors of the Jigsaw module system. The rest of Java 9 offers up loads of exciting new features including HTTP 2 support, JShell and a host more.

To add some further insight on the other half of our comment, we need to explain the current challenge we have with OpenJDK vs the JCP standardardization process. In short, OpenJDK is the GPLv2 licensed open source project that is the Reference Implementation (RI) for Java SE. Oracle and most (not quite all) other vendors create their commercial ‘Java’ releases from OpenJDK.

However, in order to release a ‘Java’ which can be called Java, you must pass the Technical Compatibility Kit (TCK) which is produced as part of the Java Specification Request (JSR). If the JSR is delivered late on in the development of OpenJDK it puts vendors who produce a non OpenJDK based implementation at a massive disadvantage and even puts the vast majority basing their implementations off OpenJDK at a disadvantage in terms of getting their product complaint and to the market.

There’s also no real mechanism for the community to push back against proposed changes via the JCP, as so much work has already been done in OpenJDK. That is, what’s in OpenJDK is effectively fait accompli. That’s not necessarily a bad thing as OpenJDK generally speaking provides that highly collaborative open source environment which allows for plenty of community feedback and influence (it’s still nominally Oracle controlled, but it’s about as good as you can get given single vendor ownership).

It does place OpenJDK and the JCP at odds though and we look forward to working with Oracle and the JCP to resolve that (there are some early proposals being discussed).

After much thought and consideration the LJC JCP Committee have cast their votes for the JCP elections (Look for the Executive Committee Elections link at jcp.org). We’re making our vote public and will give our reasons according to the openness and transparency requirements for the committee.

The list of nominees for the seats are as follows (link also contains useful recordings and notes from the nominees):

There are 8 ratified seats and 5 open seats up for election. Although it may seem like the ratified seats are shoe-ins since to the number of candidates == the number of available seats, enough no votes can make a candidate ineligible to take the seat.

In short, we think Oracle have chosen well and see no reason not to ratify these candidates.

Open Seat Vote

This was a very close vote as the strength of candidates was unprecedented. Here are our yes votes:

Azul Systems – Azul is one of the few JVM vendors out in the marketplace. Their inclusion is vital in order to keep Java SE as an open standard and Gil Tene’s insights around thorny legal issues have proved to be invaluable to the EC.

ARM Systems – The world needs Java to run well on ARM, they should be involved in evolving Java, simple as that!

Hazelcast – Represent both strength in the EE space (JSR 107 and 347 for caching and distributed data grids) and also push the SE envelope with the requirements for their core product. Greg Luck is a long time experienced member of the JCP process, his expertise would be welcome.

Waratek – Bring innovative new thinking about the JVM with regards to scalability and security in cloud environments with their multi-tenanted VM. As with Azul, it would be great to see other JVM vendors on the EC to keep help keep Java modern.

Morocco JUG – Representing the voice of developers in the Middle East and Africa. It’s estimated that a majority of new developers will come from these nations over the coming years and so they should continue to be included at the highest levels of Java.

Geir Magnusson Jr – Geir was instrumental in helping shape Java in the early years of its existence and brings a wealth of experience and understanding of the broader Java ecosystem. It’s great to see him back!

There were lots of other worthy candidates, but we feel these 5 candidates represent the best balance to face the challenges of the industry in 2015.

Summary

Although the Committee has voted for and endorsed these particular candidates, any LJC member who is also a JCP member can (and no doubt will!) vote any way they wish to.

The LJC is voting No on the Final Approval Ballot for JSR 48 (WBEM Services Specification). As this decision may surprise the community, we wanted to ensure that the reasons behind this are fully understood.

The No vote is purely a procedural measure. During the discussion of this JSR, it came to light that the license that the Reference Implementation conflicts with the terms of the JSPA and is therefore not valid. Were the Final Approval Ballot to pass, the resulting standard would be impossible to implement and useless to the community.

The LJC, along with IBM, SAP and the JCP PMO, met with the Spec Leads and resolved the issues around licensing. The EC has agreed that the Final Approval Ballot must fail, and EC members will accordingly vote it down. The JCP process contains a contingency measure for circumstances like these, known as a Final Approval Reconsideration Ballot.

This Ballot allows the Spec Leads to correct any problems & resolve concerns before resubmitting within 30 days – effectively a second chance. The Spec Leads indicated that they intended to do so, and to resubmit the JSR with a modified RI license.

During the meeting with the Spec Leads, some ecosystem questions regarding the health of the ecosystem for this technology, and the number of participants were also addressed. The Spec Leads were able to point to a wide variety of companies and projects participating, so on this basis, the LJC is happy to support this JSR.

A number of minor technical questions were also discussed – and the Spec Leads agreed to address some of them by releasing the source code for the TCK for this JSR – and to produce a new JSR for a version 2.0 after the initial release to fix any bugs found by the community.

The LJC JCP Committee would like to thank the Spec Leads for making time to meet and address concerns at very short notice, and for their perseverance in completing the JSR process.

As always, if you’re an LJC member and interested in our work in the standards & specification space – please contact one of the committee – we’re very happy to talk about our ongoing projects, and there are always ways to get involved.

Disclaimer: This post is written by developers to demystify the process and some of the differences between the JSPA (Java Specification Participation Agreement) and the OCA (Oracle Contribution Agreement). Both of these may have legal implications to intellectual property rules that might be written into your employment contract. If you are in any doubt please seek legal advice before signing one of these contracts, the last thing either you or the community wants is for you to find yourself in a legal conflict.

If you are thinking about contributing to Java there are two levels on which you can get involved. Depending on what you want to contribute you will need to sign either one or both of the JSPA (Java Specification Participation Agreement) or the OCA (Oracle Contribution Agreement).

The JSPA enables you to contribute to JSRs and sit on the expert group of individuals representing that change.

Your employer may have already signed the JSPA, in the first instance you should check with them as you might already be covered for your participation by their contract.

If your employer hasn’t signed the JSPA, you will probably want to participate as an individual (there is a cost associated with company memberships, however an individual membership is free of charge).

Your employer needs to agree with you signing the JSPA (even as an individual) and your employer needs to sign your individual JSPA paperwork. Note: the signature needs to meet certain standards – if you’re not sure you need to look at the Oracle website, especially if it’s a squiggle! (from experience)

I worked for a large investment bank and this was not a problem to be signed off by the legal team, but it did take around a month. So if you are thinking of participating in a JSR it’s a good idea to get this signed off early.

Once you send to Oracle the process is usually fairly quick to resolve, you can either fax (if that still exists where you are) or E-Mail each of the pages back as a PDF.

OCA

The OCA is required for direct code based contributions that are to be checked in to Java. It is a short single page document.

If you’re working on Open JDK and your work is approved for submission you will need to have one of these.

The essence of this agreement is to share the ownership of the change between yourself and Oracle.

If you’re thinking about taking this path it’s only a simple one page document that is quick to complete, so I recommend doing this upfront.

If you are going through your employers approval process it is potentially a good idea to try get both of these agreements signed off at the same time if you need to.

One final thing to note is that you can still attend hack days and bug fixing days without having the above signed, so if you’re not sure about how to get started, a hack day, Adopt-A-JSR or Adopt Open JDK is for you.

As mentioned in a previous post the committee is very pleased to have been re-elected to sit on the JCP committee. Everyone who works on the LJC committee does this voluntarily and in their spare time. Naturally as other commitments come around for personal and/or other opportunities we always welcome new faces and bid farewell to those who have contributed.

On this occasion, Richard Warburton is stepping down from the LJC JCP to focus on other initiatives within the Java community. Richard has worked on countless initiatives within the LJC JCP and first became interested in the cause when he first moved to London and met Jim Gough in a bar at the monthly developer sessions. Since then he has significantly contributed to both project lambda for Java 8 and the Date Time API, also for Java 8. Working with the rest of the committee Richard helped to setup sone of the corner stones that launched the Adopt-a-JSR initiative and running hack days in multiple countries. It is fair to say that Richard has aided the delivery of Java 8 and many of its newer features.

Richard is well known to the spec leads of the major JSR projects due to his insight and feedback into the development of the features. Although Richard is leaving the LJC JCP group he will still be actively involved in the community and through the Adopt-A-JSR program.

We would like to thank Richard for all his hard work and wish him all the best for the future.

Jim Gough on behalf of the LJC JCP Committee

Advertisements

What is the LJC

The London Java Community (LJC) is a group of Java Enthusiasts who are interested in benefiting from shared knowledge in the industry. Through our forum and regular meetings you can keep in touch with the latest industry developments, learn new Java (& other JVM) technologies, meet other developers, discuss technical/non technical issues and network further throughout the Java Community.