Monday Jun 29, 2015

JavaOne 2015 Java EE Track Committee: Johan Vos

This is the third in a series of interviews for you to meet some of the committee members for the JavaOne 2015 Java EE track. The committee plays the most important part in determining the content for JavaOne. These good folks really deserve recognition as most of them devote many hours of their time helping move JavaOne forward, often as volunteers. If JavaOne matters to you, these are folks you should know about.

This interview is with Johan Vos. If you are having trouble seeing the embedded video below it is available here.

Johan is a Java Champion, author, speaker, blogger, member of the BeJUG steering group, member of the Devoxx steering group and a JCP member. He is a fan of Java EE, GlassFish and JavaFX. He founded LodgON, a company offering Java based solutions for social networking software. In the interview he shares his experience and expectations for the Java EE track this year.

On this note, I would like to make sure you know that the JavaOne content catalog is now already live with a few preliminary fairly obvious selections we were able to make. None of the sessions accepted at this stage are from Oracle speakers on our track. The folks that we selected early for acceptance include David Blevins, Jonathan Gallimore, Mohammed Taman, Rafael Benevides and Antoine Sabot-Durand. They will be talking about Java EE Connectors (JCA), Java EE 7 real world adoption, CDI and DeltaSpike. I would encourage you to check out all the early selections in the catalog. We are working to finalize the full catalog shortly.

I hope to see you at JavaOne. Do stay tuned for more interviews with committee members and some key speakers on our track.

Thursday Jun 25, 2015

HTTP/2 and Server Push

HTTP/2, which has been finalized a few weeks ago, is composed of 2 related specifications: RFC 7540 and RFC 7541 (see below). With HTTP/2, the existing HTTP 1.1 semantics are fully preserved as this new version of HTTP aims to be as compatible as possible with current uses of HTTP. The main goal of HTTP/2 is to provide a more efficient use of the network resources and, at the same time, to reduce the overall latency. So the fundamental difference between HTTP/2 and HTTP/1.1 is really at the transport level, i.e. how the bits are exchanged over the network. And that is what HTTP/2's new binary-framed protocol is all about.

HTTP/2 relies on the existing HTTP/1.1 semantics, we keep using the same HTTP verbs (GET, PUT, POST, etc.), the same HTTP status codes and so on. So from a Server-side Java developer perspective nothing should really change. Running an existing application over a HTTP/2 stack should be transparent. We obviously could expect to see improvements at the wire level. That means that most of the HTTP/2 capabilities should not be exposed at the Servlet API level. But there are few exceptions to this rule and Server Push is one the important new HTTP/2 feature that should ideally be made available to the developer.

Server Push is a new HTTP/2 feature that allows a server to proactively 'push' multiple unsolicited resources as a response(s) of a regular client request. And since a server-side application knows what resources are needed to render a particular page, this capability basically let an application to pro-actively push resources needed by a client... before the client even knows that it will need those resources.

The Servlet 4.0 Expert Group now needs to figure out how this Server Push capability should be exposed at the API level. One of the possibilities might be inspired from Greg Wilkins's proposal based on Jetty 9.3's PushBuilder API (see here). Greg is an active Servlet EG member and is the original Jetty developer, he started to develop Jetty 20 years ago using Java 0.9! So happy 20th birthday to Jetty as well!

Useful resources:

Thursday Jun 18, 2015

What's Coming with JSF 2.3?

There seems to be a good deal of excitement in the Java EE community around the new MVC specification. This is certainly great and most understandable. Some (perhaps more established) parts of the Java EE community has in the meanwhile been more quietly contributing to the continuing evolution of JSF 2.3. So what is in JSF 2.3? The real answer is that it depends on what the JSF community needs. There is a small raft of work that's on the table now, but I think the JSF community should be very proactive in helping determining what needs to be done to keep the JSF community strong for years to come.

Just as he did for JSF 2.2, Java EE community advocate Arjan Tijms has started maintaining a regularly updated blog entry listing the things the JSF 2.3 expert group is working on. So far he has detailed CDI injection improvements, the newly added post render view event, improved collections support and a few others. You should definitely check it out as a JSF developer and provide your input. Arjan also has an excellent collection of Java EE 8 blog entries generally on zeef.com.

On a related note, JSF specification lead Ed Burns wrote up a very interesting recent blog entry outlining the continuing momentum behind the strong JSF ecosystem. He highlighted a couple of brand new JSF plugins that we will explore in depth in future entries.

Wednesday Jun 17, 2015

TIBCO EMS 8 Supports JMS 2

