X
FEATURED POST

Moving Forward with Eclipse GlassFish at Jakarta EE

In our last blog on Jakarta EE we discussed that moving Java EE technologies to Jakarta EE was a huge undertaking. We have made enormous progress over the past...

Recent Posts

Community

Background on Oracle’s contribution to Jakarta EE

  Today, the Eclipse Foundation is making a number of community updates on Jakarta EE, the brand under which Java EE 8 technologies will evolve to meet the requirements of cloud native Java. Check out the new Jakarta EE website and the results of the Jakarta EE Community Survey. With the updates begin delivered today, we thought it would be useful to provide an update on Oracle’s contributions so far to this project. As described in prior blogs, Oracle is contributing its Java EE 8 technologies to this effort – specifically: Source code for Oracle GlassFish 5.0, the reference implementation (RI) for Java EE 8 Sources for the Oracle Technology Compatibility Kits (TCKs) used to test for Java EE 8 compatibility Product documentation.    Oracle's efforts so far have focused on the contribution of Oracle GlassFish 5.0 and TCK sources to the EE4J project at the Eclipse Foundation, which will ultimately be used to build and test “Eclipse GlassFish”. On an ongoing basis, Oracle reviews Oracle GlassFish source repositories on GitHub for their readiness to be contributed. As these reviews near completion, Oracle proposes EE4J sub-projects that correspond to Oracle GlassFish 5.0 components. These sub-projects and repositories are created after Project Management Committee (PMC) and community review. Oracle then submits the sources themselves to the Eclipse Foundation, with new licensing, where they are reviewed and eventually published in EE4J sub-project repositories on GitHub    This project is being managed and executed by open Eclipse community processes. You can track the progress of this effort at the EE4J Project Bootstrapping status page. The page reports planned EE4J sub-projects, and the status of sub-project creation and source code submission. This status includes status of Oracle’s contributions, as well as the status of Ozark, the reference implementation for MVC 1.0, for which Ivar Grimstad and Christian Kaltepoth are the spec leads. To summarize, as of today, as part of this process: 34 EE4J sub-projects have been proposed for review. Together these sub-projects represent most of the GlassFish Reference Implementation, including the GlassFish project itself, most of the major GlassFish components, and a project for the TCK contributions.  20 EE4J sub-projects have been created. These are projects that are ready to receive Oracle contributions. 15 source contributions for these EE4J sub-projects have been delivered to the Eclipse Foundation.   These include major Oracle Java EE 8 technologies, such as Jersey (JAX-RS), Mojarra (JSF), Tyrus (WebSocket), Open MQ (JMS), EclipseLink (JPA), JSON-P and JTA 13 sub-project source repositories have been populated This process of contributing Oracle sources will continue. Our goal, subject to change, is to have all of Oracle’s GlassFish 5.0 sources contributed by July, so that an Eclipse GlassFish implementation, that is compatible with Oracle GlassFish 5.0, can be built from EE4J sources and certified as Java EE 8 compatible using the Java EE 8 TCK binaries. In addition, with the sources for the Java EE 8 TCKs delivered to the Eclipse Foundation to the “Jakarta EE TCK” project, we hope these tests can be evolved to provide Jakarta EE compatibility tests, as determined by the Jakarta EE community. In short, we are well on our way to making the contribution we proposed last September a reality. We’d like to thank the Eclipse Foundation, the Jakarta EE Working Group, the EE4J PMC, and the entire Jakarta EE community for their support, and look forward to evolving these technologies for cloud native Java under the Jakarta EE brand.

  Today, the Eclipse Foundation is making a number of community updates on Jakarta EE, the brand under which Java EE 8 technologies will evolve to meet the requirements of cloud native Java. Check out...

Community

The road to Jakarta EE

Today, the Eclipse Foundation is making multiple announcements related to Jakarta EE that includes the unveiling of https://jakarta.ee and the Jakarta EE logo, the results of the developer survey, etc. It's probably a good time to reflect on how we got here... End 2016, early 2017, I was jokingly using the following slide when I was discussing Java EE.  I am relatively confident that at that time no one would have predicted what would happen. You have to remember that during that period, things were not so simple for Java EE as questions were raised about the future of the platform. At that time, Oracle along with the different JCP experts were focused on finalizing Java EE 8 and its various APIs.  Relatively soon in the process we also started to think about the future of the platform, i.e. ‘Java EE Next’ as we informally called the post-Java EE 8 era. The Java EE 9 plans that were shared at JavaOne 2016 weren’t particularly well received so we went back to the drawing board. It was clear that we had to do something radically different to get the Java EE ecosystem excited and engaged again.  To lift all the concerns that were raised on Java EE through the years, we thought that the platform should, from that point on, evolve in a more open fashion and at a more rapid pace. It was clear that the platform had to adopt an open source model including a well-established governance. Early in those reflections, Oracle along with some key players from the ecosystem, namely Red Hat and IBM, decided that the Eclipse Foundation would be the obvious venue to host this radical evolution. One of the many reasons is that the Eclipse is already hosting the MicroProfile.IO project, which is itself augmenting the Java EE platform with capabilities geared towards Microservices Architecture. Shortly after that, additional Java EE players such as Tomitribe, Payara and Fujitsu joined the initiative. And that’s in a nutshell how EE4J Jakarta EE came to life. Transitioning the development of the platform to the Eclipse Foundation is a huge undertaking. It involves many technical and non-technical aspects including complex legal issues that I won’t cover here given IANAL! In addition, we are not talking about a small project; we are talking about a large collection of established projects that includes GlassFish, Jersey, Grizzly, Mojarra, Open MQ to name just a few. And that’s not all, there are also all the activities related to the opening of the various TCKs. It is simply a huge effort and probably the largest project that the Eclipse Foundation has ever embarked on (see here for some background). This is one of the reasons why it was decided early on that Jakarta EE would use Java EE 8 as its baseline and that older versions of the platform would not be part of Jakarta EE; that approach was simply reasonable and pragmatic. All these efforts are happening as we speak. While we would prefer the work to be behind us so that we can effectively focus on evolving the Jakarta EE platform, we still have to wait for everything to be in place. On that note, I have recently received the following mail from a well-known community member.  We were discussing a matter unrelated to Jakarta EE and while I sincerely appreciate the gratitude from that person, I really need to stress something about the whole Jakarta EE effort. Some of us are clearly more visible in the community (ex. Dmitry Kornilov who represents Oracle in the PMC and me as an evangelist) but Jakarta EE is really a team effort on the Oracle side. There are many people who are working behind the (Oracle) scene to transition Java EE to the Eclipse Foundation. It is impossible to mention all my colleagues that are, closely or remotely, involved in this effort. The list is simply too long and I don't want to take the risk of omitting someone. I, however, want to publicly acknowledge the work of Ed Bratt, Will Lyons, and Bill Shanon who deserve a particular mention as they have been working tirelessly since the early days of this effort to make sure Jakarta EE happens! So thanks to you all! You should also realize that usually when a project is open-sourced, all the related activities, including all the legal aspects, are happening upstream and it is only when everything is discussed, agreed and done that the project is made public. But early on, we have decided to be as transparent as possible, which is why we have announced our initial intent last summer. At that time, lots of things were not decided yet and that lead us to where we are today, i.e. in the early days of Jakarta EE including the creation of a new but already actively engaged open-source community. A lot of work still needs to happen to properly tackle the ultimate goal of Jakarta EE, i.e. evolve the platform towards an open-source and Java-based, Cloud Native foundation that will be relevant for the next decade. The Jakarta EE community is actively working towards that goal and today's announcement represent an important initial milestone!

Today, the Eclipse Foundation is making multiple announcements related to Jakarta EE that includes the unveiling of https://jakarta.ee and the Jakarta EE logo, the results of the developer survey,...

Eclipse

EE4J: An Update

  Mike Milinkovich of the Eclipse Foundation has recently posted a blog providing an overall update on the status of the project. To summarize: We are working on defining a new brand name using the community process described here. We have begun the process of moving Oracle GlassFish sources to the EE4J project. So far, Oracle has contributed sources for the following projects:   Eclipse Grizzly Eclipse OpenMQ Eclipse Project for JAX-RS Eclipse Project for JMS Eclipse Tyrus Eclipse Project for WebSocket Eclipse Project for JSON Processing In addition to the above: The Eclipse Yasson and EclipseLink projects have been transferred to EE4J, and are now part of the overall EE4J project. We have created Eclipse Jersey and Eclipse Mojarra projects and are working on contributing sources for these. You can watch (and star!) EE4J project repositories as they are being created in the EE4J GitHub organization. Oracle is working on Eclipse project proposals for all of the technologies Mike mentions in his blog: JSON-B API, Concurrency, Security, JTA, JavaMail, JAX-B, JAX-WS, JSTL, UEL, JAF, Enterprise Management, and Common Annotations. We intend to formally propose these projects to the EE4J Project Management Committee (PMC) very soon. One of our major near-term goals is to transfer all of the Oracle-owned GlassFish technologies to EE4J such that we can build "Eclipse GlassFish" from EE4J sources and demonstrate Java EE 8 compliance. We are working on establishing an Eclipse Foundation working group to provide a member-driven governance model for EE4J. In short, there is a lot of positive progress being driven in the EE4J project. For further updates refer to this blog and the links provided above, or subscribe to the ee4j-community mailing list.

  Mike Milinkovich of the Eclipse Foundation has recently posted a blog providing an overall update on the status of the project. To summarize: We are working on defining a new brand name using the...

Community

Java EE 8 @ JavaOne 2017

JavaOne is almost upon us again! Obviously, Java EE will be well covered. Here is a selection of some of the Java EE 8 related sessions (technical sessions, panels, BoFs, etc.). This is just an excerpt so make sure to browse the full session catalog. Also, if are attending JavaOne, make sure to visit the Developer Lounge,  there are many cool new stuff to check and some of us will be around and available to chat. Please do note that you will need to bring your own laptop for most of the Hands-on-Labs (including "Java EE 8: Hands-on with the New Features [HOL1671]"). Sunday, Oct 01 Rapid Development Tools for Java EE 8 [CON3883] 2:00 p.m. - 2:45 p.m. | Moscone West - Room 2008: NetBeans Track Powerful Lessons from Top Java EE Experts [CON7624] 4:00 p.m. - 4:45 p.m. | Moscone West - Room 2002: Java User Group Track Monday, Oct 02 Java EE 8: Hands-on with the New Features [HOL1671] 8:30 a.m. - 10:30 a.m. | Hilton San Francisco Union Square (Lobby Level) - Golden Gate 4/5 Java EE 8: What’s New in the Java EE 8 Release [CON2661] 11:00 a.m. - 11:45 a.m. | Moscone West - Room 2020 Servlet 4.0: A New Twist on an Old Favorite [CON2022] 12:15 p.m. - 1:00 p.m. | Moscone West - Room 2020 Java Keynote [KEY7692] 2:00 p.m. - 4:00 p.m. | Moscone North - Hall D Opening Up Java EE: Panel Discussion with Oracle, IBM, Red Hat, and the Eclipse Foundation [CON8030] 4:30 p.m. - 5:15 p.m. | Moscone West - Room 2020 JSF 2.3 in Action [BOF2723] 7:30 p.m. - 8:15 p.m. | Moscone West - Room 2024 Tuesday, Oct 03 JSR 375: New Security APIs for Java EE [CON3544] 9:30 a.m. - 10:15 a.m. | Moscone West - Room 2006 Modern Application and Microservices Security from EE6 JASPIC to the EE8 Security API [CON5954] 9:30 a.m. - 10:15 a.m. | Moscone West - Room 2024 What’s New in JAX-RS 2.1? [CON3625] 3:00 p.m. - 3:45 p.m. | Moscone West - Room 2006 CDI Ecosystem [BOF6113] 6:45 p.m. - 7:30 p.m. | Moscone West - Room 2020 Wednesday, Oct 04 Contemporary Java Web Applications with JSF 2.3 [CON2023] 10:45 a.m. - 11:30 a.m. | Moscone West - Room 2020 Panel: Accelerating the Adoption of Java EE 8 with MicroProfile [CON1825] 11:45 a.m. - 12:30 p.m. | Moscone West - Room 202 Discover CDI 2.0 in Live Coding [CON6083] 12:45 p.m. - 1:30 p.m. | Moscone West - Room 2020 Java EE 8 on a Diet with Payara Micro 5 [CON3013] 4:30 p.m. - 5:15 p.m. | Moscone West - Room 2024 Thursday, Oct 05 What’s New in Java EE 8? An Overview [CON1431] 10:45 a.m. - 11:30 a.m. | Marriott Marquis (Yerba Buena Level) - Salon 14 Keeping Your Data Sane with Bean Validation 2.0 [CON1512] 11:45 a.m. - 12:30 p.m. | Marriott Marquis (Yerba Buena Level) - Nob Hill A/B Java EE 8: What’s New on the JSON Front [CON7773] 2:45 p.m. - 3:30 p.m. | Marriott Marquis (Yerba Buena Level) - Nob Hill A/B  

JavaOneis almost upon us again! Obviously, Java EE will be well covered. Here is a selection of some of the Java EE 8 related sessions (technical sessions, panels, BoFs, etc.). This is just an...

JavaEE

Java EE 8 and GlassFish 5.0 Released!

We are pleased to announce the general availability of GlassFish 5.0, the Java EE 8 Open Source Reference Implementation and that the Java EE 8 umbrella specification and all the underlying specifications (JAX-RS 2.1, Servlet 4.0, CDI 2.0, JSON-B 1.0, Bean Validation 2.0, etc.) are finalized and approved! Java EE 8 adds some nice capabilities to the platform: Servlet 4.0 API with HTTP/2 support Enhanced JSON support including a new JSON binding API A new REST Reactive Client API Asynchronous CDI Events A new portable Security API Server-Sent Events support (Client & Server-side) Support for Java SE 8 capabilities (e.g. Date & Time API, Streams API, annotations enhancements) ... Today, you can use these new features using GlassFish 5.0 and hopefully with additional Java EE 8 application servers in the near future. Below you will find some resources that might help you to get started with Java EE 8.  One of the challenges we faced in this release is that we moved from the old Java.net infrastructure to GitHub in the middle of the development cycle.  It wasn’t necessarily simple but we now clearly see the benefits of such a modern collaborative software development platform! Exploring the code is now just one link away! We hope the GitHub adoption will make the platform more accessible to developers. Java EE 8 is really the result of a teamwork involving many people:  All the JCP Specification Leads and all the Expert Groups members All the people involved in developing the different Reference Implementations that comprise Java EE The different Java EE implementers The Java EE community at large And many others who most of the time works behind the scene like the team at Oracle who develops GlassFish itself and the team managing the build infrastructure! Kudos to all of you! Java EE 8 wouldn’t have been possible without your work and dedication! As you probably know, this is just the beginning as we are working, together with the community including the Eclipse Foundation, Red Hat and IBM to open Java EE even more by transferring its development under the auspices of the Eclipse Foundation (see here and here). There are many discussions going on and we hope to be able to share additional details at JavaOne. Today also marks the general availability of Java SE 9. As mentioned above GlassFish 5.0 leverages new features in Java SE 8, and is certified today on Java SE 8. Even though we have a lot of work in front of us with the transition to the Eclipse Foundation, our current intent is to certify Java SE 9 in an upcoming GlassFish 5 release.  We will keep you posted on future developments in this area. David on behalf of all the Oracle Java EE Team. Resources: Press Release GlassFish 5.0 downloads GlassFish 5.0 documentation Java EE 8 SDK downloads Java EE 8 tutorial Java EE at a Glance

We are pleased to announce the general availability of GlassFish 5.0, the Java EE 8 Open Source Reference Implementation and that the Java EE 8 umbrella specification and all the...

Community

Opening Up Java EE - An Update

In a previous post, we announced that Oracle was beginning to explore moving Java EE technologies to an open source foundation in order to make the process of evolving these standards more agile, flexible and open. Since mid-August, we’ve had many discussions with other vendors, community members and open source foundations in order to move the process forward. Here’s an update on the progress we have made so far.  First, we have reached out to IBM and Red Hat, the other largest contributors to the Java EE platform, to solicit their support for this new direction. Oracle, IBM and Red Hat are collaborating on an ongoing basis to refine an approach that we can collectively support.  We've made good progress on this front, and expect to continue to work together to make this transition successful for all parties. Thank you IBM and Red Hat! Second, we’ve refined our proposal. Subject to the usual caveats about plans being subject to change in the future, our intention is that we would: Relicense Oracle-led Java EE technologies, and related GlassFish technologies, to the foundation. This would include RIs, TCKs, and associated project documentation. Demonstrate the ability to build a compatible implementation, using foundation sources, that passes existing Java EE 8 TCKs. Define a branding strategy for the platform within the foundation, including a new name for Java EE to be determined. We intend to enable use of existing javax package names and component specification names for existing JSRs to provide continuity. Define a process by which existing specifications can evolve, and new specifications can be included in the platform. Recruit and enable developers and other community members, as well as vendors, to sponsor platform technologies, and bring the platform forward within the foundation. This would include potential incorporation of Eclipse MicroProfile technologies into the platform. Begin doing the above as soon as possible after completion of Java EE 8 to facilitate a rapid transition.  Third, we have met with several foundations to discuss our proposal. We appreciate the time they have invested with us, and the feedback and input they offered. After careful review, we have selected the Eclipse Foundation as the foundation that we will work with going forward to make the above a reality. The Eclipse Foundation has strong experience and involvement with Java EE and related technologies. This will help us transition Java EE rapidly, create community-friendly processes for evolving the platform, and leverage complementary projects such as MicroProfile. We look forward to this collaboration. Note that in addition to all of the above, Oracle will continue to support existing Java EE licensees, including licensees moving to Java EE 8. Oracle also intends to continue to support its existing WebLogic Server versions, and to support Java EE 8 in a future WebLogic Server version. We believe this plan will enable us to continue to support existing Java EE standards, while enabling the evolution to a more open environment. There's more work to do, but we believe we're on the right track. We hope to have additional updates soon!   Safe Harbor Statement The preceding is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.  

