Tuesday Mar 17, 2015

Java EE Container Lifecycle

Java EE defines different component/container models with their own well-defined lifecycle.  Understanding the lifecycle of those different component/container might sometime be useful. Having some visibility on component lifecycle is also useful with applications that use different types of components (e.g. Servlet and EJB) and needless to stay that this is the most common uses case. Finally, it is not just about visibility. Having the ability to also trigger certain actions based on the state of a particular component/container is also sometime required (e.g. perform some specific initialisation).

So when it comes to monitoring and managing Java EE applications, Application Servers tends to provide some custom hooks to achieve that, i.e. observe internal state (e.g. state of a particular container) and trigger management actions based on events such as a state change. Obviously, this is Application Server dependent. For example, GlassFish has Life Cycle Modules/Listeners while WebLogic has, amongst different options, WLDF Watches. So overall, this type of capability (and theirs implantations) varies greatly and is Application Server dependent.

But some of the Java EE Java APIs also provide hooks that can be used to determine in which state an actual component/container is. In terms of granularity, this approach might be a bit more limited but it has the advantage of being Application Server agnostic since it is based on standardised APIs. I recently came across 2 articles that are discussing that particular topic:

On a related matter, the discussions over the upcoming 'Java EE Management API 2.0' (JSR 373) will also be interesting to track.

Monday Mar 16, 2015

Migrating a JSF Application from Spring to Java EE 7/CDI

One of the most important things to do at this stage of the life-cycle of Java EE is highlight successful adoption stories. We have been doing just that for a long time through our adoption stories blog as well as JavaOne. JavaOne 2014 was particularly good in this regard and JavaOne 2015 looks to be even better. Indeed we hope the folks with great adoption stories that submitted last year but did not get accepted will resubmit next year. We will continue to highlight some of those sessions from JavaOne 2014 in the next few months. In this vein I'd like to highlight a very interesting real world story of migrating a JSF based web application from Spring to Java EE 7 and CDI shared by Mario-Leander Reimer of QAware.