Many folks don't realize this but there are actually two general forms of JMS providers - providers close to application server platforms that certify against Java EE overall and standalone JMS providers. There are a number of the former that support JMS 2/Java EE 7 already - OpenMQ (the reference implementation aligned with GlassFish) and HornetQ (part of the JBoss/WildFly ecosystem), the JMS provider included with Hitachi Cosminexus and the JMS provider included with TmaxSoft JEUS. In a few weeks WebSphere MQ, aligned with the WebSphere Liberty Profile is set to join these ranks. WebLogic MQ is not too far behind along with WebLogic 12.2.1 with it's support for JMS 2 and Java EE 7.

One of the latter class of JMS providers that somehow escaped my notice is TIBCO EMS. They announced their JMS 2 compliance with TIBCO EMS 8 some time ago.

In case you are unfamiliar with TIBCO EMS they are actually a very significant player in the messaging ecosystem deployed in some very mission critical environments. FioranoMQ announced their support for JMS 2, but I am unable to really confirm this as they have not run the JMS 2 or Java EE 7 compatibility test via the JCP.

Monday Jun 15, 2015

Your Opinion Needed: Asynchronous Message Listeners (MDB) in JMS 2.1

One of the highest priority items left over from JMS 2/Java EE 7 is revisiting the programming model for declarative message listeners for JMS. MDB has been the only way to do this in Java EE for a long time. MDBs definitely have a few things going for them: their syntax is very simple, they are very type-safe yet they provide quite a bit of power behind the scenes for listening to JMS messages in a very safe, reliable and scalable way.

MDBs do however have a couple of weaknesses. One is that they have a very generic JCA based syntax today that is more verbose than they can be. Creating a more JMS-specific syntax also opens up the possibility of a few usability improvements. The other is that an arbitrary managed bean cannot declaratively consume messages - they must be converted to an MDB via the @MessageDriven annotation. This means that for example a REST or WebSocket endpoint cannot declaratively consume JMS messages. I outlined some of these issues during JMS 2 via this JIRA entry. The JMS 2.1 specification lead Nigel Deakin has recently written up a draft proposal to start tackling some of these possible improvements. The proposal is very detailed and easy to understand for all but the most inexperienced Java EE developers. Nigel is actively looking for your feedback right now. Providing feedback is extremely easy to do and Nigel has done a great job outlining how you can get involved in JMS 2.1.

Nigel has decided to start this work by still focusing on improving MDBs. His plan is to make some early progress and then tackling opening this functionality up to other beans such as CDI. Is this a sound approach or should we be focusing on CDI right now as well? Is simply improving MDB all that is needed? What do you think of the syntax? More recently I've also proposed carrying the new syntax further to create handy abstractions for common message processing patterns. What do you think of this idea? Do you have ideas of your own?

Now is your opportunity to chime in and help design a sound API we can all use. If you are an active JUG member or already part of Adopt-a-JSR you can even participate as a group and provide your input though your JUG.

Friday Jun 12, 2015

Java EE @ DevNexus 2015

DevNexus 2015 was held in historic Atlanta on March 10-12. For those of you not familiar with it, DevNexus is the most significant Java centric conference in the South Eastern US and now perhaps even at a national level. It was started by JBoss Java Champion Burr Sutter and organized by the Atlanta JUG (currently lead by Vincent Mayers, Gunnar Hillert, Pratik Patel, et al). As usual DevNexus attracted a bevy of world class speakers including Stephen Chin, Jim Weaver, Ed Burns, Venkat Subramaniam, Yakov Fain, Kito Mann, Markus Eisele, Raju Gandhi, Freddy Guime, Max Katz, Jason Porter and so on. Topics included Java SE, NoSQL, mobile, cloud, Docker, HTML5/JavaScript and of course Java EE. Indeed I think this year Java EE made a very strong showing at DevNexus.

I ran the Java EE 7 HOL as a whole day workshop as well as delivering sessions on Java EE 8, JMS 2 and Java EE alignment with reactive programming. Ed Burns delivered a very good talk on HTTP 2 and Servlet 4 while Jason Porter delivered a JPA talk. More details on the sessions and DevNexus 2015, including slide decks and code, posted on my personal blog.

Thursday Jun 11, 2015

JSON-P 1.1 (JSR 374) update: JSON Merge Patch

JSON Merge Patch (RFC 7386) is relatvely new standard in the JSON space. It defines a set of modifications that will be used to transform a target resource; those modifcations are themselves defined in a JSON object. JSON Merge Patch is a very simple standard with a few limitations but it seems to be useful enough. So and in addition to JSON Pointer (RFC  6901) and JSON Patch (RFC 6902), the JSR374 Experts Group has recently decided to adding JSON Merge Patch support to the JSON-P 1.1 API might be useful. You can track the initial works around JSON merge Patch here.

As usual, feedback is always welcome. And to easily get started with JSON-P 1.1, you should watch the recording of the Adopt-a-JSR session that was held recently with Kin-man Chung (JSR 374 Spec Lead). It gives all the required technical details but also set some expectations in terms of the type of feedback that the EG is looking for.


