You are currently browsing the monthly archive for July 2016.
Attendeed: Martijn Verburg, Sean Landsman, Ingo Hoffmann, Abraham Marin-Perez
- Welcomed Abraham and Ingo as new members!
- 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.
- Discussed JSRs under review and agreed to go away and do more research and send feedback to the list:JSR 380 – Bean Validation 2.0 – JSR Review
Appears on the ballot: 26 July 2016
URL for proposal:
https://jcp.org/en/jsr/detail?id=308JSR 362 – Portlet Specification 3.0 – Early Draft Review 2
Last day of review: 12 September 2016
URL for EDR 2 materials:
https://jcp.org/aboutJava/communityprocess/edr/jsr362/index2.htmlJSR 367 – Java API for JSON Binding – Public Review
Appears on the ballot: 26 July 2016
URL for Public Review materials:
https://jcp.org/aboutJava/communityprocess/pr/jsr367/index.htmlJSR 363 – Units of Measurement API – Proposed Final Draft
URL for PFD materials:
https://jcp.org/aboutJava/communityprocess/pfd/jsr363/index.html - Discussed an IP and copyright of APIs proposal that was put to the EC. Decided that further in depth study was required before commenting.
- Martijn will arrange the next meeting before the Aug 7th EC phone conference
Cheers,
Martijn (on behalf of the LJC JCP Committee)
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.
The recent interview with JAX Enter sums up the current state nicely, so I’ve repeated it here verbatim.
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.
JAXenter: How can MicroProfile push forward microservice innovation in Enterprise Java?
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!
Hi all,
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).
Cheers,
Martijn (On behalf of the LJC JCP Committee)
London Java Community 