In a previous post, we announced that Oracle was beginning to explore moving Java EE technologies to an open source foundation in order to make the process of evolving these standards more agile,...

Community

Opening Up Java EE

We continue to make great progress on Java EE 8. Specifications are nearly complete, and we expect to deliver the reference implementation this summer. As we approach the delivery of Java EE 8 and the JavaOne 2017 conference, we believe there is an opportunity to rethink how Java EE is developed in order to make it more agile and responsive to changing industry and technology demands. Java EE is enormously successful, with a competitive market of compatible implementations, broad adoption of individual technologies, a huge ecosystem of frameworks and tools, and countless applications delivering value to enterprises and end users. But although Java EE is developed in open source with the participation of the Java EE community, often the process is not seen as being agile, flexible or open enough, particularly when compared to other open source communities. We’d like to do better. We are discussing how we can improve the Java EE development process following the delivery of Java EE 8. We believe that moving Java EE technologies including reference implementations and test compatibility kit to an open source foundation may be the right next step, in order to adopt more agile processes, implement more flexible licensing, and change the governance process. We plan on exploring this possibility with the community, our licensees and several candidate foundations to see if we can move Java EE forward in this direction.  We intend to meet ongoing commitments to developers, end users, customers, technology consumers, technology contributors, partners and licensees. And we will support existing Java EE implementations and future implementations of Java EE 8. We will continue to participate in the future evolution of Java EE technologies. But we believe a more open process, that is not dependent on a single vendor as platform lead, will encourage greater participation and innovation, and will be in best interests of the community.    If you would like to provide input or comments on this direction, please send email to feedback@javaee.groups.io. We will keep you updated as we explore this approach in more detail. For more information about how this affects WebLogic Server, see here. Safe Harbor Statement The preceding is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.

We continue to make great progress on Java EE 8. Specifications are nearly complete, and we expect to deliver the reference implementation this summer. As we approach the delivery of Java EE 8 and the...

JavaEE

Java EE 8 - July recap

Despite the traditional summer slowdown, the last few weeks have been important for Java EE 8. Here is a short recap of some of the progress made around the platform during the course of last month. In July, JSON-B (JSR 367) went final. That means that we now have 4 Java EE 8 related APIs that are final: CDI 2.0 (JSR 365), JSF 2.3 (JSR 372), JSON-P 1.1 (JSR 374) and JSON-B 1.0 (JSR 367). And that is excluding the APIs updated via a Maintenance Release, ex. JPA 2.2 which is now finalised too. Servlet 4.0 (JSR 369) has finished the Proposed Final Draft period and will soon enter into the Proposed File Draft ballot. For JAX-RS 2.1 (JSR 370) and Bean Validation 2.0 (JSR 380), things went a little bit faster as both specifications went through their respective Proposed Final Draft period and have both unanimously passed their Final Approval Ballot in July (see results here and here). Congratulations to the JAX-RS and Bean Validation Experts Groups! In July, the Java EE 8 EG has published their Proposed Final Draft and will submit shorty their Final Drafts to the JCP to enter the Final Approval Ballot. Mid July, the Java EE Security API (JSR 375) EG has released their Proposed Final Draft and is actively working on the final technical details. As we are getting closer the finalization of the Java EE 8 platform, we have also accelerated the GlassFish 5 Promotion process. The goal is now to have 2 GF5 promotion builds per week. Talking about GlassFish, the number of stars on the GF GitHub repo is still relatively low. This is explained by the fact that the GF repo is relatively young. But as we are slowly but surely getting closer the final bits of GlassFish 5, it would be nice to raise that number. So if you are using GlassFish, do not hesitate to ‘star’ it on GitHub. This small but nice recognition costs just one click!

Despite the traditional summer slowdown, the last few weeks have been important for Java EE 8. Here is a short recap of some of the progress made around the platform during the course of last month. In...

Java EE 8 - June recap

The last few weeks were fruitful in term of progress for Java EE 8! Here is a short recap covering some of the main news... JSON-B (JSR 367) successfully passed its Final Approval Ballot. So next to JSON-P 1.1 (JSR 374), JSF 2.3 (JSR 372) and JPA 2.2 (JSR 338) which has recently passed the Maintenance Release ballot, JSON-B is another Java EE 8 related specification that is final! In June, 3 additionals specifications have passed their Public Review Ballot and have then posted their Proposed Final Draft: Servlet 4.0 (JSR 369), JAX-RS 2.1 (JSR 370) and Bean Validation 2.0 (JSR 380). Those 3 specifications are now in the final phase, i.e. Proposed Final Draft, before getting finalized! The Security API for Java EE Expert Group (JSR 375) has also posted the Public Review and is currently closing its Public Review Ballot period. The experts are busy wrapping the specification to submit the Proposed Final Draft shortly. And last but not least, the Java EE 8 (JSR 366), the umbrella specification has also successfully passed in June the Public Review Ballot and is ready to move to Proposed Final Draft! All in all, we can now say that Java EE 8 specifications are nearly complete. As a consequence, we are observing a steady ramping down on specifications related works and an increase of GlassFish 5 related activities. Last month, the GlassFish code base has been restructured. The different Reference Implementations (Jersey, Yasson, Mojarra, etc.) are already or are currently being integrated in GlassFish 5 (e.g. EclipseLink 2.7.0 for JPA 2.2). There has been some back for regarding Weld 3 integration but Weld 3 has been recently re-integrated back in GlassFish 5. The Bean Validation 2 integration is now being tackled... In summary, it is fair to say that Java EE 8 is progressing nicely! PS: If you are using Docker, make sure to check this Docker update covering both GF 4.1.2 and GF 5.

The last few weeks were fruitful in term of progress for Java EE 8! Here is a short recap covering some of the main news... JSON-B (JSR 367) successfully passed its Final Approval Ballot. So next...

GlassFish

GlassFish Docker Images – Update

p { margin-bottom: 0.25cm; line-height: 120%; }a:link { } We have updated the docker image for GlassFish available in DockerHub. Please find below the highlights of the update.   GlassFish 4.1.2 Docker Images   The latest GlassFish release is 4.1.2. The latest tag of oracle/glassfish is pointing to oracle/glassfish:4.1.2. The docker image for GlassFish 4.1.2 full profile can be downloaded as   docker pull oracle/glassfish OR docker pull oracle/glassfish:4.1.2   The docker image for GlassFish 4.1.2 web profile can be downloaded as   docker pull oracle/glassfish:4.1.2-web   GlassFish 5.0 Nightly Docker Images  Earlier GlassFish 5.0 nightly docker image used to be available under 'glassfish' organization in DockerHub. In order to keep and maintain all GlassFish docker images under same organization we have moved this image from 'glassfish' organization to 'oracle' organization in DockerHub. Please do not use glassfish/nightly docker image as we are not maintaining it any more. Instead please use oracle/glassfish:nightly (or oracle/glassfish:nightly-web for web profile) for the latest nightly images for GlassFish 5.0 GlassFish 5.0 full profile nightly docker image can be downloaded as   docker pull oracle/glassfish:nightly   GlassFish 5.0 web profile nightly docker image can be downloaded as   docker pull oracle/glassfish:nightly-web   GlassFish Admin Password Handling   Earlier admin password was default ('glassfish' was the default admin password) for oracle/glassfish image. It had security flaws. So we have updated the image to use orchestrator provided password at runtime. If the orchestrator does not provide password in time of docker run, it would auto generate password at runtime.   Orchestrator provided password   docker run -ti -e ADMIN_PASSWORD=<your-secret-password> -p 4848:4848 -p 8080:8080 -d oracle/glassfish:4.1.2   Auto Generated password   docker run -ti -p 4848:4848 -p 8080:8080 -d oracle/glassfish:4.1.2 The auto generate password can be obtained from docker log   docker logs <CONTAINER> | grep "GENERATED ADMIN PASSWORD"   This change is done for all the tags (4.1.1, 4.1.1-web, 4.1.2, 4.1.2-web, nightly, nightly-web and latest) of GlassFish image.   Updated Base Image   Earlier GlassFish images used oraclelinux:latest which is 225 MB in size. Now GlassFish images are lighter as we changed to use oraclelinux:7-slim as base image which is 114MB in size. This change is made for all the tags of oracle/glassfish image.   JDK Version used in GlassFish docker images   Image JDK Version oracle/glassfish:latest openjdk 1.7.0_141 oracle/glassfish:4.1.1 openjdk 1.7.0_141 oracle/glassfish:4.1.2 openjdk 1.7.0_141 oracle/glassfish:4.1.1-web openjdk 1.7.0_141 oracle/glassfish:4.1.2-web openjdk 1.7.0_141 oracle/glassfish:nightly openjdk 1.8.0_131 oracle/glassfish: nightly-web openjdk 1.8.0_131   Docker Build Scripts   The docker build scripts for all the tags of oracle/glassfish docker image is available here.   Please do try out the images and share your experience with us.

We have updated the docker image for GlassFish available in DockerHub. Please find below the highlights of the update.   GlassFish 4.1.2 Docker Images   The latest GlassFish release is 4.1.2. The latest...

JavaEE

Java EE 8 - May recap

Here is a short recap covering some recent Java EE 8 updates. In May, JSON-P 1.1 (JSR 374) has passed its Final Approval Ballot. Next to this, CDI 2.0 (JSR 365) has also successfully passed the Final Approval Ballot. Given the importance of CDI across the Java EE platform, this is a key milestone towards Java EE 8!  Make sure to check this CDI 2 – Weld 3 Tour. Last month, JSON-B (JSR 367) has entered in the Final Approval ballot period. In the meantime, you can get Yasson, the JSON-B Reference Implementation, here. Servlet 4.0 (JSR 369) , JAX-RS 2.1 (JSR 370) and Bean Validation 2.0 (JSR 380) have all finished their Public Review in May and are now in the Public Review ballot period. In addition, the respective Spec Leads gave a status update on their JSRs to the JCP Executive Committee: Ed Burns’s Servlet 4.0 status update  Santiago Pericas-Geertsen’s JAX-RS 2.1 status update  Gunnar Morling’s Bean Validation 2.0 status update Finaly, it should be mentioned that Java EE 8 (JSR 366) has also entered in the Public Review Ballot period.  Java EE Security API (JSR 375) is now in Public Review; this is clearly an important step for this new API.  Progress is also being made on different specifications that will get a maintenance release for Java EE 8: JAX-B 2.0 (JSR 222) has passed the Maintenance Release Interceptors (JSR 318) Maintenance Release Java Persistence 2.1 (JSR 338) Maintenance Review JavaMail (JSR 919) Maintenance Review 4, JavaMail 1.6.0 Release Candidate 2   Overall, we can observe a steady progress towards the finalization of the different Java EE 8 specifications. Last month, 2 promoted builds of GF5 were released. The fact that those are the first post-Java.net builds explains their relatively limited scope (see here and here). A lot of work has been done in the new GlassFish build pipeline. Now that this effort is mostly done, it is fair to expect a boost on GF5 progress in the coming weeks. To conclude on the infrastructure front, we should mention that all the Java EE related discussions are now hosted on a new platform javaee.groups.io. So if you have done so yet, join the conversation!

Here is a short recap covering some recent Java EE 8 updates. In May, JSON-P 1.1 (JSR 374) has passed its Final Approval Ballot. Next to this, CDI 2.0 (JSR 365) has also successfully passed the Final...

JavaEE

Java EE 8 - April recap

  With a few days delay, here is a short recap of some the April news related to Java EE 8.    First an important update regarding Java.net that will be shutdown shortly. All the GlassFish development and most of the Java development is being migrated to GitHub under the Java EE organization. From now on, we will leverage GitHub to go forward; this will hopefully enable a greater participation. Some projects like Jersey and specifications like JAX-RS were already mirrored from Java.net to GitHub, those repositories will remain unchanged for the time being. Most of the Java.net repositories and issues have been migrated to GitHub but we still have things to do including refreshing most of the projects web sites. We are also putting the final touches on the new mailing lists and we should, hopefully, be able to share the details very soon. And last but not least, this blog platform will also be migrated to a new modern platform.  Overall, the effort that went into the migration from Java.net to GitHub has slightly impacted the work on GlassFish 5 last month but it was a short-term pain for a long-term gain! You can download the mid April GlassFish 5 promoted build here.   The good news is that the progress of the different EGs hasn’t been really impacted by this migration.   JavaServer Faces 2.3 has posted the Final Release of the JSR 372 specification while JSON-P 1.1 has passed the Final Approval Ballot. Congratulation to both EGs! JSON-B 1.0 (JSR 367) is now in Proposed Final Draft, yet another specification very close to the Final Approval ballot!   The Servlet 4.0 (JSR 369) EG is now in Public Review.  Regarding Servlet 4 and more specifically HTTP/2 support over TLS on JDK 8, there is a clarification on ALPN support on top of JDK 8.   The JAX-RS 2.1 (JSR 370) EG is making good progress; it has posted a Public Review. Make sure to review the draft specification and provide feedback. Santiago Pericas-Geertsen (JAX-RS 2.1 Co-Spec Lead) gave a session on JAX-RS 2.1 at Devoxx US; the video is now available here. It should be noted that since this presentation in early March, it was decided to drop for now the support of non-blocking I/O in providers. In any case, Santiago's session is interesting to understand JAX-RS 2.1 new APIs (SSE API, Reactive Client API) but also to understand the motivation (and the challenges) behind non-blocking I/O support in JAX-RS providers.   During Devoxx US, Will Hopkins (Spec Lead) gave a overview on Java EE Security (JSR375), you can watch the replay here. The question was raised in the Platform EG (JSR 366) about the inclusion of this JSR in the Web Profile. Given the strong positive feedback on this question, it was decided to include this API in the Web Profile (in addition to the full platform). It is one of the update included in the second Early Draft of the Java EE 8 specification that is now available for Public Review. Also, make sure to watch the Java EE 8 overview that Linda De Michiel (JSR 366 Spec Lead) gave at Devoxx US.   CDI 2 has entered the Final Approval Ballot and while waiting the results, you can watch another great Devoxx US session: “CDI 2.0 New & Noteworthy” by John Ament (JSR 365 EG member). Talking about Red Hat lead JSRs, Bean Validation 2 (JSR 380) is now in Public Review. You can watch Emmanuel Bernard (BV 1.x Spec Lead) “Bean Validation 2 overview” Devoxx US session.   On the Maintenance Release front, we can mention for now 2 upcoming MRs for Java EE 8: Interceptors and JPA.   And last but not least, we are happy to see MVC (JSR 371) going forward, independently of Java EE, with not one but two new Spec Leads: Ivar Grimstad and Christian Katlepoth. With Ivar and Christan, that JSR is in good hands!    In summary, April has been a very busy month bringing us another step closer to completing Java EE 8 this summer!  

  With a few days delay, here is a short recap of some the April news related to Java EE 8.    First an important update regarding Java.net that will be shutdown shortly. All the GlassFish development...

GlassFish

GlassFish 5 Promoted Build 4

The latest GlassFish 5.0 promotion i.e glassfish-5.0-b04 is available for download here. Component updates included in this build are: Grizzly 2.3.30 JSON-P 1.1.0-M2 Bugs Fixed  This build includes some critical security fixes apart from the following bug fixes.   Issue ID  Description GLASSFISH-21582 No error is displayed on Batch Job Executions screen when Batch Runtime database is down GLASSFISH-21652 ConnectionQueueStatsProvider.java#onTaskQueuedEvent is not counted correctly when there exists plural acceptor threads GLASSFISH-21256 Debug not shown correctly on General Information in the admin console GLASSFISH-21409 Encoding mapping key search error GLASSFISH-21319 javax.inject.jar missing in javaee.jar Servlet 4.0 Update   Issue ID or Commit Revision  Description SERVLET_SPEC-73 implemented by GLASSFISH-21670 Implementation of servlet mapping discovery r64750 Integrated Grizzly 2.3.30 -Removed experimental SPDY code -Removed Http2 dom element.  HTTP2 attributes migrated to http dom attribute.  SERVLET_SPEC-161 implemented by GLASSFISH-21688 New XML element for request and response encoding. GLASSFISH-21664 Implement Servlet 4.0 Server Push GLASSFISH-21708 Implement SERVLET_SPEC-171 Just to re-iterate, weekly promotions go through more thorough testing but if you want to use the latest, you can pick up the nightly bits from here. Do try out the bits and share your experience with us.

The latest GlassFish 5.0 promotion i.e glassfish-5.0-b04 is available for download here. Component updates included in this build are: Grizzly 2.3.30 JSON-P 1.1.0-M2 Bugs Fixed  This build includes some...

JavaEE

Java EE 8 - March recap

Here's a quick recap of some of the recent Java EE 8 news. JSF 2.3 (JSR 372) is now final! You can check the Release Notes and download the Reference Implementation. A small party was held at JavaLand to celebrate this community effort! JSON-P 1.1 (JSR 374) has successfully passed the Public Review Ballot and is now in Proposed Final Draft. CDI 2 (JSR 365) has also passed the Public Review Ballot and is about to enter the Proposed Final Draft stage too. Make sure to check this CDI 2.0 overview.  JSON-B 1.0 (JSR 367) should also enter the Proposed Final Draft phase shortly.  The JAX-RS 2.1 EG (JSR 370) has posted an Early Draft that covers 2 of the 3 big-ticket JAX-RS 2.1 features: SSE support and a Reactive Client API. The details on Non Blocking IO support, the 3rd big-ticket feature, are now also being discussed. To get a good overview of JAX-RS 2.1, check the presentation that Santiago Pericas-Geertsen (JAX-RS 2.1 co-Spec Lead) did at Devoxx US (video will be published soon).  The Java EE Security API EG (JSR 375) has posted its first Early Draft. For both JAX-RS 2.1 and the Java EE Security API make sure to read the drafts and provides your feedback in time! The Servlet 4 EG (JSR 369) is also making progress towards another Early Draft; they have just published an updated schedule that align with the Java EE 8 global schedule. In parallel, we are observing progress on the Reference Implementation work (e.g. Server Push support is being added).  JavaMail should get a Maintenance Release for Java EE 8 (see details here), a Release Candidate of JavaMail 1.6 is available here. In other news, IBM has confirmed that they are not planning to do a Maintenance Release of the Batch API (JSR 352) for Java EE 8. GlassFish 5, the Java EE 8 Reference Implementation is starting to take shape, Promoted Build 3 and 4 have been released in March. Finally, you might want to check the 3rd Adopt a JSR online meeting held by the JCP.  As usual, feedback and participation are encouraged! You should expect more news shortly including an update on the plans to move away from Java.Net. 