Wednesday Jun 10, 2015

Meet the JavaOne Java EE Track Committee: David Heffelfinger

This is the second in a series of interviews for you to meet some of the committee members for the JavaOne 2015 Java EE track. The committee plays the most important part in determining the content for JavaOne. These good folks really deserve recognition as most of them devote many hours of their time helping move JavaOne forward, often as volunteers. If JavaOne matters to you, these are folks you should know about.

This interview is with David Heffelfinger. If you are having trouble seeing the embedded video below it is available here.

David is an independent consultant in the Washington DC metro area. He is a long time Java EE advocate, blogger, prolific author and speaker. We are proud to have him as a brand new addition to the committee this year. In the interview he shares his experience and expectations for the Java EE track this year.

On this note, I would like to make sure you know that the JavaOne content catalog is now already live with a few preliminary fairly obvious selections we were able to make. None of the sessions accepted at this stage are from Oracle speakers on our track. The folks that we selected early for acceptance include David Blevins, Jonathan Gallimore, Mohammed Taman, Rafael Benevides and Antoine Sabot-Durand. They will be talking about Java EE Connectors (JCA), Java EE 7 real world adoption, CDI and DeltaSpike. I would encourage you to check out all the early selections in the catalog. We are working to finalize the full catalog shortly.

I hope to see you at JavaOne. Do stay tuned for more interviews with committee members as well as some key speakers on our track.

Tuesday Jun 09, 2015

JSR 359: SIP Servlet 2.0

The reach of the Java EE Platform is not necessarily limited to 'traditional' Enterprise Applications. A good illustration of that is the SIP Servlet technology, which brings together the SIP programming model and the Java EE platform. SIP (Session Initiation Protocol) is a network signaling protocol, often used in the Telecommunication space, for creating and terminating sessions (e.g. VOIP sessions) with different participant(s).

A SIP Servlet is to SIP what a (traditional) Servlet is to HTTP, a server-side component managed by a container. A component developed using a Java API that interacts with clients by responding to incoming requests and returning corresponding responses. The SIP Servlet API (javax.servlet.sip) builds on the generic servlet API (javax.servlet) in much the same way as the HTTP Servlet API (javax.servlet.http) does. Given that, it is relatively easy to learn how to write SIP-based applications. A Converged Application is a (Telco oriented) application that spans multiple protocols (e.g. SIP, HTTP) and interfaces, such as Web, telephony, and other Java EE interfaces. A SIP container enables the development of applications that use SIP, HTTP Servlet API, and other Java EE APIs and components like JPA, JAX-RS, and messaging.

And like any major Java APIs, the SIP Servlet API is defined through the JCP.  The SIP Servlet specification has recently been updated, see JSR 359 here. To learn more about this, you might want to read the SIP Servlet Tutorial.

Monday Jun 08, 2015

The Ghosts of Java EE 7 in Production: Past, Present and Future

In the past few days I've seen a certain predictable group of folks on the Interwebs feigning concern over the viability of using Java EE 7 in production. I have to be honest in that I think it is fairly obvious these concerns are more -ahem- opportunistic than sincere or well-intentioned. Nevertheless I think this is a great trigger to discuss something valuable to the Java EE community anyway - Java EE 7 production adoption in the near past, present and near future.

Head over to my personal blog to read what I hope is a slightly entertaining toungue-in-cheeck but hopefully useful personal insights on the matter. I've dicussed what makes Java EE 7 important both in terms of challenge and opportunity, summarized what we know of real world Java EE 7 adoption right at this moment as well as what we can share shortly, how you can go about using Java EE 7 now and in the near future as well as a brief shot in the dark as to what wonders the future might bring for us all :-). Enjoy!

Please note that any views expressed here are my own only and certainly does not reflect the position of Oracle as a company

Friday Jun 05, 2015

Java EE 8 Roadmap Update

Java EE 8 was formally launched in September 2014 with the JCP’s unanimous approval of JSR 366 and our announcements at JavaOne.  At JavaOne 2014 we presented a summary of our areas of investigation for Java EE 8 during the Strategy Keynote, followed by numerous in-depth presentations on our intended work by the specification leads.  The goal that we set for ourselves then was to complete this work by JavaOne San Francisco 2016.

Although we all like to do (and hear) big things at JavaOne, the various latencies involved in launching expert groups as well as the other demands on the time of our spec leads has resulted in the date being pushed out a bit. We are strongly committed to transparency in our work on the Java EE Platform.  We are therefore publicly announcing that we are now changing our target time frame for the completion of this work to the first half of 2017.  We will be updating the target dates for the JSRs under the Java EE umbrella to reflect this change.