Mario's division is a small German based project consulting practice. He was tasked by a major German auto manufacturer to undertake this migration effort (it won't take most Germans much effort to figure out who this auto manufacturer might be since Mario shares that they are based in Munich). The reasons cited for the migration include streamlining/simplifying company-wide application architecture, reducing framework explosion/dependencies, standardization and reducing cost. In just about a month Mario was able to successfully migrate over the application that made extensive long-term use of Spring to CDI and Java EE 7! Mario also made use of great CDI ecosystem tools such as DeltaSpike and Arquillian (both projects have been Duke's Choice award winners, DeltaSpike being the more recent recipient). He also used PrimeFaces with JSF.

During his talk Mario highlighted his journey in learning CDI/Java EE 7 (he was previously a heavy Spring user), the parts of CDI and Java EE he really came to appreciate as well as the challenges he faced and successfully overcame. His talk highlights the ever careful balance struck between feature bloat and simplicity in a Java EE standard like CDI as well as the power of the CDI portable extensions API when you really need to break out of what CDI provides out-of-the-box. You can see Mario's awesome JavaOne 2014 presentation below (if you are having trouble seeing the embedded video it is available here).

If you have a similarly great Java EE adoption story to share, please do drop us a note (particularly migration stories from other technologies). 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.

Friday Mar 13, 2015

Java EE 7 Hands-on-Lab Updated for You to Use!

The official Java EE 7 Hands-on-Lab is an excellent learning resource. It was initiated by my former colleague Arun Gupta (now at Red Hat). The lab starts with some skeleton code (that's mostly Java EE 5 and Java EE 6) and through a series of well-written step-by-step instructions adds a select set of Java EE 7 features to create a fairly cohesive sample web application. The instructions do a reasonable job of explaining the context and motivation for the features being added. Although it touches upon a tiny subset of what was added in Java EE 7, in my experience the lab takes about six to eight hours to complete. In the end attendees get a real sense of how developing with Java EE and Java EE 7 actually feels like and learn a few Java EE 7 features.

I just finished successfully delivering the lab once again at DevNexus 2015 (trip report coming soon). In preparation for DevNexus and beyond I made a few updates/changes:

  • I tried to make the lab entirely self-directed and self-paced for attendees by removing as many possible stumbling blocks (however minor) as possible. My goal was to make the lab as easy to go through and as standalone as possible.
  • I updated the lab to use GlassFish 4.1 and NetBeans 8.0.2. This resulted in a small number of minor code changes.
  • I polished up the code to make it as realistic as possible within the scope of a simple lab.

The first bullet point above is what I would really like to bring your attention to. Every time I have run this lab I've tried to execute it such that it requires bare minimum or no involvement from me and in fact I believe I've succeeded in doing just that. The reason this really matters is that I think this lab material has much greater potential than just something else our team does at conferences. I believe that the lab is now in a state such that anyone can go through the lab entirely on their own, by just using the public HOL page linked. More importantly I think it is possible with very little effort for someone to lead the lab in their user group or company. I highly encourage you to do so if you have an interest in supporting the Java EE community. If needed, our team could provide any help that you may need (such as being present virtually or working with you one-on-one to get you prepared). I've supplied all the resources that you should need on the public HOL page.

Do drop me a note if you have any feedback on this, if there's anything that I can improve with the lab or if you need any help.

Thursday Mar 12, 2015

Templating in the MVC JSR

One of the underlying requirements of the JSR 371 was to not re-invent any VDL (View Declaration/Definition Language) because the Java EE Platform already provides that capability in 2 different forms, i.e. JSP and Facelets. In addition, the templating solution space is already very mature (and very crowded too!), it would be a complete waste to re-invent anything around that!

So instead of spending energy in re-inventing the (template) wheel, it makes more sense to spend energy in allowing to cleaning use, from the MVC API, the existing templating solutions provided by the platform: JSP & Facelets (see the javax.mvc.engine.ViewEngine interface). 

One additional benefit of that approach is that the MVC API is not limited to just JSP and Facelets. It will also be possible to cherry pick and easily plug-in your preferred templating solution to any MVC JSR implementation.

Next to JSP and Facelets, Ozark (JSR 371 Reference Implementation) already support some additional templating solutions: FreeMarkerVelocityMustacheHandlebars and soon Thymeleaf. Some of those were contributed by Rodrigo Turini and Rahman Usta.

Do you see any templating solution missing?

If so, it's probably just one contribution away!

Disclamier: it's early days, expect things to evolve!

Tuesday Mar 10, 2015

Java EE Security API (JSR 375) Update

It took a bit longer than expected but the JSR 375 Expert Group is now formed! The EG is led by Alex Kosowski (Oracle) and is composed of the following members (companies representatives and individuals) : 

Adam Bien David Blevins (Tomitribe)
Rudy De Busscher Ivar Grimstad
Les Hazlewood (Stormpath, Inc.) Will Hopkins (Oracle)
Werner Keil Matt Konda (Jemurai)
Darran Lofthouse (RedHat) Jean-Louis Monteiro (Tomitribe)
Pedro Igor Silva (RedHat) Arjan Tijms (ZEEF) 

At that at this stage, IBM’s participation is not yet confirmed but this should be, hopefully, resolved quickly.

Now that the EG is formed, the technical discussions can take place. So make sure to watch the discussions as they happen over the JSR 375 user mailing list. The JSR 375 Issue Tracker is also a good resource to keep track of.

It is also worth to mention that this topic will be discussed during the upcoming weeks in 2 conferences. David Blevins and Jean-Louis Monteiro, both from Tomitribe and both EG members will present “Java EE Security: Let's Make Something Useful” during JavaLand (Germany).  In addition, Alex Kosowski (JSR 375 Spec Lead) will give, at Devoxx France, a session on JSR 375. So if you happen to attend one of those conferences, make sure to add those sessions to your schedule. 

Thursday Mar 05, 2015

JavaOne Replay: 'JSF 2.2'

Kito D. Mann is a well-known and active member in the JSF sphere. He is the editor-in-chief of JSF Central and co-host of the Enterprise Java Newscast. A few years ago, he has written the 'JavaServer Faces in Action' book for Manning. And now in addition to his day job as an enterprise application architecture consultant, Kito is also a member of several JCP Expert Groups (including JSF), a recognized conference speaker, etc. Needless to say that Kito lives and breathes JavaServer Faces!

During last JavaOne, Kito hosted several sessions including 2 sessions on JSF 2.2:  'JSF 2.2 In Action' and 'JSF 2.2 Deep Dive'. Both sessions cover the new features of JSF 2.2 (e.g. Faces Flow, Multi Templating, HTML 5 support, XSRF, etc.) but in a different format. The first session ('JSF 2.2 In Action') is a regular session, i.e. 60min, while the second session ('JSF 2.2 Deep Dive') is longer, almost 2.5 hours! This gave Kito more time to go deeper and in more details on JSF 2.2. So if you know JavaServer Faces but want to dig more about what JSF 2.2 brings, you should definitely watch one of those sessions, they’re both very informative and well illustrated with code and demos.



Wednesday Mar 04, 2015

MVC JSR SNAPSHOT builds

The MVC JSR (JSR 371) is progressing nicely. A key architectural decision was taken a few weeks ago: the MVC JSR will be based on JAX-RS. And since then, the Experts Group has started to publish SNAPSHOT builds :

If you want to lean more about the MVC JSR, make sure to bookmark this page where Manfred Riem (MVC co-spec lead) is tracking all relevant MVC information and resources.

It's still early but you now have everything on hand to start initial testing of this new API. As always, community feedback is a critical factor for the long-term success of this JSR!

Tuesday Mar 03, 2015

JavaOne Latin America CFP extended to March 9th

By popular demand, the JavaOne Latin America Call For Papers deadline has been extended by a week. So if you haven't done so yet, make sure to submit your proposal(s) before March 9th (EOB)!

JavaOne Latin America will take place on June 23–25 in São Paulo - Brazil. Registration will open soon. For more information, check this site regularly.

Monday Mar 02, 2015

Java EE 8/Adopt-a-JSR Updates: Chicago JUG and JSF 2.3

It is truly heartwarming to see Adopt-a-JSR moving forward! Although it is still the early days a number of JUGs worldwide have already adopted Java EE 8 JSRs. One of the most active of these groups in the Chicago JUG. The JUG is hosting periodic meetups to work on contributing towards various Java EE 8 JSRs. Their first meetup in this vein was focused JSF 2.3. The meetup had two tracks - one for beginners and one for advanced users. Both were well received.

Bob Paulin, Chicago JUG President, led the beginners track through a tutorial that focused on building a simple JSF application using NetBeans 8, JSF 2, EJB 3, JPA 2 and the rest of the Java EE stack. The advanced track was led by key Java EE advocate Josh Juneau. Led by Josh, attendees checked out, setup (in an IDE), built and debugged the latest JSF 2.3/Mojarra code. Josh blogged the details on the meetup, including some great resources.

We can expect to see great things from the Chicago JUG on Adopt-a-JSR and Java EE 8! One of the earliest Adopt-a-JSR groups, the Morocco JUG also had a similar meetup recently that we will highlight next very soon.

Is your JUG adopting a Java EE 8 JSR yet :-)?

Thursday Feb 26, 2015

Jersey, from Android to Mainframe

As usual, the Jersey Team is busy cranking out new releases. In February, the team has released Jersey 2.16 (release notes, change log) and Jersey 1.19 (blogchange log).

Jersey has a large, active and involved community. For example, there was a bug in Jersey when used on z/OS (who doesn't use Jersey on z/OS?). A community member raised this particular issue along with a suggested fix, fix which has been integrated in 2.16.

Jersey 2.16 is also solving some of the issues related to running the Jersey client stack on Android. Supporting Android is more a side project and Jersey 2.16 clearly shows some initial success. But more work needs to be done. The Jersey Team is looking for concrete feedback on real uses-cases and why not, community contributions too.

So with 2.16, you can finally run a Jersey client on an Android phone connecting to a Jersey server running on Z/OS! Yeah!

And it's not because the Jersey community is already large and active that you cannot participate, contributions are always welcome! See here on the different ways to contribute to Jersey.

Wednesday Feb 25, 2015

Unsynchronized Persistence Contexts in JPA 2.1/Java EE 7

One of the more obscure features introduced in JPA 2.1 and Java EE 7 is the unsynchronized persistence context. It's not too surprising that the community does not seem to discuss it much - it's really geared towards somewhat an edge case.

Prior to JPA 2.1, the entity manager is always synchronized with the database when a JTA transaction commits. This poses a challenge if you have a multi-step workflow (let's say in a stateful session bean/CDI conversation/JSF flow) where you want some data to be flushed to the database on transaction commit at a given stage of the workflow but not all - but you do eventually want to synchronize all changes at some other point in the workflow. Non-standard solutions like Seam and the Hibernate flush mode have been the answer in the past to get around this problem. This is now solved in JPA 2.1 via the unsynchronized persistence context. In an unsynchronized persistence context changes are not automatically flushed to the database on transaction commit. Rather, you explicitly join the transaction when you want changes synchronized.

Hantsy Bai does a decent job explaining this through code examples. By far the best explanation of the feature comes from specification lead Linda DeMichiel. Check out minute 11-14 in the short video below (if you are having trouble accessing the embedded video it is available here).

What do you think of the feature? Do you think it is useful or obscure? The JPA spec is the best place to get further details if this intrigues you.

Tuesday Feb 24, 2015

JavaOne Replay: 'Java EE Game Changers'

David Blevins is a frenetic actor in the overall Java EE Ecosystem. Over the years, he has been involved in various open source Java EE related projects (e.g. OpenEJB). David is now actively working on TomEE which he launched in 2011. So it is fair to say that David knows what implementing Java EE means.

In addition, David is involved in different JCP Expert Groups where he is helping to shape the future versions of Java EE. So David has multiple hats: implementor, contributor and active participant in different EGs.

In this JavaOne session, David is sharing, in a technical (and non traditional) way, his enthusiasm about Java EE and the JCP. In his 'Java EE Game Changers' talk, David looks back at Java EE, he discusses some aspects that have changed the way we program Java EE applications. David also talks about points such as testability in Java EE. Finally, David is also sharing some of the ideas he is pushing forward, through his involvement in the JCP, to improve Java EE (e.g. MDB replacement in JMS 2.1).

This is great session to watch! This talk is also highly recommended to anyone who still has doubts about the Java EE Platform! The only grief one could do about this session is that one hour is too short for such an enthusiast and knowledgable speaker!

Monday Feb 23, 2015

Rakuten: Java EE Adoption in One of the World’s Largest Online Financial Systems

One of the most important things to do at this stage of the life-cycle of Java EE is highlight successful adoption stories. We have been doing just that for a long time through our adoption stories blog as well as JavaOne. JavaOne 2014 was particularly good in this regard and JavaOne 2015 looks to be even better. Indeed we hope the folks with great adoption stories that submitted last year but did not get accepted will resubmit next year. We will highlight some of those sessions from JavaOne 2014 in the next few months and the best place to start is the Java EE adoption story from Rakuten.

Rakuten is one of the largest online financial systems in the world. It is the number one e-commerce platform in Japan generating over 51 billion dollars of yearly revenue and growing on a global scale. It is easily one of the most technically adept companies in Japan and perhaps the world. They had a legacy system build around J2EE and a hodgepodge of various non-standard frameworks such as Spring, Apache Axis and iBatis. They chose to adopt Java EE over these technologies including alternatives such as .NET. They cited vendor neutrality, choice, simplicity, community, ease-of-learning, ease-of-use and productivity as great reasons for selecting Java EE for their next generation platform. They fully leverage Java EE including key APIs such as JSF, CDI, EJB, JPA, JTA and JMS. Along with Java EE they also chose WebLogic as well as Oracle DB/Exadata. They cited performance, scalability, reliability, productivity and support for choosing WebLogic, Oracle DB and Exadata. They also use best-of-breed tools such as NetBeans, Maven, Jenkins and the Atlassian suite of solutions. They achieved the astounding technical feat of completely overhauling their 24/7, extremely high volume online transactional system in just six months including training!

You can see Hirofumi Iwasaki and Arshal Ameen's awesome JavaOne 2014 presentation below (if you are having trouble seeing the embedded video it is available here).

The slide deck from the talk is posted below (if you are having trouble seeing the embedded slideshow it is available here).

Hirofumi Iwasaki and Arshal Ameen have been great advocates of Java EE, especially in Japan. We hope to continue to see great things from them and Rakuten. Rakuten is looking forward to learning and applying Java EE 7 in the real world as soon as possible.

If you have a great Java EE adoption story to share, please do drop us a note (particularly migration stories from other technologies). 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.

Friday Feb 20, 2015

Java EE @ CodeMash 2015

CodeMash 2015 took place 6-9 January in Sandusky, Ohio at the exotic Kalahari Waterpark Resort. With another sold-out year, CodeMash is quickly becoming one of the larger developer conferences state-side. It has it's roots in .NET, but is making a concerted effort to better attract a Java audience. Topics covered included .NET, methodology, JavaScript/HTML, mobile, cloud, DevOps, Hadoop, NoSQL, Docker, Java SE and Java EE.

I delived sessions on aligning Java EE 7 with the JavaScript/HTML5 rich client landscape, reactive programming support in Java EE and what's coming in Java EE 8. More details on the sessions and CodeMash, including the slide decks and code, posted on my personal blog.

Thursday Feb 19, 2015

HTTP/2 is done

...well almost! There are still some minor processes to go through before they are published as official RFCs but the IESG has formally approved the HTTP/2 and HPACK specifications! So clearly, it’s safe to say that HTTP/2 is done! And given how vital the HTTP protocol is in today’s world, this is really important news.

The fact that HTTP/2 is binary based (Vs. HTTP 1.x being text based) removes lot of technical barriers that (text-based) HTTP 1.x had and allows the introduction of new capabilities. Those new capabilities (e.g. stream multiplexing over a single TCP connection, stream prioritization, server-push, etc.) are more than welcome as they will reduce the overall Web latency. HTTP/2 will also help to get rid of the various “hacks” (e.g. file concatenation, domain sharding) that were put in place to work-around the HTTP 1.x limitations (e.g. Head-of-Line blocking).

HTTP/2 maintains a high-level compatibility with HTTP 1.x and preserve a lot of its predecessors concepts (e.g. URI, headers, etc.). So from a Java EE developer point of view, the HTTP/2 impact will be relatively minimal and only a few HTTP/2 aspects will be exposed to the developer through the Servlet API (Server-Push & Stream Prioritization). This work is conducted right now in the Servlet 4 (JSR 369) Experts Group (see EG discussions here).

And even if you are not a Web-tier developer, it is important to understand HTTP/2 and what it brings. For that, you are strongly encouraged to watch the session that Ed Burns and Shing wai Chan (Servlet 4 Specification Leads) gave during last JavaOne on HTTP/2 and the Servlet 4 plans (slides here).