Here's a quick recap of some of the recent Java EE 8 news. JSF 2.3 (JSR 372) is now final! You can check the Release Notes and download the Reference Implementation. A small party was held at JavaLand...

GlassFish

GlassFish 4.1.2 Released

 GlassFish 4.1.2 is the latest update release of GlassFish 4.x line, the Java EE 7 Reference Implementation. GF 4.1.2 supercedes 4.1.1 (Java EE 7 Update 2). GlassFish 4.1.2 has undergone extensive testing that include the component unit tests, developer tests, full CTS 7 as well as standalone TCKs (e.g. websocket, bean validation, CDI, ...). These tests span the full Java EE 7 platform and the Java EE 7 Web profile. JDK Requirements  Minimum JDK required is JDK 7 u80. Downloads The release is available from the following locations: glassfish.org GF 4.1.2 bundle on maven central http://repo1.maven.org/maven2/org/glassfish/main/distributions/glassfish/4.1.2/ groupId=org.glassfish.main.distributions  artifactId=glassfish version=4.1.2 type=zip GF 4.1.2 Web bundle on maven central http://repo1.maven.org/maven2/org/glassfish/main/distributions/web/4.1.2/ groupId=org.glassfish.main.distributions artifactId=web version=4.1.2 type=zip All GlassFish 4.1.2 maven artifacts are also posted to maven central; just search "org.glassfish.main" on http://search.maven.org/ Bugs Fixed We have incorporated the following critical fixes in this release. Issue Description GLASSFISH-21390 The message of PWC4011: Unable to set request character encoding does not output GLASSFISH-21172 javax.transaction.RollbackException from @Transactional bean has no cause set GLASSFISH-21314 Cannot create JDBC Connection Pool GLASSFISH-21238 Response code 400 on a DELETE request with a body GLASSFISH-21642 access-logging-bad-requests web devtests fails in Hudson Component Updates Component Version in Glassfish 4.1.1 GlassFish 4.1.2 JSF (Mojarra) (GLASSFISH-21662) 2.2.12 2.2.14  Do give it a try and watch out this space for more! 

 GlassFish 4.1.2 is the latest update release of GlassFish 4.x line, the Java EE 7 Reference Implementation. GF 4.1.2 supercedes 4.1.1 (Java EE 7 Update 2). GlassFish 4.1.2 has undergone extensive...

GlassFish

Additional details on GlassFish 5 Promoted Build 3

As we are progressing on Java EE 8, GlassFish has started to see activity in the recent months. After stabilizing the nightly builds of GlassFish 5, we have resurrected the GlassFish weekly promotion process. After a long time, we have a weekly promoted build GlassFish-5.0-b03. Do give it a try and give us your feedback. Note that the minimum JDK version that is needed for GlassFish 5 is JDK 8u121. Here is a list of component integrations that are part of this build: JSF 2.3.0-m11 Jersey 2.26-b02 JAX-RS 2.1-m03 HK2 2.5.0-b33 Grizzly 2.3.29 Grizzly NPM 1.7 Jboss Logging 3.3.0.Final Tyrus 1.13.1 Jackson 2.8.4 JSTL 1.2.5-b03 Servlet 4.0.0-b03 Servlet 4.0 Update We have made good progress in the web container. Issue ID or Commit Revision Summary r64700 Integrate javax.servlet:javax.servlet-api:4.0.0-b03 SERVLET_SPEC-73 Add API for Servlet Mapping SERVLET_SPEC-161implemented by GLASSFISH-21688 Allow encoding to be set from deployment descriptor r64338 Updates schema files for Servlet 4.0 SERVLET_SPEC-16implemented by GLASSFISH-21666 Allow setting the jsp-file programmatically SERVLET_SPEC-134 Updates for spec and impl of server push SERVLET_SPEC-137implemented by GLASSFISH-21673 Allow setting the default context-path without resorting to container specific config Bugs Fixed Here is the list of bugs addressed in this build. Issue Id Summary GLASSFISH-21677 Need to remove -Xbootclasspath from domain.xml GLASSFISH-21671 Switch appserver build to source=1.8 and target=1.8 GLASSFISH-21656 list-jms-resources fails if operand is clustered instance GLASSFISH-21655 rollback of create-jms-resource fails when resource has already existed GLASSFISH-21650 countopenconnections is not counted at the request to http-listener-2 of the cluster GLASSFISH-21649 countqueued1minuteaverage does not count the value for one minute GLASSFISH-21648 corethreads and maxthreads are always zero GLASSFISH-21646 countbytesreceived and countbytestransmitted count the value of requests to admin-listener GLASSFISH-21645 maxopenconnections of HttpServiceStatsProvider is always the same. GLASSFISH-21644 Not able to deploy app with cdi validator support GLASSFISH-21642 access-logging-bad-requests web devtests fails in Hudson GLASSFISH-21640 JMS message in server.log is logged only message key. GLASSFISH-21639 difficult maintained log messages GLASSFISH-21591 [GF-JDK9] JDK internal API sun.misc.URLClassPath used in com.sun.appserv.ClassLoaderUtil GLASSFISH-21589 Problems with resource deletion if all resource targets are deleted GLASSFISH-21585 The list of JVM options is lost empty when an invalid option is added. GLASSFISH-21584 A new property cannot be added in "Cluster System Properties" page. GLASSFISH-21580 WebappClassLoader is not thread safe GLASSFISH-21579 asadmin list-file-groups exits successfully although user doesn't exist GLASSFISH-21576 javamail debug log is not logged. GLASSFISH-21574 asadmin deploy --precompilejsp doesn't check compilerSourceVM and compilerTargetVM in glassfish-web.xml GLASSFISH-21573 Server log messages are unexpectedly trimmed if the message starts with or ends with spaces. GLASSFISH-21572 AS-WEB-GLUE-00078 is logged to the server.log although both tls11-enabled and tls12-enabled are true. GLASSFISH-21560 "asadmin list-logger-levels" does not list java.util.logging.ConsoleHandler GLASSFISH-21546 password alias is not updated until restart the process. GLASSFISH-21542 Update jboss.logging GLASSFISH-21522 NullPointerException during WebDirContext.lookupFromJars GLASSFISH-21515 Possible null pointer dereference GLASSFISH-21505 JDK9 - Unable to launch the Application Client Container GLASSFISH-21494 Double checked locking problem GLASSFISH-21479 Glassfish 4.1 won't start with JDK 9 build jdk9-b95 (and later) GLASSFISH-21376 There is a "null" in the log name GLASSFISH-21276 A number of monitor mbeans are broken GLASSFISH-21272 JDBC Monitoring MBeans not working in JConsole GLASSFISH-20917 a wrong implementation for web-fragment.xml with <distributable/> issue GLASSFISH-20858 Message "Invalid Url Pattern" contains placeholder, while it obviously must contain the invalid pattern

As we are progressing on Java EE 8, GlassFish has started to see activity in the recent months. After stabilizing the nightly builds of GlassFish 5, we have resurrected the GlassFish weekly...

JavaEE

An update on GlassFish 5

The Reference Implementation is a critical piece of any given JSR, this is even more true for Java EE. As the different Java EE 8 JSRs continue to make progress, it is now important to ramp up efforts around GlassFish 5, the open source Java EE 8 Reference Implementation. And today is an important milestone on the way to Java EE 8 as we are publishing the first promoted build of GlassFish 5, aka GlassFish-5.0-b03. We are in fact releasing 2 types of GlassFish 5 builds: nightly and promoted (for both the full Java EE platform and the Web Profile).  Nightly builds have a daily cadence and goes through more limited testing; those builds are on the edge! See here. The promoted builds on the other hand have a slower cadence, i.e. weekly cadence, but go through a larger set of tests including (an initial version of) the Java EE 8 CTS.  See here. It is obvious that we are in the early days and everything is in motion: the different specifications, their respective Reference Implementations (e.g. Jersey for JAX-RS, Hibernate Validator for Bean Validation, ...) but also their own TCK. So clearly, we are not claiming that any GlassFish 5 promoted build is fully passing the Java EE 8 CTS ... yet! ;-) It should also be mentioned that the cadences mentioned below might varies depending on the actual state of a given build, e.g. if the build is broken, it might be delayed or simply skipped. Given that Java EE 8 is based on Java SE 8+, we are using Java SE 8 as the baseline JDK for GlassFish 5 but the intent to also support Java SE 9 for the final GF5 release. For example, this week promoted build isn't working on Java SE 9 but that is only temporary.  The nightly builds will always be a few days ahead of the latest promoted build but we do encourage the community to use promoted builds. So you can help us by testing the latest promoted GF5 builds. If you find any issue, please raise a ticket against the appropriate GlassFish component here. And if you are confident that the issue is located in a specific component (e.g. Jersey) it might be more efficient to raise the issue directly against that particular component. GlassFish 5 should be released about six weeks after the Java EE 8 Platform specification (JSR 366) is final. As of today, we are targeting specification completion in July, which would result on a release date in the August/September timeframe. The schedule is subject to change but that is our current direction.  

The Reference Implementation is a critical piece of any given JSR, this is even more true for Java EE. As the different Java EE 8 JSRs continue to make progress, it is now important to ramp up efforts...

JavaEE

Java EE 8 - February recap

February is the shortest month of the year but it was nevertheless not a quiet month for Java EE 8! Here is a short recap of some recent activities and relevant updates. The Java EE 8 platform (JSR 366) schedule has been updated as follow: Public Review - Apr/May 2017 Proposed Final Draft - June 2017 Final Release - July 2017(!) The CDI 2.0 Public Review period is almost over, so make sure to provide your feedback to the JSR 365 EG …now!  The JAX-RS 2.1 Early Draft is nearly ready; see here to get a sneak peak. In this draft, the Server-Sent Event API has changed quite a lot. For more details, check here and here (JAX-RS 2.1 m04).  The Bean Validation 2.0 (JSR 380) EG has released an Early Draft. To learn more about BV 2.0, you might want to listen this JBoss Community Asylum episode. Servlet 4.0 (JSR 369) has successfully passed its renewal ballot and in the meantime, the Servlet EG is making progress towards its Early Draft.  The Security API (JSR 375) EG is also busy preparing its Early Draft. It was also announced that there is intent to do a JPA Maintenance Release for Java EE 8.  JSF 2.3 and JSON-P 1.1 have now entered the Public Review Ballot period. That means that those 2 specifications are getting very close to being finalised! Finally and if you want to contribute, make sure to watch the 2nd Adopt-A-JSR webcast that was recently hosted by the JCP.

February is the shortest month of the year but it was nevertheless not a quiet month for Java EE 8! Here is a short recap of some recent activities and relevant updates. The Java EE 8 platform (JSR 366)...

JavaEE

Java EE 8 - January recap

January was a busy for month for Java EE 8, here is a short recap of some of the activities that have occurred recently. JSF 2.3 , JSON-P 1.1 and CDI 2.0 are now in Public Draft. It is important to check those 3 specifications and provide feedback before the end of their respective Public Draft period. On the JAX-RS front, there has been a lot of progress as we now have concrete proposals for 2 of the 3 JAX-RS 2.1‘big ticket’ features, the Reactive Client API and the Server-sent Events support.  Non Blocking IO providers is the third ‘big ticket’ feature that should be discussed next in the JAX-RS Expert Group. Gunnar Morling (JSR 380 Spec Lead) is reporting on the Bean Validation 2.0 progress and hopes to have Early Draft Review shortly. In the meantime, you can always check the draft as it progresses. The Servlet 4 Expert Group is also making good progress as some of the technical implementations details of HTTP/2 (e.g. Server Push) are currently being discussed (see here). In addition, it seems that we can expect to see concrete discussions on the Security JSR (JSR-375) in the coming days.  Finally, it should also be mentioned that the MVC transfer ballot has passed. That means that we can now proceed with the paper works and hopefully, Ivar Grimstad should officially be the new MVC spec lead very soon! Concretely, we now have 4 Java EE 8 specifications in Public Draft (JSON-B 1.0, JSON-P 1.0, JSF 2.3 and CDI 2.0). So it is a good time to get engaged, test and provide feedback on those specifications. Watching the Adopt A JSR webcast that was recently hosted by the JCP is a good starting point to contribute. It still very early but we can now observe a resurgent activity around the Java EE 8 Reference Implementation, i.e. GlassFish 5. On that point, we are obviously very aware of the Java.net dismissal. We are working to ensure that this does not impact Java EE, i.e. the Java EE related JSRs and the different RIs including GlassFish. We plan to share more concrete details on this as quickly as we can. 

January was a busy for month for Java EE 8, here is a short recap of some of the activities that have occurred recently. JSF 2.3 , JSON-P 1.1 and CDI 2.0 are now in Public Draft. It is important to...

JavaEE

Java EE 8 - Community Survey Results and Next Steps

Thanks to everyone who took the time to complete the Java EE Community Survey!  1693 of you completed the survey, and ranked the importance of 21 different component technologies included in our proposed Java EE roadmap presented at JavaOne 2016.  For more detail on this roadmap, watch Anil Gaur’s Keynote at JavaOne 2016. Detailed findings and analysis can be found here and the chart below summarizes community ranking of component technologies surveyed, from most important to least important. Conclusions We reviewed the Java EE 8 proposal based on these survey results, and additional review of implementation considerations.  We have concluded that: REST (JAX-RS 2.1) and HTTP/2 (Servlet 4.0) have been voted as the two most important technologies surveyed, and together with JSON-B represent three of the top six technologies. Much of the new API work in these technologies for Java EE 8 is already complete.  There is significant value in delivering Java EE 8 with these technologies, and the related JSON-P updates, as soon as possible.  CDI 2.0, Bean Validation 2.0 and JSF 2.3 were not directly surveyed, but significant progress has been made on these technologies and they will be included in Java EE 8. We considered accelerating Java EE standards for OAuth and OpenID Connect based on survey feedback.  This could not be accomplished in the Java EE 8 timeframe, but we’ll continue to pursue Security 1.0 for Java EE 8. At JavaOne, we had proposed to add Configuration and Health Checking to Java EE 8, and these technologies rank reasonably high in survey results.   However, after additional review we believe the scope of this work would delay overall Java EE 8 delivery.  We have concluded it is best to defer inclusion of these technologies in Java EE in order to complete Java EE 8 as soon as possible. Management, JMS, and MVC ranked low in survey results, and this ranking supports our proposal to withdraw new APIs in these areas from Java EE 8. We have withdrawn the JSRs for Management 2.0 (JSR 373), and JMS 2.1 (JSR 368), and are investigating a possible transfer of MVC to another community member or organization in order to complete JSR 371 as a stand-alone component. We will revise the Java EE 8 proposal consistent with these findings.   The table below summarizes Oracle's original and revised Java EE 8 proposals, focusing on areas of new API development: Original and Revised Java EE 8 Proposals Next Steps Based on the survey results and implementation considerations discussed above, we’ll move forward with the revised Java EE 8 proposal.   If you have further feedback on Java EE 8, please join the project (if you are not already a member), and post to users@javaee-spec.java.net for further discussion.

Thanks to everyone who took the time to complete the Java EE Community Survey!  1693 of you completed the survey, and ranked the importance of 21 different component technologies included in our...

JavaEE

Developers Continue to Affirm Strong Support for Java EE 7

Some of you might recall last year in the JavaOne time frame we highlighted a key DZone survey showing strong developer support for Java EE 7, even as compared to alternatives. Since then a few things have changed. WebLogic announced official commercial support for Java EE 7. It now is clear JBoss EAP, WebSphere Classic and TomEE are also very close to coming forward with their Java EE 7 support (as you know WildFly and WebSphere Liberty already officially support Java EE 7 in addition to GlassFish and others). We thought this was a good point to do another pulse check of the community to see where Java EE 7 adoption stands now. We could not think of a better way to do this than simply running our own Twitter survey. We asked a very simple question on the survey - "Which version of Java EE are you running in production environments?". Frankly the results of the survey were far better than we could have ever expected. As the graph below shows almost 60% responded they use Java EE 7. 33% responded that they were using Java EE 6. Only 8% indicated they were using Java EE 5. We deliberately made the choices mutually exclusive and eliminated J2EE as irrelevant to our survey.  Here is a link to the actual survey on the Java EE twitter account. There is no downplaying the fact a strong majority indicated Java EE 7 usage. This data point goes a long way to removing the severe Java EE 7 skepticism in certain corners of the Java EE ecosystem. A nice side effect of the survey is that we got in touch with a number of Java EE 7 adopters willing to share their story with the community. The folks that responded that they are using Java EE 6 and Java EE 5 represent both a challenge and an opportunity. While it is true Java EE 7 does not represent a major programming model change in the way Java EE 5 or Java EE 6 did, the reality is that there is simply too much in Java EE 7 worth taking advantage of in terms of the sheer amount of improvements to many APIs. If you are a fan of Java EE 7 you should educate colleagues on what it brings to the table. No survey is perfect of course. Since it is a Twitter survey it is highly susceptible to selection bias. There is no denying the fact though that the sample size for the survey is extremely strong at over 1,100. That is a number well representative for the Java ecosystem and most certainly worth thinking about seriously. We can hope that developer support for Java EE 7 continues to strengthen even further in coming months. I can only be very thankful to all the folks that participated in the survey and showed their sincere support for Java EE.

Some of you might recall last year in the JavaOne time frame we highlighted a key DZone survey showing strong developer support for Java EE 7, even as compared to alternatives. Since then a few...

JavaEE

Self-Documented Services Using JAX-RS Analyzer