As a result of this shift, there is now more time and opportunity for YOU to get involved.  For example, the MVC  1.0 JSR has published their Early Draft Review, and the Java EE Security JSR will soon follow. We continue to encourage developers to track JSRs and provide feedback by viewing the individual JSR mailing lists, wikis, and download and try out early Java EE 8 reference implementation builds.  We've already seen a lot of interest not only in Java EE 8 features, but also in participation.  Many JUGs have been involved in adopting Java EE 8 and related JSRs, including the CJUGMorocco JUG, and a host of others.  Companies and individuals can get involved as well. For example, Serli, with a host of expertise in Java development, have contributed Application Versioning to GlassFish in the past, and are now signing up to contribute to the MVC reference implementation.

Start here and help define the future of Java EE! 

Thursday Jun 04, 2015

Devoxx Replay: Java EE Security API (JSR 375)

A few weeks ago, Alex Kosowski (JSR 375 Specification Lead) gave a session at Devoxx Paris on the new Java EE Security API (JSR 375). During that session, Alex gave some background and the motivations that led to the creation of JSR 375. Alex then outlined some of the initial plans of the Expert Groups.

This session is particularly useful to understand what the EG is trying to accomplish, it will also provide sufficient background to start following the JSR 375 EG discussions (see here).

Note: The audio level is low at the beginning of the video but everything is fine around the 2m45 mark. Alex's slides can be found here.

Wednesday Jun 03, 2015

Hitachi Cosminexus Now Java EE 7 Compatible!

With great pleasure I can report that the Hitachi Cosminexus Application Server v10.0 has recently been Java EE 7 certified! Cosminexus joins the ranks of GlassFish 4, WildFly 8 and TmaxSoft JEUS 8. Cosminexus has long been a significant player in the Japanese market backed by our good JCP partners at Hitachi. All of the Java EE certified offerings are always listed on the official Java EE compatibility page.

As many of you know Java EE 7 compatibility is one of the most significant goals of the upcoming WebLogic 12.2.1 release. We also know that the IBM WebSphere Liberty Profile team has been aggressively pursuing full Java EE 7 certification through monthly beta releases and seem close to being done. 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 not unreasonable 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).

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 :-).

Tuesday Jun 02, 2015

Stored Procedure Support in JPA 2.1/Java EE 7

If you want to start a contentious debate at work, you should try initiating a discussion on the pros and cons of database stored procedures. If you want the discussion to be particularly colorful make sure to include a few DBAs or database developers instead of simply Java application developers :-). One of the least contentious benefits of stored procedures is that they can provide a performance boost for cases that involve multiple complex queries and heavy data manipulation by reducing the number of network round trips to the database. Some of the main weak points for stored procedures include lack of portability, weaker tooling for development/testing/debugging, and increased database load. The last one is a particularly salient point in my view - databases are the most difficult part of the data center to scale horizontally and they are already heavily IO bound. Frivolously adding stored procedures to the mix can work to make the database CPU bound to boot.

Where JPA and more generally ORM tools stand on this debate is not a great mystery - prior to JPA 2.1 the specification did not add direct support for stored procedures. That being said it should be noted that major JPA implementations have long supported stored procedures and adding support for them has been a frequent enough request for the JPA specification. The good news is that JPA 2.1 and Java EE 7 adds standardized support for accessing stored procedures. Pau Kiat Wee does a nice job of demonstrating the new feature in a very brief code centric blog post. Note that his example is Java SE based so it's actually even easier in a Java EE 7 environment. The newly added stored procedure support is very similar to the way JPA handles native queries. One of the best explanations of the feature comes from specification lead Linda DeMichiel. Check out minute 4-7 in the short video below (if you are having trouble accessing the embedded video it is available here).

Another very good source for more examples of the new feature is the EcliseLink 2.5 JPA 2.1 notes. Enjoy and don't forget to share if these are useful resources.

Please note that any views expressed here are my own only and certainly does not reflect the position of Oracle as a company

Monday Jun 01, 2015

Java EE @ Voxxed Days Algiers

The inaugural Voxxed Days Algiers was held on May 23 in Algiers, Algeria. Besides the Devoxx and Voxxed brand, the event can be credited by and large to the grassroots efforts of the Algeria JUG as well as the neighboring Morocco JUG. I have to thank Morocco JUG leader Badr El Houari for cordially inviting me to the event and Algeria JUG leader Abderrazak Bouadma for making the trip a unique unforgettable experience. The event was a humble but profound first step in the right direction for Algerian developers. The event definitely had a strong Java EE showing.

I participated in the opening keynote and delivered three sessions on Java EE 8, using NoSQL in Java EE applications and testing Java EE applications with Arquillian. More details on the sessions and Voxxed Days Algiers, including slide decks and code, posted on my personal blog.