One of the things I miss the most about SOAP is the fact that much like Java, it is strongly typed. That means one can take a look at a WSDL document to understand what a service does. Similarly tools can easily read and use a SOAP service including generating clients, GUI visualizations and accurate documentation. WADL was conceived of in the REST world to overcome some of these shortcomings. Unfortunately WADL is sparsely supported and even more sparsely used. This presents a pretty big problem if you are writing REST services that are consumed by folks outside of your own team and even worse people that you may not even know. The answer so far has been manually writing documentation for REST services that are laborious, error-prone and often out of date (incidentally you should be aware that Jersey, the JAX-RS reference implementation, does support WADL). For JAX-RS developers though there is JAX-RS Analyzer to the rescue. JAX-RS Analyzer is a simple but extremely useful open source JAX-RS plugin written by Sebastian Daschner. It reads JAX-RS annotations/metadata to automatically generate documentation - in  plain text, AsciiDoc or Swagger. The Swagger option is especially compelling. Swagger is the closest thing at the moment to closing the WSDL/UDDI gap for REST. If you are still unfamiliar with JAX-RS Analyzer, you should definitely take a look at Sam Sepassi's  excellent recent write-up on it. It will save you from hours of tediously documenting your REST APIs.

One of the things I miss the most about SOAP is the fact that much like Java, it is strongly typed. That means one can take a look at a WSDL document to understand what a service does. Similarly tools...

JavaOne

Java SE 8 and Java EE 7 in Production at TecSinapse

One of the most important things to do at this stage of the life-cycle of Java EE is highlight successful adoption stories at a regular cadence. We have been doing just that for a long time through our adoption stories blog, this humble blog as well as JavaOne. Indeed JavaOne 2016 was particularly good in this regard. We had a number of solid adoption stories submitted that we could select from. A nice adoption story presented at JavaOne 2016 was from TecSinapse. The session was presented by Michael Santos. For those unaware, Michael Santos is an active member of the Brazillian Java community. He is a Java Champion, JavaOne Rock Star Speaker, blogger, OpenJDK committer, JCP expert and open source advocate. Michael is part of SouJava's board - one of the largest and most influential JUGs in the world. As head of development and operations at TecSinapse he oversaw real world adoption of both Java SE 8 and Java EE 7 in customer projects. TecSinapse is a consulting, solutions and integration provider out of Brazil. Some of their clients include Audi, Mercedes-Benz, Harley-Davidson, Jaguar, Land Rover, Nissan, Toyota and BMW. At JavaOne Michael provided specific insights on how he used Java EE 7 and Java SE 8 together. He also did not shy away from pointing out where Java SE and Java EE integration should improve. You can view his very well-delivered session below (click here if you are having trouble seeing the embedded video). If you have a similarly great Java EE adoption story to share with the community (particularly migration stories from other technologies), please do feel encouraged to reach out. In the spirit of Java EE centric vendor neutrality, what Java EE implementation or tool set you choose does not matter at all and neither does which part of the globe you are in.

One of the most important things to do at this stage of the life-cycle of Java EE is highlight successful adoption stories at a regular cadence. We have been doing just that for a long time through...

JavaEE

Java EE 7 Proves Effective for Mission-Critical E-Payment Systems

One of the most important things to do at this stage of the life-cycle of Java EE is highlight successful adoption stories at a regular cadence. We have been doing just that for a long time through our adoption stories blog, this humble blog as well as JavaOne. Indeed JavaOne 2016 was particularly good in this regard. We had a number of solid adoption stories submitted that we could select from. We will highlight all of those stories here. A very nice adoption story presented at JavaOne 2016 was from the TAS Group. The session was presented by Andrea Folli, the CTO of the cashless business unit of the TAS group that recently re-architected their legacy systems using Java EE 7. The TAS Group is a very important player in back-end e-payment solutions worldwide and certainly in Italy/Europe (so think the folks that do the actual heavy lifting behind e-commerce credit card processing, in-store credit card readers and bank ATMs). The Italy based company has 15 years of experience in providing mission-critical infrastructure for some of the largest financial organizations in Italy and the EU. They manage over 100 million cards world-wide. Over 65% of acquiring systems and more than 50% of issuing systems in Italy alone are managed by them. The company's legacy systems had been written with a combination of COBOL, Spring and J2EE. They successfully migrated these legacy systems to Java EE 6 and now Java EE 7. In adopting Java EE, Andrea cited standardization, portability, vendor neutrality, lack of third party dependencies and runtime performance as some of the reasons. Besides Java EE 7 APIs like JSF, CDI, EJB 3, JPA, JAX-RS, JAX-WS, batch and JTA he noted the use of Eclipse, Maven, Subversion, soapUI, trac and SonarQube. Although he did not name them specifically Andrea touched upon concepts like microservices, reactive architectures and Domain-Driven Design (DDD) using Java EE during his talk. He also shared some very cool Java EE best practices he discovered for his use cases along with cool architectural insights for e-Payment processing. You can view his well-delivered session below (click here if you are having trouble seeing the embedded video). If you have a similarly great Java EE adoption story to share with the community (particularly migration stories from other technologies), please do feel encouraged to reach out. In the spirit of Java EE centric vendor neutrality, what Java EE implementation or tool set you choose does not matter at all and neither does which part of the globe you are in.

One of the most important things to do at this stage of the life-cycle of Java EE is highlight successful adoption stories at a regular cadence. We have been doing just that for a long time through...

JavaEE

Java EE in Practice for Secure Online Voting at Scytl

One of the most important things to do at this stage of the life-cycle of Java EE is highlight successful adoption stories at a regular cadence. We have been doing just that for a long time through our adoption stories blog, this humble blog as well as JavaOne. Indeed JavaOne 2016 was particularly good in this regard. We had a number of solid adoption stories submitted that we could select from. We will highlight all of those stories here in the coming months. A particularly nice adoption story presented at JavaOne 2016 was from Scytl. The session was presented by Alex Soto. Scytl is a very innovative and important company that enables secure online voting across the world. Alex was the architect of a service-only back end system at Scytl written using vanilla Java EE and TomEE. Alex talked about the reasons they chose Java EE (over Spring in this case) such as ease-of-use, productivity, simplicity, standardization, lack of third-party dependencies, simple deployment, fast startup and performance. He also discussed their use of some pretty cool TomEE features, Arquillian, Docker and Apache Mesos. For those unaware, Alex is a Java EE advocate, blogger, author, JCP expert and open source commiter. You can view Alex's well-rated session below (click here if you are having trouble seeing the embedded video). If you have a similarly great Java EE adoption story to share with the community (particularly migration stories from other technologies), please do feel encouraged to reach out. In the spirit of Java EE centric vendor neutrality, what Java EE implementation or tool set you choose does not matter at all and neither does which part of the globe you are in.

One of the most important things to do at this stage of the life-cycle of Java EE is highlight successful adoption stories at a regular cadence. We have been doing just that for a long time through...

JavaOne

Revamping the Security API in Java EE 8

JAAS, JASPIC, JACC. If those acronyms do not sound familiar, you are in good company. I have been developing with Java EE for almost two decades and I was not terribly familiar with them until I seriously started thinking about revamping Java EE security in the early Java EE 7 time frame. Those are the three main Java EE related standard APIs that have remained largely unchanged since the J2EE era. That is until the Java EE Security API aimed for Java EE 8.The reason I mostly didn't need to know about these APIs is because of the way Java EE security has evolved over the years. As of Java EE 7 the way applications work is that you do some minimal web.xml configuration declaring what type of authentication you want (basic, form, digest, etc), what application server "realm" (logical link name to application server security configuration) and what roles (security groups) have access to secure parts of the application. Most of the real work is typically actually done in application server admin GUI wizards like configuring what identity store you want to use (database, LDAP, etc) and how underlying groups map to roles (for most of my applications the application roles and identity store groups are exactly the same). There are certainly some benefits to this approach that most other technologies do not have. Most of the heavy lifting for security is just a few mouse clicks as opposed to writing and maintaining code. You can hand off the work of securing the application to an admin where this work often best belongs. Application servers have sophisticated security admin tooling that seems to have everything under the Sun including things like federated security through SAML.This is not the approach more feature poor runtimes that lack admin GUIs take and the approach also has some downsides. The most significant downside is that beyond learning Java EE APIs as a developer you also need to know about each application server's security administration features. This also means that these features are slightly different from one application server to another, limiting application portability. In a PaaS environment it is a lot easier if all security configuration is done inside the application itself, making the application more self-contained. The last problem is related to the age and focus of the current APIs used in Java EE - JAAS, JASPIC, JACC. These APIs have not gone through a significant revision in a while and their focus is on vendor plug-in writers, not application developers. This becomes a problem when developers need to do things that the application server does not have built-in support for such as using a custom data store (say using a security database with a poorly designed legacy schema) or using a custom authentication mechanism (say your own homegrown HTTP headers for federated security). There are third party frameworks in the Java EE ecosystem such as Shiro and PicketLink that attempt to solve these issues - in particular making application security embedded. These frameworks are of course non-standard and increase the need to add more runtime dependencies in the application.The new Java EE Security API slated for Java EE 8 aims to solve these problems by simplifying and modernizing security in the platform. The Security API will make it possible to embed security in most common cases in the application in the simplest way possible. It will allow for easy extensibility by providing a much simpler, modernized, developer-focused alternative to JASPIC, JAAS and JACC. In the process it will introduce simple standard terms and interfaces for Java EE security. It will also add some cool new authorization mechanisms in addition to the basic role based security that Java EE offers today.Specification lead Alex Kosowski described all of this well during his JavaOne 2015 talk embedded below (click here if you can't see the embedded video).The Java EE Security API is one of the most important and perhaps most awaited parts of Java EE 8. It is not very surprising that it is one of the Java EE 8 JSRs that has seen the most active participation from the community - Alex refers to some of this participation in his talk. You should feel encouraged to participate yourself perhaps starting by viewing the video above.

JAAS, JASPIC, JACC. If those acronyms do not sound familiar, you are in good company. I have been developing with Java EE for almost two decades and I was not terribly familiar with them until...

JavaEE

Some Interesting Real World CDI Usage Statistics

The good folks over at Genuitec developing MyEclipse recently asked the Twittersphere about real world CDI usage. They ran a week-long Twitter survey asking the simple question - "Do you use CDI in your Java EE applications?". The results of the survey were pretty interesting and certainly worth sharing. As the graph below shows 60% responded they use CDI. 21% responded that they did not. 19% did not know what CDI was.Here is a link to the actual survey on the MyEclipse twitter account. For those unaware the MyEclipse team is working hard to bridge the CDI and Java EE support gaps in Eclipse - hence the question.It is definitely very good that a clear majority said they were using CDI. CDI is key to writing effective Java EE applications. This data point goes a long way to removing the severe CDI skepticism in certain corners of the Java EE ecosystem. The 19% that responded that they did not know what CDI was pose both a challenge and an opportunity. If you are a Java EE or CDI fan it should tell you that there are colleagues that you should educate on CDI. I am often still taken aback when a developer does not know what CDI is or still refers to Java EE as "J2EE" (the term J2EE has been long retired with the likes of "J2SE" and COM/DCOM). A large number of these same developers are very pleasantly surprised to learn how much modern Java EE can help make their day-to-day work easier.No survey is perfect of course. The sample data size for the survey is small but respectable at around 300. Around 500-1000 data points is probably more representative of the Java ecosystem. Since it is a Twitter survey it is probably highly susceptible to selection bias. That being said the results are definitely good enough to think about seriously.

The good folks over at Genuitec developing MyEclipse recently asked the Twittersphere about real world CDI usage. They ran a week-long Twitter survey asking the simple question - "Do you use CDI in...

JavaEE

Migrating from Java EE 5 to Java EE 7 at Segurnet Portugal

One of the most important things to do at this stage of the life-cycle of Java EE is highlight successful adoption stories at a regular cadence. We have been doing just that for a long time through our adoption stories blog, this humble blog as well as JavaOne. Indeed JavaOne 2015 was particularly good in this regard. We had a number of solid adoption stories submitted that we could select from. We will highlight all of those stories here in the coming months. A particularly nice adoption story presented at JavaOne 2016 was from Segurnet Portugal on migrating from Java EE 5 to Java EE 7.Segurnet is a data sharing platform for key insurers in Portugal. It used by 65 companies, about 30,000 users with close to 1.5 million page views and over 3 million server requests. Roberto Cortez detailed how the platform was recently migrated from legacy Java EE 5 to Java EE 7 - showing specific code examples. As the end result of the migration Roberto noted latest technology adoption, improved standardization, simplicity, a net reduction in code, an increase in productivity, faster deployment times and better performance. Roberto's experience is typical for anyone considering such a migration. You can view the session below (click here if you are having trouble seeing the embedded video). The slide deck for the talk is available on SlideShare. For those unaware, Roberto is a passionate Java EE advocate, frequent speaker, blogger and JUG leader. He now works on the TomEE Java EE application server. If you have a similarly great Java EE adoption story to share with the community (particularly migration stories from other technologies), please do feel encouraged to reach out. In the spirit of Java EE centric vendor neutrality, what Java EE implementation or tool set you choose does not matter at all and neither does which part of the globe you are in.

One of the most important things to do at this stage of the life-cycle of Java EE is highlight successful adoption stories at a regular cadence. We have been doing just that for a long time through...

JavaOne

Migrating from Tomcat to Java EE and TomEE at Dassault Systemes

One of the most important things to do at this stage of the life-cycle of Java EE is highlight successful adoption stories at a regular cadence. We have been doing just that for a long time through our adoption stories blog, this humble blog as well as JavaOne. Indeed JavaOne 2016 was particularly good in this regard. We had a number of solid adoption stories submitted that we could select from. We will highlight all of those stories here in the coming months. A particularly nice adoption story presented at JavaOne 2016 was from Dassault Systemes. Although the average developer and consumer is probably not aware of Dassault Systemes, it is a company that powers many of the world's most critical industrial processes. It is one of the global leaders in 3D modelling (think CAD/CAM), product life-cycle management systems. Just some companies that rely on Dassault Systemes include the likes of Boeing, Toyota, BMW, Mercedes, Honda, Samsung, Coca Cola, Nokia, Nikon, Panasonic, LG, Procter & Gamble, GE, Johnson & Johnson and Exxon. French based Dassault Systemes is recognized to be one of the most innovative companies in the world. The company offers it's products both on-premise and as SaaS on their own cloud. The company chose to standardize their very diverse set of products geared towards various industry verticals on Java EE and TomEE. They cited reasons like ensuring consistency throughout a large number of systems, avoiding third-party jar/configuration/class-path hell, providing a fully supported uniform stack, portability and modernizing technology in a managed, sustainable fashion. Their migration experience was quite varied and represents the gamut of what others can expect in adopting Java EE. They migrated a large number of Tomcat based applications using various third-party libraries to Java EE. They also migrated over legacy C/C++ applications as well as legacy J2EE applications. They even ported from one Java EE application server to another to get to a common base with TomEE. TomEE was cited as a particularly easy way to migrating from Tomcat to Java EE. They are looking forward to TomEE moving ahead with Java EE 7 support. The session explains their entire migration story in a concise, clear fashion. You can view the session below (click here if you are having trouble seeing the embedded video). If you have a similarly great Java EE adoption story to share with the community (particularly migration stories from other technologies), please do feel encouraged to reach out. In the spirit of Java EE centric vendor neutrality, what Java EE implementation or tool set you choose does not matter at all and neither does which part of the globe you are in.

One of the most important things to do at this stage of the life-cycle of Java EE is highlight successful adoption stories at a regular cadence. We have been doing just that for a long time through...

JavaOne

AngularBeans: Java EE 7/CDI Integration with AngularJS

In the highly volatile world of JavaScript frameworks, AngularJS has managed to maintain a lead at least for now. The good news for Java EE developers is that Java EE generally and Java EE 7 in particular works extremely well as a back-end for frameworks like AngularJS. To see why this is you need not look much farther than my talk on the topic and the corresponding example code (the code is deliberately self-contained with setup instructions so that you can explore it in detail on your own). One of the drawbacks of the JavaScript rich client approach is that it often involves some boilerplate code that does not exist in server-side web frameworks due to the remote communication layer involved. To borrow concepts from the old J2EE design patterns, this boilerplate involves the creation and maintenance of DTOs (Data Transfer Objects) and remote proxies, not to mention the plumbing code necessary for the remote communication.  If you look carefully at my code example the boilerplate is not that hard to spot. One way of avoiding this boilerplate is a tight binding layer with the underlying back-end technology that automatically generates the DTO, remote proxy and remote plumbing parts. In the process the binding layer can bring a lot of interesting back-end features forward to the client as well. Fortunately for the Java EE ecosystem, my Tunisian friend Bessem Hmidi has formulated just such a solution focusing on CDI as the back-end component model. He has aptly named his project AngularBeans and the project is now on GitHub for everyone to use. I am very happy that we were able to host Bessem at JavaOne 2015 to talk about the project. In his session he explained the basic motivation for AngularBeans, discussed the features he has implemented so far and did quite a bit of live coding in the process! You can view the session below (click here if you can't see the embedded video). The session really speaks volumes as to the power of the solution and why it is a very valuable part of the CDI/Java EE ecosystem. The project is at a very early stage, so this is a great time to get involved, evaluate the project and perhaps even contribute.

In the highly volatile world of JavaScript frameworks, AngularJS has managed to maintain a lead at least for now. The good news for Java EE developers is that Java EE generally and Java EE 7...

JavaEE

Hypermedia/HATEOAS Support in JAX-RS 2/Java EE 7

The concepts of Hypermedia and HATEOAS (shorthand for the mouthful of "Hypermedia as the Engine of Application State") have made the rounds in the REST ecosystem for a little while now. If you Google around a bit you'll find no shortage of arcane academic-sounding text describing it's supposed universal virtues. For the rest of us a simple explanation is that it is an attempt to utilize web page style links in REST based web services. Using the hypermedia concept, you can send the client links for what they may be able to do further after receiving a REST response. A simple example is including links for canceling or getting details for an order in addition to a confirmed order object probably retrieved via a GET request. Although less common, links can also be embedded as data within the response. An example would be embedding a link to retrieve the delivery address in the order data body instead of embedding the actual address body or an address ID. Finding a reasonably down-to-earth, unpretentious explanation of Hypermedia was shockingly difficult. The best I could find is the humble documentation for the PayPal Payment REST API that makes real world use of Hypermedia. In practical terms Hypermedia helps make clients more flexible by avoiding hard-coding REST URLs. It can also help in self-documenting REST APIs. If you look around on the web it is an open question whether these purported benefits are actually worth the additional implementation complexity. Hypermedia may be best applied in a situation when you are developing a public API where you do not know much about potential users of the API. The PayPal Payment REST API is a good example of such a case. The good news is that if you have a good use case for Hypermedia Java EE 7 adds support for it via JAX-RS 2. Sam Sepassi recently did an excellent write-up detailing the newly added API. It is far and away the best write-up that exists on the topic. He includes a brief explanation of Hypermedia including example code using JAX-RS 2. He also included some details on experimental work that is being done in the Jersey JAX-RS RI to include support for declarative Hypermedia (the Hypermedia APIs added in JAX-RS 2 are basically programmatic). Enjoy and feel free to share with anyone that you might think would find this useful.

The concepts of Hypermedia and HATEOAS (shorthand for the mouthful of "Hypermedia as the Engine of Application State") have made the rounds in the REST ecosystem for a little while now. If you Google...

JavaEE

Java EE in Practice at Lufthansa Industry Solutions

One of the most important things to do at this stage of the life-cycle of Java EE is highlight successful adoption stories at a regular cadence. We have been doing just that for a long time through our adoption stories blog, this humble blog as well as JavaOne. Indeed JavaOne 2016 was particularly good in this regard. We had a number of solid adoption stories submitted that we could select from. We will highlight all of those stories here in the coming months. A nice JavaOne 2016 session to start with is the one from Lufthansa industry solutions. Lufthansa industry solutions develops systems both internally at Lufthansa as well as for external customers. They chose to standardize on Java EE to ensure consistency throughout a large number of systems. The session explains what the organization does, it's architectural approach and why they chose Java EE. The session also dives into some interesting details on two different Java EE applications (one still using Java EE 6 and one already on Java EE 7) that Lufthansa industry solutions developed for clients. The session touches upon how Java EE applications can take advantage of most of the practical benefits of microservices without the added complexity. The applications use a mix of WildFly and JBoss EAP along with other JBoss ecosystem projects like Hibernate Envers, Hibernate Search, Drools. The applications also used ICEfaces and PrimeFaces (the older Java EE 6 application used ICEfaces while the newer Java EE 7 application uses PrimeFaces). You can view the session below (click here if you are having trouble seeing the embedded video). If you have a similarly great Java EE adoption story to share with the community (particularly migration stories from other technologies), please do feel encouraged to reach out. In the spirit of Java EE centric vendor neutrality, what Java EE implementation or tool set you choose does not matter at all and neither does which part of the globe you are in.

One of the most important things to do at this stage of the life-cycle of Java EE is highlight successful adoption stories at a regular cadence. We have been doing just that for a long time through...

JavaEE

Adam Bien Impressed by Java EE 7 Support in WebLogic

As many of you are aware WebLogic 12.2.1 now offers full Java EE 7 commercial support. Recently Java rock star Adam Bien took Java EE 7 support in WebLogic for a spin and was impressed. He commented on fast startup, low memory footprint, fast deployments, excellent NetBeans integration and solid Java EE 7 compliance. You can read Adam's full write-up here. None of this of course is incidental. WebLogic is a mature product with an extremely large existing deployment base. With those strengths often comes the challenge of usability and WebLogic is no exception. Nonetheless many folks that haven't kept up-to-date with WebLogic evolution don't realize that usability and performance have long been a continued core focus. That is why folks like Adam are often pleasantly surprised when they take an objective fresh look at WebLogic. You can give WebLogic 12.2.1 a try yourself here. There is no need to pay for anything as you can use a free OTN developer license (this is what Adam used as per the instructions on his post). You can also use an official Docker image here. Solid Java EE support is of course the tip of the iceberg (albeit an extremely important tip of the iceberg) as to what WebLogic offers. WebLogic offers a depth and breadth of proven features geared towards mission-critical, 24x7 operational environments that few other servers come close to. One of the best ways to observe this is taking a quick glance at the latest WebLogic documentation.

As many of you are aware WebLogic 12.2.1 now offers full Java EE 7 commercial support. Recently Java rock star Adam Bien took Java EE 7 support in WebLogic for a spin and was impressed. He...

JavaEE

Season's Greetings and Happy New Year from the GlassFish/Java EE Team

On behalf of the GlassFish and Java EE team at Oracle I wish you and your family Season's Greetings and a very Happy New Year. This has been another important year for us. We continued our evangelism efforts worldwide, released GlassFish 4.1.1, started the GlassFish 5 branch, released a number of early drafts for critical Java EE 8 JSRs, strengthened the Adopt-a-JSR program and offered full commercial support for Java EE 7 through the best-in-class WebLogic 12.1.2 offering. In a similar vein we saw the number of available Java EE 7 options expand especially with WebSphere Liberty. We were able to warmly welcome Siwpas as a new entrant into the Java EE compatibility family. Most encouragingly we were able to share a number of real world Java EE 7 adoption stories with you and saw strong developer support for the Java EE 7 platform as well as key APIs like JSF and JPA. We are ever thankful for your support and we hope to continue to try our best to serve your interests, perhaps against what many would consider pretty tall odds. In the coming year it is obvious we will see commercial Java EE 7 support via JBoss EAP very soon. We hope we will also see other strong Java EE 7 options such as TomEE. We hope to continue to move the Java EE 8 specifications and GlassFish 5 forward with support from our community and our JCP compatriots. On the cloud front we will very likely bring Java EE 7 to the commercial Oracle Cloud. If the current momentum of Java EE 7 holds we are sure to be able to share many more great real world adoption stories with you. We will look forward to working harder than ever in engaging you through our development and evangelism efforts certainly including this humble community blog. As you know I and my colleague David Delabassee are the primary maintainers of this blog. Both David and I will be enjoying some well-earned time-off with our families the next few days. As a result the guns will be mostly quiet at this particular Java bulwark to return recharged and full force in the new year. Until then, thanks and best wishes once again. We hope to see you next year!

On behalf of the GlassFish and Java EE team at Oracle I wish you and your family Season's Greetings and a very Happy New Year. This has been another important year for us. We continued our evangelism...

JavaEE

Java EE 7 in Production at Commerzbank

One of the most important things to do at this stage of the life-cycle of Java EE is highlight successful adoption stories at a regular cadence. We have been doing just that for a long time through our adoption stories blog, this humble blog as well as JavaOne. In the past few months celebrated Java EE advocate and Java Champion Adam Bien has been really helping out in this regard as well through his popular blog. One of the recent cases Adam highlighted is production Java EE 7 usage at Commerzbank. For those unaware, Commerzbank is one of the largest international financial institutions based in Germany. The bank implements a number of applications based on Java EE 7 and AngularJS. The front end AngularJS application communicates securely with the back-end using REST powered by JAX-RS and Java EE 7. Timo, a senior engineer with Commerzbank, noted the simplicity, ease-of-use and productivity offered by Java EE 7. He also noted very lightweight war deployments and lack of any complex application dependencies with Java EE. The team also utilizes Java SE 8, NetBeans and Jenkins. You can read the full details of the adoption story on Adam's blog. JavaOne 2015 was particularly good in terms of compelling Java EE adoption story sessions. We will share the details of those stories here, including session videos, in the coming weeks and months. If you have a similarly great Java EE adoption story to share with the community (particularly migration stories from other technologies), please do feel encouraged to reach out. In the spirit of Java EE centric vendor neutrality, what Java EE implementation or tool set you choose does not matter at all and neither does which part of the globe you are in.

One of the most important things to do at this stage of the life-cycle of Java EE is highlight successful adoption stories at a regular cadence. We have been doing just that for a long time through...

JavaEE

Content Negotiation using 'q' Factors with JAX-RS 2/Java EE 7

When we think of HTTP and content negotiation most of us probably immediately think of mime-types. Agreeing upon the mime-type is indeed part of the HTTP conversation between a client and a server. However HTTP has also had an even finer grained content negotiation mechanism called the relative quality factor or 'q' factor for short. 'q' factors are so far not that well supported by browsers and are even more unknown to most developers. Using a q-factor, a client can specify a preference for the mime-type they want if they are able to support multiple mime-types (let's say to state a preference for PNG over JPG). The 'q' factor is essentially a number between 0.0 and 1.0 tacked onto the mime-type. A higher value indicates a more preferred mime-type. Similarly the server can also indicate what mime-type it prefers to send as a response by specifying a 'qs' factor or quality of source factor. The best written explanation of 'q' factors that I could find is here. Note that the article also points out the somewhat obscure nature and poor browser support for 'q' factor based negotiation in the web world so far. It does however point out the fact that Apache httpd has long had strong support for 'q' factors. 'q' factor based negotiation can be very valuable in REST. It can help you write a more robust service API. For example, you could support both JSON and XML for a resource and then state that you prefer JSON over XML if the client supports both. Similarly you can write more powerful clients that can flexibly process multiple content types. These capabilities are especially helpful while writing public APIs with REST or dealing with heterogeneous clients that you cannot completely predict. The same is true on the client side as well especially while dealing with third-party services. The good news for you is that JAX-RS 2 and Java EE 7 has strong support for 'q' factor based content negotiation. Sam Sepassi did a very nice job explaining the feature in a recent article. You should give it a read and consider using it if you have a good use case for the feature.

When we think of HTTP and content negotiation most of us probably immediately think of mime-types. Agreeing upon the mime-type is indeed part of the HTTP conversation between a client and a server....

Community

2015 Duke’s Choice Award Winners Announced

The incredible amount of innovation that uses and builds upon standard Java/EE technologies is one the most important factors that keeps our ecosystem so uniquely strong. The annual Duke's Choice Awards is a small way of recognizing and encouraging such innovation. Every year a panel of judges gives out ten of these awards at JavaOne (in the interest of full disclosure I am one of those judges). Every year Java EE makes a strong showing at the awards and this year was no exception (in fact I'll share that Java EE makes an even stronger showing in the total number of nominees). In particular the following winners are worth highlighting on this humble blog. UN/WFP School Subsidy Card: Thousands of students in developing countries lack access to adequate food, Egypt is sadly no exception. Egypt based consulting company e-Finance developed the United Nations’ World Food Program (UN/WFP) School Subsidy Card to help combat this problem. The project was developed for Egypt’s Ministry of Education. The project is now live as a pilot that helps 20,000 families in two poor cities. The project uses Java EE 7, Java SE 8, GlassFish 4 and NetBeans. The project is led by Mohammed Taman. Mohammed is an experienced architect, consultant, Morocco JUG member, Egypt JUG leader, JCP executive committee member and expert group member for multiple JSRs. He is an ardent advocate for Java EE and has been a very active participant in the Adopt-A-JSR, Adopt-OpenJDK, and FishCAT programs. Mohammed's work was highlighted at JavaOne, including in the Java EE portion of the keynote. OmniFaces: One of the core strengths of JSF is the ecosystem built around it, in particular popular component libraries like PrimeFaces. Though not a component library, OmniFaces is a rising star in the JSF ecosystem. It is a collection of useful utilities for JSF developers. If you were familiar with Seam Faces, OmniFaces reminds me quite a bit of it. OmniFaces is led by Arjan Tijms and Bauke Scholtz - two JSF/Java EE community heroes in their own right. Bauke is one of the foremost JSF community experts. Many in the JSF community know him as BalusC - the ever present voice online always ready to help with very knowledgeable and helpful answers to JSF questions anywhere! Similarly Arjan has long been a strong contributor to the JCP and many of his good ideas are already standardized in Java EE. You can find out more about OmniFaces here. KumuluzEE: The ranks of fat jar solutions targeting microservices hype in the Java EE ecosystem seems to be ever expanding. There is WildFly Swarm, Payara Micro/GlassFish Embedded as well as TomEE embedded. KumuluzEE is an interesting part of this crowd as unlike the others it does not come from a traditional application server pedigree and is a very community based project that still uses Java EE APIs to create a fat jar solution. KumuluzEE is led by Slovenian Java Champion Matjaz B. Juric. Besides being a Java Champion Matjaz's impressive credentials include simultaneously being an Oracle ACE Director and IBM Champion! You can find out more about KumuluzEE here. I'd like to take this opportunity to congratulate all of the winners, most certainly not just the ones above. You can find out about all of this year's winners here. 

The incredible amount of innovation that uses and builds upon standard Java/EE technologies is one the most important factors that keeps our ecosystem so uniquely strong. The annual Duke's Choice...

JavaEE

WebLogic Now Java EE 7 Compatible!

With the greatest pleasure I can report that WebLogic 12.2.1 has recently been fully Java EE 7 certified! This represents full commitment from Java steward Oracle to commercial support for Java EE 7. WebLogic joins the ranks of GlassFish 4, WildFly 8, WebSphere Liberty Profile 8.5, Hitachi Cosminexus and TmaxSoft JEUS. With the very broad customer base that both Oracle and WebLogic have globally this is very welcome news for Java EE 7 indeed. All of the Java EE certified offerings are always listed on the official Java EE compatibility page. As many of you are aware, Java EE 7 is one of the most extensive set of changes to the platform in it's history. Similarly WebLogic 12.2.1 is one of the most significant releases of WebLogic in many years, even not counting full Java EE 7 support. In addition to Java EE 7 support WebLogic 12.2.1 brings two significant sets of changes. The first is what is referred to as multitenancy. WebLogic multitenancy brings greater isolation similar to what one can accomplish through Linux containers like Docker or traditional virtualization - only applied natively at the WebLogic runtime level. What this means is that multiple applications can run completely isolated from each other on the same WebLogic runtime as though they were running on different domains. The multitenancy concept is intended to be implemented seamlessly across Oracle products in the data center including the Oracle JDK, Coherence, Traffic Director and the Oracle Database. This is a concept currently unique to the Oracle stack. WebLogic 12.2.1 also builds on the traditional strengths of the product with regards to high availability. A number of features have been added to improve 100% up time capabilities through live patching, live upgrades, clustering, load-balancing, fail-over and replication, especially in large, multi data center, disaster recovery capable deployments.  The following are the most important links you should explore: The full announcement for the WebLogic 12.2.1 release. The download link for WebLogic 12.2.1 - you can try it for free. The full documentation for WebLogic 12.2.1. Official Docker images for WebLogic 12.2.1. The official WebLogic blog that's being actively updated with 12.2.1 feature details. It is worth reminding that prior to 12.2.1, the WebLogic 12.1.3 release supported the Java EE 7 APIs that many customers indicated they thought were most important -  WebSocket, JSON-P, JAX-RS 2 and JPA 2.1. Also note that like 12.1.3, WebLogic 12.2.1 is certified for Java SE 8. Though it is not there yet, WebLogic 12.2.1 will soon also be available on the Oracle Cloud - representing full Java EE 7 commercial support on the cloud from Oracle. So the question now is who will be next to cross the Java EE 7 compatibility finish line. JBoss EAP 7 recently released an alpha with Java EE 7 support - this is in addition to Red Hat's long standing Java EE 7 compatibility through WildFly. Similarly WebSphere Classic released a beta showing Java EE 7 support in addition to the existing IBM full commercial Java EE 7 support through WebSphere Liberty. It is clear there will be at least two more significant Java EE 7 commercial platforms in the next few months. The Apache TomEE team is also working on bringing forward Java EE 7 features. For some perspective, few other open standards such as SQL have as many available implementations as Java EE 7 already has.

With the greatest pleasure I can report that WebLogic 12.2.1 has recently been fully Java EE 7 certified! This represents full commitment from Java steward Oracle to commercial support for Java EE 7....

JavaEE

2015 JCP Award Winners Announced

An open standard like Java EE involves a lot of hard work from a lot of different groups of people. The hard work of these people, largely selflessly, benefit countless Java developers. For specification leads the work in the JCP is often far beyond just a job. I have seen the same to be true of many vendor experts on a specification. Especially admirable are the independents that contribute to specifications largely on their own time as well as Adopt-a-JSR participants. The annual Java Community Process awards is a small way of recognizing some of these great people and their work. There are four different awards: JCP member or participant of the year Outstanding specification lead Most significant JSR Outstanding Adopt-a-JSR participant The following are the nominations I had personally made for this year's awards (in no particular order): Josh Juneau (for outstanding Adopt-a-JSR participant) Arjan Tijms (for JCP member of the year) Adam Bien (for JCP member of the year) David Blevins (for JCP member of the year) Ivar Grimstad (for JCP member of the year) Antoine Sabot-Durand (for outstanding specification lead) Manfred Riem and Santiago Pericas-Geertsen jointly (for outstanding specification lead) CDI 2 (for most significant JSR) MVC 1.0 (for most significant JSR) The winners of the JCP awards were announced in a lavish party during JavaOne 2015. I am happy to see that one of my nominations - Adam Bien - won this year and the others were strong contenders. I am also happy to see the other winners - Anatole Tresch (for outstanding specification lead), JSR 363 - Units of Measurement API (for most significant JSR) and Rajmahendra Hegde/JUG Chennai (for outstanding Adopt-a-JSR participant). In particular JUG Chennai has long been a strong supporter for Java EE through the Adopt-a-JSR program. I would encourage you to read a bit about the winners and all of the nominees. It's no surprise Java EE has a strong showing in the nominations. These are all true Java heroes in my book. All the details are posted on jcp.org for you to take a look at.

An open standard like Java EE involves a lot of hard work from a lot of different groups of people. The hard work of these people, largely selflessly, benefit countless Java developers....

Community

Java EE @ Devoxx Belgium

As you can see from the following outline, Java EE will have again a strong presence at Devoxx this week in Antwerp - Belgium. Reza and myself will be around, we will have the opportunity to meet you?  Monday Nov. 9 Java EE 7 in Action Reza Rahman 13:30 - 16h30 (University) Docker Tooling for JavaEE Developers Xavier Coulon 18:05 - 18:35 (Tools in Action) Tuesday Nov. 10 Refactor your Java EE application using Microservices and ContainersArun Gupta 09:30 - 12:30 (University) CDI : or how to extend Java EE in a portable way Antonio Goncalves & Antoine Sabot-Durand13:30 - 16:30 (University) Apache Tomcat to Apache TomEE in 1-n StepsAndy Gumbrecht 17:25 - 17:55 (Tools in Action) Java EE Microservices - the Payara way Mike Croft 18:05 - 18:35 (Tools in Action) Wednesday Nov. 11 JSF with PrimeFaces, From Ugly Duckling to a Beautiful Swan Cagatay Civici 14:00 - 15:00 (Conference) Java EE BoF David Delabassee et al. 20:00 - 21:00 (BoF) WildFly Community BOF and V10 update Dimitris Andreadis 21:00 - 22:00 (BoF) Thursday Nov. 12 Java SE 8 for Java EE Developers David Delabassee & José Paumard 09:30 - 10:30 (Conference) Updates to the Java API for JSON Processing for Java EE 8 Alex Soto & Mite Mitreski 10:50 - 11:50 (Conference) Badass Microservices – Deploy, Build and Scale Your Apps with Payara MicroNavin Surtani13:10 - 13:50 (Quickie) Develop and Deploy your JavaEE micro service in less than 5 minutes with Apache TomEEAlex Soto13:10 - 13:15 (Ingite) CDI 2.0 is coming Antoine Sabot-Durand & José Paumard 14:00 - 15:00 (Conference) MVC 1.0 - by Example Ivar Grimstad & Rene Gielen 15:10 - 16:10 (Conference) Java EE Security API Jean-Louis Monteiro 17:50 - 18:50 (Conference)  Friday Nov. 13 HTTP 2.0 & Java: Current Status Simone Bordet 10:45 - 11:45 (Conference)

As you can see from the following outline, Java EE will have again a strong presence at Devoxx this week in Antwerp - Belgium. Reza and myself will be around, we will have the opportunity to meet you? ...

JavaOne

Java EE @ JavaOne 2015 - Day 4

JavaOne 2015 is almost over! Here is the last set of Java EE related sessions to attend today (Thursday Oct. 29) Using Java SE 8 with Java EE 7 in the Real World [CON7902] Michael Santos, Head of Development & Operations, TecSinapse 9:00 a.m. | Parc 55—Mission Cloudy with a Chance of Java: Building Multitenant Java EE Cloud Applications [CON2265] Jason Lee, Principal Software Engineer, NetSuite, Inc. 10:30 a.m. | Parc 55—Market Street Migrating to TomEE and Java EE: A Success Story [CON1973] Michael Finocchiaro, Sr Architect, 3DEXPERIENCE Platform, Dassault Systèmes Boris Tabenkin, Platform Modeling R&D Solution Architecture Director, Dassault Systemes 10:30 a.m. | Parc 55—Mission Reactive Java EE: Let Me Count the Ways! [CON2576] Reza Rahman, Java EE Evangelist, Oracle 10:30 a.m. | Parc 55—Cyril Magnin II/III Apache Lucene for Java EE Developers [CON3538] Sanne Grinovero, Principal Software Engineer, Red Hat 2:30 p.m. | Parc 55—Mission Java EE Application Servers: Multitenant or Containerized? Both! [CON7506] Bruno Borges, Principal Product Manager, Oracle 2:30 p.m. | Parc 55—Cyril Magnin II/III Innovating Democracy with Java EE and Open Source [CON4218] Alex Soto Bueno, Software Engineer, CloudBees 4:00 p.m. | Parc 55—Mission Digital Java EE 7 with JSF Conversations, Flows, and CDI Scopes [CON5211] Peter Pilgrim, Java and Scala Developer Contract Consultant, Independent Contractor 4:00 p.m. | Parc 55—Cyril Magnin I AngularBeans: A Modern Real-Time Java EE/CDI Back End for AngularJS [CON4316] Hmidi Bessem, R&D Engineer @ESPRIT, ESPRIT 4:00 p.m. | Parc 55—Cyril Magnin II/III

JavaOne 2015 is almost over! Here is the last set of Java EE related sessions to attend today (Thursday Oct. 29) Using Java SE 8 with Java EE 7 in the Real World [CON7902] Michael Santos, Head of...

JavaOne

Java EE @ JavaOne 2015 - Day 3

If you're at JavaOne, here are the Java EE related sessions for today (Wednesday Oct. 28). Java EE Connectors: The Secret Weapon Reloaded [CON7749] David Blevins, Founder, Tomitribe Jonathan Gallimore, Senior Software Engineer, Tomitribe 8:30 a.m. | Parc 55—Cyril Magnin I Tales of Migration from Java EE 5 to 7 [CON3212] Roberto Cortez, Senior Software Engineer, Tomitribe 8:30 a.m. | Parc 55—Cyril Magnin II/III Secure Java EE Architecture and Programming 101 [CON4155] Mario-Leander Reimer, Chief Technologist, QAware GmbH 11:30 a.m. | Hilton—Plaza Room B New and Noteworthy in Jersey 2 [CON2882] Petr Janouch, Developer, Oracle 11:30 a.m. | Parc 55—Mission Real-World Batch Processing with Java EE [CON3339] Arshal Ameen, Team Manager, Rakuten, Inc. Hirofumi Iwasaki, Group Manager, Rakuten, Inc. 11:30 a.m. | Parc 55—Cyril Magnin II/III Java SE 8 for Java EE Developers [CON2483] Edward Bratt, Senior Development Manager, Oracle José Paumard, CTO, JPEFI 1:00 p.m. | Parc 55—Powell I/II WebSocket in Enterprise Applications [CON6446] Pavel Bucek, Principal Software Engineer, Oracle 1:00 p.m. | Parc 55—Cyril Magnin II/III Down-to-Earth Microservices with Java EE [CON2577] Steve Millidge, Founder Payara, C2B2 CONSULTING LIMITED Reza Rahman, Java EE Evangelist, Oracle 1:00 p.m. | Parc 55—Mission Penn State: Java EE 7 in the Very Real World of Higher Education [CON3564] Christopher Harm, IT Manager, Pennsylvania State University Steve Moyer, Enterprise Software Architect, The Pennsylvania State University Shawn Smith, Director of Software Engineering, Penn State University 3:00 p.m. | Parc 55—Powell I/II EJB 3.2/JPA 2.1 Best Practices with Real-Life Examples [CON7535] Ahmad Gohar, Architect and Technical Team Leader, IBM 3:00 p.m. | Parc 55—Mission Docker for Java EE Developers [HOL7249] Rafael Benevides, Senior Software Engineer, Red Hat Markus Eisele, Developer advocate, Red Hat GmbH 3:00 p.m. | Hilton—Franciscan Room B/C/D Java EE in Practice at Lufthansa Industry Solutions [CON3610] Lars Bilger, Consultant, Lufthansa Industry Solutions AS GmbH Ed Burns, Consulting Member of Technical Staff, Oracle Ivo Kammerath, Software Engineer, Lufthansa Industry Solutions 3:00 p.m. | Parc 55—Cyril Magnin II/III The Java EE 8 Opportunity [CON6086] David Blevins, Founder, Tomitribe 4:30 p.m. | Parc 55—Cyril Magnin II/III Standardized Extension-Building in Java EE with CDI and JCA [CON2385] Jason Porter, Senior Software Engineer, Red Hat Inc 4:30 p.m. | Parc 55—Mission Java EE to Microservices Automagically [CON7641] Alexandre Porcelli, Principal Software Engineer, Red Hat 4:30 p.m. | Parc 55—Embarcadero

If you're at JavaOne, here are the Java EE related sessions for today (Wednesday Oct. 28). Java EE Connectors: The Secret Weapon Reloaded [CON7749] David Blevins, Founder, Tomitribe Jonathan Gallimore,...

JavaOne

Java EE @ JavaOne 2015 - Day 2

Here are some interresting Java EE related sessions that will be presented today (Tuesday Oct. 27) at JavaOne. Java EE Lab 101: An Introduction [HOL1659]Frank Greco, Director of Technology, NYJavaSIGDavid Heffelfinger, Chief Technology Officer, Ensode Technology, LLCReza Rahman, Java EE Evangelist, Oracle8:30 a.m. | Hilton—Franciscan Room B/C/D Deploying Elastic Java EE Microservices in the Cloud with Docker [TUT3238]Steve Millidge, Founder Payara, C2B2 CONSULTING LIMITED8:30 a.m. | Parc 55—Market Street Modern Web Apps with HTML5 Web Components, Polymer, and Java EE MVC 1.0 [TUT3244]Kito Mann, Principal Consultant, Virtua, Inc.8:30 a.m. | Parc 55—Mission Advanced CDI in Live Coding [TUT2376]Antoine Sabot-Durand, Senior Software Engineer, Red HatAntonin Stefanutti, Senior Software Engineer, Red Hat8:30 a.m. | Parc 55—Cyril Magnin II/III EJB/CDI Alignment: What Does It Mean? [CON7668]David Blevins, Founder, TomitribeJean-Louis Monteiro, Director of Engineering, Tomitribe11:00 a.m. | Parc 55—Cyril Magnin I Finally, the Java EE Security API (JSR 375) [CON3659]Alex Kosowski, Principal Member Technical Staff, Oracle11:00 a.m. | Parc 55—Mission Down and Dirty with JMS 2 [HOL2575]Chihiro Ito, Principal Consultant, OracleSalim KAYABASI, Sr. Developer, Self EmployedHasan Keklik, Senior Software Developer, ÖdeAlReza Rahman, Java EE Evangelist, Oracle12:30 p.m. | Hilton—Franciscan Room B/C/D Integrating JavaServer Faces and HTML5 [CON1784]David Heffelfinger, Chief Technology Officer, Ensode Technology, LLC12:30 p.m. | Parc 55—Cyril Magnin I Servlet 4.0: HTTP/2 and Reactive Programming in Java EE 8 [CON3629]Ed Burns, Consulting Member of Technical Staff, OracleShing wai Chan, Principle Member of Technical Staff, Oracle12:30 p.m. | Parc 55—Cyril Magnin II/III What’s New in the Java Persistence API (JSR 338) [CON7631]Lukas Jungmann, JPA Specification Lead, Oracle12:30 p.m. | Parc 55—Mission JPA in Reverse: Pushing Database Events to Java EE Applications in Real Time [CON7718]Jean-Philippe Laroche, Coherence integration architect, Kafeine Consulting Inc.Randal Stafford, Architect At-Large, Oracle2:30 p.m. | Parc 55—Mission Tuning JavaServer Faces [CON3239]Kito Mann, Principal Consultant, Virtua, Inc.2:30 p.m. | Hilton—Imperial Ballroom A Introduction to MVC 1.0 (JSR 371) [CON4176]Santiago Pericasgeertsen, Consulting Member of Technical Staff, Oracle2:30 p.m. | Parc 55—Cyril Magnin I Java EE Revisits GoF Design Patterns [CON3884]Reza Rahman, Java EE Evangelist, OracleMurat Yener, Software Developer, Intel4:00 p.m. | Parc 55—Mission JSR 373: New Java EE Management API [CON2876]Martin Mares, Software Developer, Oracle4:00 p.m. | Parc 55—Cyril Magnin II/III Penn State: Java EE 7 in the Very Real World of Higher Education [CON3564]Christopher Harm, IT Manager, Pennsylvania State UniversitySteve Moyer, Enterprise Software Architect, The Pennsylvania State UniversityShawn Smith, Director of Software Engineering, Penn State University4:00 p.m. | Parc 55—Cyril Magnin I, will be repeated on Oct 28, 3:00 p.m. Meet Snoop, a Discovery Service for Java EE [CON1615]Ivar Grimstad, Principal Consultant, Cybercom Sweden5:30 p.m. | Parc 55—Embarcadero Java SE 8 for Java EE Developers [CON2483]Edward Bratt, Senior Development Manager, OracleJosé Paumard, CTO, JPEFI5:30 p.m. | Parc 55—Cyril Magnin II/III, will be repeated on Oct 28, 1:00 p.m. Let’s Discuss MVC 1.0 [BOF4180]Santiago Pericasgeertsen, Consulting Member of Technical Staff, Oracle7:00 p.m. | Parc 55—Cyril Magnin II/III How Would You Improve the Java EE Security API? [BOF3666]Ivar Grimstad, Principal Consultant, Cybercom SwedenAlex Kosowski, Principal Member Technical Staff, Oracle8:00 p.m. | Hilton—Plaza Room A Meet the Java EE Specification Leads [BOF2555]Linda Demichiel, Consulting Member of Technical Staff, OracleBill Shannon, Architect, Oracle8:00 p.m. | Parc 55—Cyril Magnin II/III Building Professional JavaServer Faces UI Components [BOF3256]Kito Mann, Principal Consultant, Virtua, Inc.9:00 p.m. | Parc 55—Cyril Magnin II/III

Here are some interresting Java EE related sessions that will be presented today (Tuesday Oct. 27) at JavaOne. Java EE Lab 101: An Introduction [HOL1659] Frank Greco, Director of Technology, NYJavaSIGD...

JavaOne

Java EE @ JavaOne 2015 - Day 1

As usual, JavaOne will be very busy. For your convenience, here is a list of interesting Java EE related sessions that are taking place today, i.e. Monday Oct. 26 at JavaOne. Java EE 7 in Action [TUT2573] Reza Rahman, Java EE Evangelist, Oracle 8:30 a.m. | Parc 55—Cyril Magnin II/III Java EE 7 and Java SE 8 Adoption at the United Nations [CON2064] Mohamed Taman, Enterprise Architect & Software Development Manager, e-Finance 11:00 a.m. | Parc 55—Cyril Magnin I Java EE 8 Work in Progress [CON2554] Linda Demichiel, Consulting Member of Technical Staff, Oracle 11:00 a.m. | Parc 55—Cyril Magnin II/III CDI 2.0: What’s in the Works? [CON2391] José Paumard, CTO, JPEFI Antoine Sabot-Durand, Senior Software Engineer, Red Hat 12:30 p.m. | Parc 55—Cyril Magnin I Refactor Your Java EE Application with Microservices and Containers [CON1700] Arun Gupta, Couchbase 12:30 p.m. | Parc 55—Market Street JavaServer Faces in Action [CON3249] Marty Hall, President, coreservlets.com 12:30 p.m. | Parc 55—Cyril Magnin II/III Cashless 3.0: Java EE 7 Proves Effective for Mission-Critical E-Payment Systems [CON2303] Andrea Folli, CTO, T.A.S. Spa 2:30 p.m. | Parc 55—Mission What’s Next for JAX-RS 2.1? [CON4192] Santiago Pericasgeertsen, Consulting Member of Technical Staff, Oracle 2:30 p.m. | Parc 55—Cyril Magnin II/III Apache DeltaSpike, the CDI Toolbox [CON2380] Rafael Benevides, Senior Software Engineer, Red Hat Antoine Sabot-Durand, Senior Software Engineer, Red Hat 2:30 p.m. | Parc 55—Cyril Magnin I What’s New in the Java API for JSON Processing? [CON3561] Kinman Chung, Software Developer 4, Oracle Alex Soto Bueno, Software Engineer, CloudBees 4:00 p.m. | Parc 55—Mission     Java EE Lab 101: An Introduction [HOL1659] Frank Greco, Director of Technology, NYJavaSIG David Heffelfinger, Chief Technology Officer, Ensode Technology, LLC Reza Rahman, Java EE Evangelist, Oracle 4:00 p.m. | Hilton—Franciscan Room B/C/D, will be repeated on Oct 27, 8:30 a.m. Is Enterprise Java Still Relevant? [CON10790] Ian Robinson, WebSphere Foundation Chief Architect, IBM Erin Schnabel, Senior Software Engineer, IBM 4:00 p.m. | Parc 55—Powell I/II What’s Coming in JMS 2.1 [CON3942]Nigel Deakin, Principal Member of Technical Staff, Oracle 4:00 p.m. | Parc 55—Cyril Magnin II/III From Macro to Micro(Services) and Back: Onstage Hacking with Java EE 7 [CON1851] Adam Bien, Java Enthusiast, Adam Bien 5:30 p.m. | Parc 55—Cyril Magnin II/III High-Performance Java EE with JCache and CDI [CON3234] Jaromir Hamala, Developer, Hazelcast Steve Millidge, Founder Payara, C2B2 Consulting Ltd. 5:30 p.m. | Parc 55—Mission What’s New in Java API for JSON Binding (JSR 367) [CON6155] Dmitry Kornilov, Software Developer, Oracle 5:30 p.m. | Parc 55—Cyril Magnin I JSF 2.3: Continued Return on Investment with Incremental Innovation [BOF3658] Ed Burns, Consulting Member of Technical Staff, Oracle 7:00 p.m. | Parc 55—Cyril Magnin I JCache 2.0: Where Do We Go from Here? [BOF6835] Chris Dennis, Principal Engineer, Terracotta Inc.Brian Oliver, Architect, Oracle 7:00 p.m. | Parc 55—Mission Most Popular Java (EE) Q&A: Airhacks.tv Live [BOF1849] Adam Bien, Java Enthusiast, Adam Bien 7:00 p.m. | Parc 55—Cyril Magnin II/III High Availability with Java EE Containers, JDBC, and Java Connection Pools [BOF7732] Jean De Lavarene, Software Development Director, Oracle Kuassi Mensah, Director Product Management, Oracle Nirmala Sundarappa, Principal Product Manager, Oracle 8:00 p.m. | Parc 55—Mission The JMS BOF [BOF4085] Nigel Deakin, Principal Member of Technical Staff, Oracle 9:00 p.m. | Parc 55—Cyril Magnin II/III Advanced PrimeFaces [BOF3245]Kito Mann, Principal Consultant, Virtua, Inc.9:00 p.m. | Parc 55—Mission 

As usual, JavaOne will be very busy. For your convenience, here is a list of interesting Java EE related sessions that are taking place today, i.e. Monday Oct. 26 at JavaOne. Java EE 7 in Action...

JavaEE

DZone Survey Shows JPA Dominates Java Persistence

For those of us that have been around Java for a while it has been a long, hard road for Java persistence. In a relatively brief period of time we have seen a chaotic flux of persistence solutions - plain JDBC, homemade JDBC utilities, Apache Commons DBUtils, TopLink, Castor/JDO (Java Data Objects), EJB 2.x Entity Beans, iBatis, Spring JDBC, and so on. For most it was a relief that our industry seemed to finally converge on ORM as an imperfect but generally workable, productive solution to the very complex problem of persistence. For many others though persistence remains a highly contentious topic. It is not too surprising then that DZone took up the topic in it's wide ranging 2015 Java Ecosystem Survey. The analysis of the results of that survey will be part of the upcoming 2015 Java Ecosystem Guide to be published during JavaOne (you can register to get it here). Fortunately DZone shared the results with a selected set of MVBs (Most Valuable Bloggers) including yours truly and gave me permission to share some preview perspectives on the data. As the title of this entry suggests the survey results bode very well for JPA.The survey asked a very simple question - "What persistence tools do you use today?". The answers included the survivors of the Java persistence wars past and some relative newcomers like jOOQ. The answers were mutually inclusive which was a wise choice that reflects reality. As the results highlighted shows, a very strong majority - almost 64% of developers voted for JPA. The closest contender lagging far behind at 37.6% was very old school plain JDBC!Also very interesting was the fact that Hibernate native was a separate choice that received only about 17% percent of votes. This represents a successful transition from non-standard APIs to open standards based APIs. For context, even after achieving near de-facto dominant position in Java persistence the Hibernate team, Gavin King and Red Hat decided to standardize on JPA. The native Hibernate APIs were also maintained as a matter of legacy as well as a space for value-added features. For a while it was unclear whether the Hibernate community will opt to make the transition to JPA. This survey clearly shows the transition has happened, paving the way for continued healthy competition in the persistence space via JPA.The surprisingly high usage of plain JDBC is notable as well. Clearly in this day and age one can do far better than using such a low level API. This data point represents an opportunity for further JPA adoption either through advocacy, migration or sensible evolution of the JPA open standard. It also represents an opportunity for more SQL-centric persistence solutions such as relative newcomer jOOQ.Overall the survey shows a fairly mature Java persistence landscape that still has a few surprises in store for us all to keep an eye on.

For those of us that have been around Java for a while it has been a long, hard road for Java persistence. In a relatively brief period of time we have seen a chaotic flux of persistence solutions -...

JavaEE

Developers Affirm Strong Support for Java EE 7 in DZone Survey

                    "The reports of my death have been greatly exaggerated."                                                                                                       – Mark Twain It sometimes seems like there has been a raging debate on the role of Java EE in server-side Java since the beginning of time. The debate is perhaps just as old and stale as the question of whether Java is finally dead or irrelevant. One of the latest dimensions of this debate has been around adoption of Java EE 7. It is not too surprising then that DZone took up the topic in it's wide ranging 2015 Java Ecosystem Survey. The analysis of the results of that survey will be part of the upcoming 2015 Java Ecosystem Guide to be published during JavaOne. Fortunately DZone shared the results with a selected set of MVBs (Most Valuable Bloggers) including yours truly and gave me permission to share some preview perspectives on the data. As the title of this entry suggests the survey results bode well for Java EE 7 specifically and Java EE generally.The survey asked a very simple question - "Which of the following Java platforms do you use today?", including various versions of Java EE and some key alternative technologies as mutually inclusive answers (I think the mutually inclusive part is an important reality check towards the aforementioned debate that generally tends to have a tone of mutual exclusion). As the results highlighted shows, almost 39% of developers chose Java EE 7. A total of over 90% responses chose one version of Java EE or the other - well ahead of the other technologies listed. Java EE 7 community support seems to have already edged out the very well regarded Java EE 6 release. These patterns will likely get even stronger with the recent Java EE 7 release of WebSphere Liberty and full commercial support of Java EE 7 through WebLogic and JBoss EAP in the next coming months.Fortunately we also have interesting past data points to compare in the RebelLab's 2014 Java Tools and Technologies Landscape survey. That survey asked similar but slightly different questions with regards to Java EE. In that survey 68% indicated that they were Java EE users, which is likely a lower rate than in the DZone survey. Most importantly a significantly higher percentage, 49% indicated Java EE 6 usage than Java EE 7 usage that stood at 35%. For clarity this report treated Java EE version usage as mutually exclusive (probably a mostly reasonable assumption). It did not attempt to collate data on Java EE vis-a-vis alternatives. To roughly compare with the DZone report format that means that of total respondents, about 24% reported Java EE 7 usage while 33% reported Java EE 6 usage. All this bodes well for Java EE and Java EE 7. The two surveys taken roughly a year apart indicate higher levels of usage for Java EE overall and strengthening community support behind Java EE 7, even as compared with Java EE 6.On behalf of the Java EE team here at Oracle it is only correct to thank everyone that indicated their support for Java EE and Java EE 7 in such surveys. Our work is intended to benefit you first and foremost - it is good to see that intent does not get lost in the muddle. As you may be aware we make an effort to highlight your success adopting Java EE in our blogs, JavaOne and through the core Java EE community. It is always a good time to drop us a note to share your story with the broader community.

                    "The reports of my death have been greatly exaggerated."                                                                                                       – Mark Twain It...

JavaOne

Kito Mann's JavaOne 2015 Sessions on JSF, MVC and HTML 5

For the Java EE track at JavaOne 2015 we are highlighting some key sessions and speakers to better inform you of what you can expect, right up until the start of the conference. To this end we recently interviewed Kito Mann. Kito is a long time JSF advocate, popular author, speaker, consultant and very prolific contributor to the JCP. Just as previous years, Kito has one of the highest number of sessions from a single speaker on the Java EE track. He spoke to us about his accepted session at JavaOne 2015 (click here if you can't see the embedded video). The following are the sessions we talked about: Advanced PrimeFaces: This informal after-hours BoF is a deep dive into the popular PrimeFaces library. If you are using PrimeFaces this is a great session to really understand how PrimeFaces works. Tuning JavaServer Faces: In this extended tutorial style session Kito offers his deep insight to effectively tuning JSF applications in the real world. I would say this is a must attend for any JSF user. Building Professional JavaServer Faces UI Components: As Kito explains building reusable components is a key value proposition for JSF. In this informal after-hours BoF Kito will cover best practices for effectively building JSF components for real world applications. Modern Web Apps with HTML5 Web Components, Polymer, and Java EE MVC 1.0: This is a very advanced technical session covering a number of very forward-looking topics. HTML5 web components are a key emerging standard for building JSF style components in vanilla HTML. Polymer is an important open source library for HTML 5 web components. In this session Kito shows how Polymer/web components can be used effectively with the upcoming MVC 1.0 standard slated for Java EE 8. The following sessions are pretty closely related to what Kito is presenting at JavaOne this year: Introduction to MVC 1.0: This talk is about the new action-oriented web framework being standardized as part of Java EE 8. Besides this technical session there is also a BoF scheduled for MVC 1.0. JSF 2.3: Continued Return on Investment with Incremental Innovation: This is an informal after-hours BoF session by specification lead Ed Burns on the incremental work being done as part of JSF 2.3. Besides these sessions, we have a very strong program for the Java EE track and JavaOne overall - just explore the content catalog. If you can't make it, you can be assured that we will make key content available after the conference just as we have always done. If you are coming, do make sure to book your sessions via schedule builder before they fill up.

For the Java EE track at JavaOne 2015 we are highlighting some key sessions and speakers to better inform you of what you can expect, right up until the start of the conference. To this end we recently...

JavaEE

Survey Confirms JSF Remains Leading Web Framework

In the past ten years or so few topics have caused as much impassioned debate as the question of what Java web framework to use. It's not too surprising then that JavaLobby/DZone recently ran a survey to see what the Java web framework usage landscape looks like today. You can take a look at the detailed results of the survey here. As the title of this blog entry suggests the results bode very well for JSF and in fact bode well for the MVC 1.0 specification targeted for Java EE 8 as well: For those of us that understand something about how open standards and de-facto "standards" form it was only a matter of time before the obviously hyper-competitive server-side web framework space was going to consolidate/converge on some kind of market consensus. This survey clearly demonstrates that is exactly what is finally happening. JSF leads with 34.5% of the market share. That is great news for the JSF community and they deserve credit for it given most other Java web frameworks seem to implicitly choose JSF as their primary competitive target. Spring MVC follows very closely with 34.2%. This in my view is great news as this validates the need to standardize MVC 1.0 as an action-oriented approach to web frameworks. The MVC specification community should take note and pay close attention to the concepts proven out in Spring MVC. In addition the MVC specification has the implicit advantage of not being tied to legacy and starting from a clean slate to adopt what is proven and do better where it makes obvious sense. Other than the two front-runners market share drops pretty sharply for the rest. I should note that the sample size for this survey is extremely strong at 1300+. While no survey is foolproof, this is probably the closest to getting at what is really going on in the Java web framework space. It is also note worthy that JSF has consistently been either number one or number two in such surveys in the past few years. OmniFaces lead Arjan Tijms pointed this out in a characteristically well written analysis on the JAX-RS expert group some months ago. I highly recommend the post for folks interested in JSF or Java web frameworks in general. I know a segment of folks will have a tendency to dismiss the server-side Java web framework space with the hype around HTML 5/JavaScript rich clients like AngularJS. Fortunately DZone/JavaLobby ran an even broader reaching survey on the Java ecosystem. That survey measured server-side Java web frameworks against JavaScript client-side frameworks. The results were not made public yet but should be available soon. I don't consider myself a betting man but based on what I have observed during my popular talk on the topic of HTML5/JavaScript clients and Java EE 7 I have a few reasonably good guesses. Given the current hype I have no doubt JavaScript clients will make a strong showing. Indeed I would not be too surprised to also see that AngularJS already dominates the JavaScript client side framework space. However I think both the relative market share for JSF and Spring MVC will remain largely unchanged even in that survey. What's more likely is that the Java web frameworks that are already in a niche would join the marginal ranks of AngularJS's weaker JavaScript framework competitors. We will find out if I am right as soon as the results of the broader survey are published...

In the past ten years or so few topics have caused as much impassioned debate as the question of what Java web framework to use. It's not too surprising then that JavaLobby/DZone recently ran a survey...

JavaOne

Bessem Hmidi on AngularBeans at JavaOne 2015

For the Java EE track at JavaOne 2015 we are highlighting some key sessions and speakers to better inform you of what you can expect, right up until the start of the conference. To this end we recently interviewed Bessem Hmidi. Bessem is the JUG leader of the ESPRIT JUG Tunisia, an educator, a researcher, an international speaker and a Java EE enthusiast. He spoke to us about his accepted session at JavaOne 2015 on AngularBeans. AngularBeans is a very innovative open source project that marries AngularJS with CDI and Java EE (click here if you can't see the embedded video). We've highlighted AngularBeans on this humble blog in the past. You can find details on Bessem's session on the JavaOne 2015 content catalog. The following are the other sessions we talked about: Introduction to MVC 1.0: This talk is about the new action-oriented web framework being standardized as part of Java EE 8. Besides this technical session there is also a BoF scheduled for MVC 1.0. Finally, the Java EE Security API: This is a session on the newly minted Java EE Security API. It's a very important part of Java EE 8 and a very important API to get right as it's primary goal is improving simplicity and portability for the platform. The specification lead Alex Kosowski and Ivar Grimstad are also hosting a BoF on the topic. HTTP 2.0: What Do I Need to Know?: This session details the groundbreaking changes to the veteran HTTP protocol. This is perhaps a must have for anyone on the Java EE track. As a follow on to this, Ed Burns will explain what all of this means for Serlet 4 and Java EE 8 in his session titled Servlet 4.0: HTTP/2 and Reactive Programming in Java EE 8. Down-to-Earth Microservices with Java EE: This is a session from myself and Steve Millidge about developing practical microservices in blue-collar enterprises using vanilla Java EE. There are understandably quite a few talks on Java EE and microservices at JavaOne 2015. A couple of other very interesting ones are From Macro to Micro(Services) and Back: Onstage Hacking with Java EE 7 by Adam Bien and Java EE 7 Applications as a Microservice with WildFly Swarm by Ken Finnigan of Red Hat. Besides these sessions, we have a very strong program for the Java EE track and JavaOne overall - just explore the content catalog. If you can't make it, you can be assured that we will make key content available after the conference just as we have always done.

For the Java EE track at JavaOne 2015 we are highlighting some key sessions and speakers to better inform you of what you can expect, right up until the start of the conference. To this end we recently...

JCP

JSON-P 1.1/Java EE 8 Webinar at Istanbul JUG

The Istanbul JUG has been spinning up it's participation in Java EE 8 through Adopt-a-JSR. They have already taken an interest in JSON-P 1.1, MVC and JMS 2.1 with many more Java EE 8 JSRs on their radar. The Istanbul JUG is the first Turkish JUG to engage with Adopt-a-JSR and Java EE 8. Towards this end the JUG is hosting an online webinar on the proposed changes in JSON-P 1.1 to better involve JUG members. These changes include support for JSON Pointer, JSON Patch and JSON Patch-Merge as well as Java SE 8 alignment. They will be using the recently released specification early draft to drive the discussion. The meeting will be hosted online so anyone can participate. The event will be held on September 3rd, 9:00 PM Istanbul time. Details of the meeting can be found here. The linked page also includes a registration form for the webinar. Note the meeting will be in Turkish. The Adopt-a-JSR program is one the key things we are trying hard to do differently for Java EE 8 with the goal making this version of the platform one of the most community driven technologies ever developed. Here are just some of the things you could help do via the program right now: Raise awareness on Java EE 8 or Adopt-a-JSR by doing a talk or writing a blog entry. Read and provide feedback on the MVC specification early draft. Try out the MVC specification reference implementation early builds. Help contribute to the MVC specification reference implementation. Join the MVC specification mailing lists. Try out the JSF specification reference implementation early builds. Help contribute to the JSF specification reference implementation. Join the JSF specification mailing lists and discuss the contents of the upcoming early draft. Join the security specification mailing lists. Join the CDI specification mailing lists. Read the CDI 2 specification early draft and provide your feedback. Read and provide feedback on the plan to improving asynchronous JMS message listeners in Java EE. Join the JMS specification mailing lists. Join the JSON-P specification mailing lists. Read the JSON-P 1.1 specification early draft and provide your feedback. Join the Servlet 4 specification mailing lists and discuss the contents of the upcoming early draft. Join the JSON-B specification mailing lists and discuss the early draft. The full details for Adopt-a-JSR/Java EE 8 is always available here. Remember that if you have any questions on any of this, you are always welcome to drop me a note.

The Istanbul JUG has been spinning up it's participation in Java EE 8 through Adopt-a-JSR. They have already taken an interest in JSON-P 1.1, MVC and JMS 2.1 with many more Java EE 8 JSRs on...

JavaEE

Java API for JSON Binding (JSON-B) 1.0 Early Draft Now Available!

The first early draft of the Java API for JSON Binding (JSON-B) 1.0 is now available for you to review: https://jcp.org/aboutJava/communityprocess/edr/jsr367/index.html. As discussed below this is distinct from the Java API for JSON Processing (JSON-P) 1.1, which also recently published it's own first early draft. Like all early drafts for JSRs, the goal is to foster dialog, feedback and participation. Although it is just an early draft the thirty-five page specification document is actually fairly far along so providing useful feedback should be easy. JSON is increasingly becoming the de-facto data interchange format on the web, be it for mobile, HTML5/JavaScript rich-client or microservices applications. While Jersey, EclipseLink, GlassFish and WebLogic have long provided strong support for JSON via EclipeLink MOXy, it has been a goal in the Java EE platform to make JSON a first class citizen to the degree where it can become just another natural serialization format for Java. Towards that goal Java EE 7 provided simple JSON processing support via JSON-P. That support is being beefed up further in Java EE 8 by supporting more JSON standards in JSON-P such as JSON Pointer, JSON-Patch and the like. As a parallel effort Java EE 8 also plans to provide a much higher level JSON binding API via JSON-B. The idea is to make JSON handling in the platform so ubiquitous and easy-to-use that it is almost invisible akin to JAXB in the XML world. If these are ideas that interest you, now is the time to get involved with JSON-B and join other folks in the community that are already helping out. The JSON-B early draft gives special thanks to Olena Syrota, Oleg Tsal-Tsalko and the Ukraine JUG for their contributions even at this stage. These folks have helped us with feedback, community building as well as evangelizing. There are many ways for you to get involved as always. You are always welcome to join the expert group proper via the JCP page for the specification. You can always simply join the discussion by subscribing to the JSON-B specification user alias. If you would rather participate as a group through your JUG you can do that easily via Adopt-a-JSR.

The first early draft of the Java API for JSON Binding (JSON-B) 1.0 is now available for you to review: https://jcp.org/aboutJava/communityprocess/edr/jsr367/index.html. As discussed below this is...

JCP

A new CDI scope in Java EE 8 ?

At this stage, it is probably safe to say that a new CDI scope will be introduced in Java EE 8 as the MVC Expert Group (JSR 371) is in the process of introducing a new CDI custom scope (@RedirectScoped) to support redirect.  The idea is simple; an MCV controller can decide to redirect a client to a specific URL, to a specific controller method. A typical example would be that an anonymous user hits a page that required to be logged; the controller will then redirect the user to a login page. To do this, the controller uses HTTP 302 ('moved temporarily') to invite the client to make a new request to a different URL, to a different controller.  That second request implies a new (and thus different) request-response cycle. And that's the 'raison-d'être' of this new @RedirectScoped scope, i.e. to allow maintaining some state between the 2 request-response cycles of a redirect. Note that this new scope is for the MVC API only. That new scope is sometime referred as the 'Flash scope'. You can see how both redirect and @RedirectScoped works here. The great thing about this new scope is that it is just a new CDI custom scope. This is a great example on how the Java EE Platform leverages its foundation to evolve.  And last but not least, make sure to provide feedback as JSR 371 is in Early Draft period review.

At this stage, it is probably safe to say that a new CDI scope will be introduced in Java EE 8 as the MVC Expert Group (JSR 371) is in the process of introducing a new CDI custom scope (@RedirectScope...

JavaEE

A Journey from Tapestry to JSF 2.2 and JavaEE 7

After the key Java EE 6 release we have seen a steady stream of folks migrating from various non-standard frameworks to Java EE - all for their own good reasons. One such very recent detailed migration story was shared by Lenny Primak. He successfully migrated from Tapestry to Java EE 7/JSF 2.2 and shared his observations in a series of (eighteen!) blog entries. His candid independent insights with regards to JSF/Java EE are likely very helpful to current and potential adopters. I do think it is very important to take any such migration story with a grain of salt. All of this is just one person's view about what is right for them while choosing amongst a complicated set of trade-offs. It is never wise to over-generalize from those unique perspectives instead of choosing what is right for a given situation. We certainly should not forget that all non-trivial technology has it's advantages and drawbacks over time. Tapestry is a great technology in the overall ecosystem that standards like JSF do adopt good ideas from (and the opposite is likely to also be true). It is also possible to use Tapestry with Java EE as an alternative to JSF. You can read Lenny's entire migration story on his personal blog. Although eighteen entries can seem daunting each entry is short/to-the-point and well written. Here are some highlights for the very impatient: In the conclusion Lenny notes "As I looked at the big picture, it turned out to be easier to convert the whole app from T5.3 to JSF and PrimeFaces instead of T5.4, and that’s what I did. This turned out a great decision. Everything is compatible, future JavaEE versions are easily adoptable, all integrations do not require heroic efforts to implement or maintain and even JavaScript and Ajax with JQuery even started to be fun to develop." Lenny opted to use Apache Shiro instead of built-in Java EE application server security such as GlassFish Security or WebLogic Security. He found that Shiro was easy to use with JSF and Java EE - "After the switch to JSF, however, Shiro, with it’s standard configuration, worked as expected, and I was able to build all of the security requirements in the application very quickly." Lenny had some nice things to say about JSF generally and JSF 2.2 in particular - "The JSF way seems to be more flexible and saves code", "writing the same function in JSF and PrimeFaces took only about 10 lines of CoffeeScript code", "...major feature of JSF 2.2 is HTML 5 support, and ability to write JSF applications in standard HTML5 syntax as opposed to JSF tags...this development prompted me to re-evaluate JSF as my tool set". Lenny found contributing to Java EE extremely easy "when trying to contribute to JavaEE, I was welcomed right away. The attitude really shined, and I was able to contribute valuable bug fixes without too much hassle." Lenny found it more sensible to work with standard EJB 3 and JPA features instead of the Tapestry approach to persistence - "I found it better to call EJBs from Tapestry, and let EJBs handle all JPA transactions, thus totally bypassing Tapestry-JPA. This turned out to be the best solution of using JPA with Tapestry." Do you have a similar interesting Java EE adoption story to share with the community? If so, please do reach out and we will find a way to properly highlight it.

After the key Java EE 6 release we have seen a steady stream of folks migrating from various non-standard frameworks to Java EE - all for their own good reasons. One such very recent...

JavaOne

Submit Now to Win a Duke's Choice Award!

The incredible amount of innovation that uses and builds upon standard Java/EE technologies is one the most important factors that keeps our ecosystem so uniquely strong. The annual Duke's Choice Awards is a small way of recognizing and encouraging such innovation. Every year a panel of judges gives out ten of these awards at JavaOne. Submissions for this year is now open and you should check out the details right now. Note that while some of the text uses the word "nomination", it simply means submitting (aka "nominating") your own project or work for consideration by the awards committee. There is no problem with doing this whatsoever and that is in fact what the submission form expects in most cases. That being said there is also no problem whatsoever in submitting on behalf of any project or work you think deserves the award even if you are not directly involved with it. Besides some well-deserved recognition by the Java community, winners get a free JavaOne 2015 conference pass, a super cool Duke award statue and of course the winner's badge. Keep in mind the award isn't just for the framework or product developer types. In the past people using Java in innovative ways for "real world" projects, great educators and thought leaders have won too. Here are some example winners from the past few years for inspiration: Apache TomEE - Innovative fully certified lightweight Java EE application server that is a drop-in replacement to Tomcat. United Nations High Commissioner for Refugees/World Food Program Subsidy Card - A real world Java EE 7 application running on GlassFish that makes a real difference. JCertif - Bringing Java/EE focused IT education to the African continent. JEDI - Bringing Java/EE focused education to the Philippines. DeltaSpike - A very useful CDI toolbox for Java EE developers. Devoxx4Kids - A very cool initiative focused on teaching kid's programming facilitated by one of the largest Java developer conferences. JDuchess - A program to strengthen women in Java. London Java Community - The super active JUG involved in OpenJDK, JCP and Adopt-a-JSR. Parleys.com - The world class e-Learning platform built on Java EE. Arquillian - JUnit for Java EE, need I say more :-)? jHome - An open source home automation platform built on Java EE and GlassFish. You can check out all the past winners here. Do hurry up - the submission deadline is August 24. The submission form is here.

The incredible amount of innovation that uses and builds upon standard Java/EE technologies is one the most important factors that keeps our ecosystem so uniquely strong. The annual Duke's Choice...

JCP

Adopt-a-JSR/Java EE 8 at Istanbul JUG

The Istanbul JUG has been spinning up it's participation in Java EE 8 through Adopt-a-JSR. They have already taken an interest in MVC and JMS 2.1 with many more Java EE 8 JSRs on their radar. The Istanbul JUG is the first Turkish JUG to engage with Adopt-a-JSR and Java EE 8. Towards this end, the JUG is hosting an event on Adopt-a-JSR to better involve JUG members. The intent of the meeting is to introduce the program and how members can participate in various Java EE 8 JSRs. The meeting will be held on August 13th, 7:30 PM at the Koc University Incubation center. Details of the meeting can be found here (the page is in Turkish and geared towards Istanbul residents). The Adopt-a-JSR program is one the key things we are trying hard to do differently for Java EE 8 with the goal making this version of the platform one of the most community driven technologies ever developed. Here are just some of the things you could help do via the program right now: Raise awareness on Java EE 8 or Adopt-a-JSR by doing a talk or writing a blog entry. Read and provide feedback on the MVC specification early draft. Try out the MVC specification reference implementation early builds. Help contribute to the MVC specification reference implementation. Join the MVC specification mailing lists. Try out the JSF specification reference implementation early builds. Help contribute to the JSF specification reference implementation. Join the JSF specification mailing lists and discuss the contents of the upcoming early draft. Join the security specification mailing lists. Join the CDI specification mailing lists. Read the CDI 2 specification early draft and provide your feedback. Read and provide feedback on the plan to improving asynchronous JMS message listeners in Java EE. Join the JMS specification mailing lists. Join the JSON-P specification mailing lists. Read the JSON-P 1.1 specification early draft and provide your feedback. Join the Servlet 4 specification mailing lists and discuss the contents of the upcoming early draft. Join the JSON-B specification mailing lists and discuss the contents of the upcoming early draft. The full details for Adopt-a-JSR/Java EE 8 is always available here. Remember that if you have any questions on any of this, you are always welcome to drop me a note.

The Istanbul JUG has been spinning up it's participation in Java EE 8 through Adopt-a-JSR. They have already taken an interest in MVC and JMS 2.1 with many more Java EE 8 JSRs on their radar....

NetBeans

Maven, Java EE and ... NetBeans

At the beginning, build tools capabilities were relatively simple, i.e. mostly compile and package the compiled sources. But over the years, those capabilities have largely evolved (e.g. complex build processes, dependencies management, documentation generation, testing integration, etc.). And it's probably fair to say that Maven has been, at least in the Java landscape, one of the main actors in that evolution... if not the most important one! Maven is widely used since many years, it's now the de-facto Java build environment. And if you are using another solution (e.g. Graddle), you can't ignore Maven; chances are high that you still have to directly or indirectly use Maven in a way or another (e.g. to integrate a 3rd party framework which uses Maven).  In his "Truly Unleashing the Power of Maven and Java EE" article, Geertjan Wielenga (NetBeans Product Manager) talks about how well integrated Maven is in the NetBeans IDE. If you haven't used NetBeans and its Maven support, you should read this piece. It's amazing how Maven is supported in NetBeans. It's so nicely integrated that you sometime tend to forget that Maven is used under the hood. Geertjan then discusses another strength of NetBeans, its Java EE support. He then concludes with "Maven and Java EE are baked into the very essence of what NetBeans IDE is, as its heartbeat, and as its raison d’être". So when you combine NB's deep Maven integration with its outstanding Java EE support, you get a rock-solid (and free!) environment to develop Java EE applications. Visual representation of a Maven project's depencies in NetBeans

At the beginning, build tools capabilities were relatively simple, i.e. mostly compile and package the compiled sources. But over the years, those capabilities have largely evolved (e.g. complex build...

JCP

Help Recognize Java Community Process (JCP) Heroes!

An open standard like Java/EE involves a lot of hard work from a lot of different groups of people. The hard work of these people, largely selflessly, benefit countless developers. For specification leads the work in the JCP is often far beyond just a job. I have seen the same to be true of many vendor experts on a specification. Especially admirable are the independents that contribute to specifications largely on their own time as well as Adopt-a-JSR participants. The annual Java Community Process awards is a small way of recognizing some of these great people and their work. This year's award nominations are now open - you should read the details here. There are four different awards: JCP member or participant of the year Outstanding specification lead Most significant JSR Outstanding Adopt-a-JSR participant The awards will be presented at JavaOne 2015. These are the nominations I have personally made already: Josh Juneau (for outstanding Adopt-a-JSR participant) Arjan Tijms (for JCP member of the year) Adam Bien (for JCP member of the year) David Blevins (for JCP member of the year)Ivar Grimstad (for JCP member of the year) Antoine Sabot-Durand (for outstanding specification lead) Manfred Riem and Santiago Pericas-Geertsen jointly (for outstanding specification lead) CDI 2 (for most significant JSR) MVC 1.0 (for most significant JSR) Are there others that deserve nomination this year? If so, please don't hesitate to submit the nomination yourself using the very straightforward form. The form is only open until August 17th, so please do hurry!

An open standard like Java/EE involves a lot of hard work from a lot of different groups of people. The hard work of these people, largely selflessly, benefit countless developers. For...

JavaOne

Ivar Grimstad's Java EE Sessions at JavaOne 2015

For the Java EE track at JavaOne 2015 we are highlighting some key sessions and speakers to better inform you of what you can expect, right up until the start of the conference. To this end we recently interviewed Ivar Grimstad. Ivar is a Java EE advocate, speaker, blogger and open source hacker. He is a part of the Java EE 8 MVC and Security JSRs. We wanted to talk to him about his two accepted sessions at JavaOne 2015, his expectations for JavaOne and his experiences in the JCP (click here if you can't see the embedded video): The following are the sessions we talked about: Meet Snoop, a Discovery Service for Java EE: In this session Ivar will introduce his very interesting new open source project named Snoop. Similar to Netflix Eureka, Snoop enables discovery and registration of Java EE based microservices. There are understandably quite a few talks on Java EE and microservices at JavaOne 2015. A couple of other very interesting ones are From Macro to Micro(Services) and Back: Onstage Hacking with Java EE 7 by Adam Bien and Java EE 7 Applications as a Microservice with WildFly Swarm by Ken Finnigan of Red Hat. How Would You Improve the Java EE Security API?: This is an informal after-hours BoF on the newly minted Java EE Security API. As Ivar mentions in the interview it's an important part of Java EE 8 and a very important API to get right as it's primary goal is improving simplicity and portability for the platform. Ivar is hosting the BoF in addition to specification lead Alex Kosowski. Prior to the BoF, Alex will be presenting a conference session on the Java EE 8 Security API titled Finally, the Java EE Security API. Besides Ivar's sessions, we have a very strong program for the Java EE track and JavaOne overall - just explore the content catalog. If you can't make it, you can be assured that we will make key content available after the conference just as we have always done.

For the Java EE track at JavaOne 2015 we are highlighting some key sessions and speakers to better inform you of what you can expect, right up until the start of the conference. To this end we recently...

JavaEE

WebSphere Liberty Now Java EE 7 Compatible!

With the greatest pleasure I can report that IBM WebSphere Liberty 8.5 has recently been Java EE 7 certified! WebSphere joins the ranks of GlassFish 4, WildFly 8, Hitachi Cosminexus and TmaxSoft JEUS. With the very broad customer base that both IBM and WebSphere have globally this is very welcome news for Java EE 7 indeed. IBM has long been a very strong JCP supporter. They led the very well received Java Batch API included in Java EE 7 - bringing to bear their decades of deep expertise in mission critical batch processing. All of the Java EE certified offerings are always listed on the official Java EE compatibility page. WebSphere Liberty is a modern, fast, lightweight and highly modular Java EE implementation. In fact using it's modular architecture WebSphere Liberty has been releasing parts of Java EE 7 into their fully supported service stream for a few months now (note that we've essentially done the same with WebLogic 12.1.3 during JavaOne 2014). Holly Cummins explains well the evolution of WebSphere Liberty and why it's a game changer especially for IBM customers. Liberty's approach to modularity makes it possible to upgrade to Java EE 7 incrementally without a reinstall and even continue running existing applications against a Java EE 6 runtime baseline. The Java EE 7 certification announcement from Laura Cowen can be found here and you can download WebSphere Liberty here. As many of you know full Java EE 7 compatibility is one of the most significant goals of the upcoming WebLogic 12.2.1 release. The Apache TomEE team is also working on bringing forward Java EE 7 features. Judging by past history of release cycles for JBoss AS and JBoss EAP it's reasonable to think JBoss EAP will likely be Java EE 7 certified within this year (for those unaware WildFly is the upstream project for JBoss EAP much like JBoss AS once was). By the end of this year Java EE 7 users should have well over a half-a-dozen fully compatible platforms to choose from. So the question now is who will be next to cross the Java EE 7 compatibility finish line - only to start working on their Java EE 8 implementation :-).

With the greatest pleasure I can report that IBM WebSphere Liberty 8.5 has recently been Java EE 7 certified! WebSphere joins the ranks of GlassFish 4, WildFly 8, Hitachi Cosminexus and TmaxSoft JEUS....

JavaEE

Using HTML 5 with JSF 2.2/Java EE 7

Though some people seem to continue to pit JSF against HTML 5, there is little practical reason this needs to be the case. In fact JSF 2.2 specifically and Java EE 7 generally has gone to great lengths to support the fellow HTML 5 body of standards. It has always been fully possible to use native HTML in JSF pages. There is little reason you would have any practical difficulty in using most key HTML 5 features even with JSF 2.1/Java EE 6 including canvas, web workers, audio, video and local storage. The only clear place where JSF and HTML 5 can collide is while mixing and matching JSF features with newer input/data elements and attributes such as calendar, email, pattern, autofocus and placeholder. The JSF 2.2 expert group created a very novel and easy solution to this problem through pass-through elements and attributes. Using this feature you can start with an HTML 5 native element and add JSF features to it or start with a JSF element and add HTML 5 features to it seamlessly and effortlessly. By far the best write-up on this capability comes from Chicago based Java EE community advocate Josh Juneau. You should take time to read his very well written article published on OTN as well as the Java Magazine. Washington DC based Java EE community advocate David Heffelfinger will tackle the topic of pushing HTML 5 usage to the max with JSF 2.2/Java EE 7 in his accepted JavaOne 2015 session titled Integrating JavaServer Faces and HTML5. If you can't come to JavaOne 2015 to see him in person we will share the session video with you on this humble blog when it becomes available.

Though some people seem to continue to pit JSF against HTML 5, there is little practical reason this needs to be the case. In fact JSF 2.2 specifically and Java EE 7 generally has gone to...

JavaEE

Java EE 7 in Production at safsms.com

One of the most important things to do at this stage of the life-cycle of Java EE is highlight successful adoption stories at a regular cadence. We have been doing just that for a long time through our adoption stories blog, this humble blog as well as JavaOne. In the past few months celebrated Java EE advocate and Java Champion Adam Bien has been really helping out in this regard as well through his popular blog. One of the interesting adoption cases Adam highlighted is production Java EE 7 usage at safsms.com. SAFSMS stands for SAF School Management Software. It comes out of Nigeria's vibrant startup ecosystem and is a web-based application for managing school processes and student records. Currently over 200 schools are using SAFSMS. It is completely based on Java EE on the server side. SAFSMS is soon going to be offered as Software as a Service (SaaS) likely via Amazon EC2. Faiz Bashir, the key engineer behind SAFSMS, noted the simplicity, ease-of-use and productivity offered by Java EE 7 that makes it well suited to ambitious startups like his. SAFSMS utilizes GlassFish 4.x, Git, NetBeans, Arquillian and Docker. They are also considering adopting Java SE 8 and Jenkins. Faiz confidently remarked "I will choose Java EE always without any hesitation". You can read the full details of the adoption story on Adam's blog. JavaOne 2015 was particularly good in terms of compelling Java EE adoption story session proposals that we could accept. You should start seeing those sessions show up in the live content catalog. We will of course share those stories here if you cannot come to JavaOne. If you have a similarly great Java EE adoption story to share with the community (particularly migration stories from other technologies), please do feel encouraged to reach out. In the spirit of Java EE centric vendor neutrality, what Java EE implementation or tool set you choose does not matter at all and neither does which part of the globe you are in.

One of the most important things to do at this stage of the life-cycle of Java EE is highlight successful adoption stories at a regular cadence. We have been doing just that for a long time through...

Oracle

Integrated Cloud Applications & Platform Services