Friday Jan 16, 2015

File Uploads Using JSF 2.2 and Java EE 7

File uploads have long been possible in JSF, usually using third party plugins like PrimeFaces or RichFaces. JSF 2.2 finally adds support for file uploads out of the box. The practical reason for this lag is that the JSF specification has always chosen to support a Servlet version one behind the latest. This is what often makes it possible to use newer versions of JSF on older runtimes, particularly on Servlet containers like Tomcat. Consequently JSF 2.2 can depend on Servlet 3.0 which adds support for multi-part file handling - making the new file upload feature possible. In a pretty well written code driven post, Hantsy Bai explains the file upload support in JSF 2.2/Java EE 7. You can also check out Rama Krishnnan's YouTube video below on the file upload feature:

Interestingly Rama uses Tomcat and an older version of NetBeans but is still able to demo the feature well (he also chooses to do manual header parsing himself). Things are obviously a lot easier with a Java EE 7 server like GlassFish, which is what Hantsy Bai uses instead.

Thursday Jan 15, 2015

JavaOne Replay: 'JMS 2.0 Best Practices in 50 Minutes'

'50 xxx Best Practices (or Tricks) in 50 minutes' is a trendy thing in conferences (*). As the title suggest, the idea is simple: cover a lot of technical tips in a given timeframe. This is an interesting format for attendees as if you are new to the presented subject; you will high likely learn a lot of things.  And if you are already familiar with the topic, chances are high that you will also learn a few tricks here and there.  It is however a difficult exercise for the person delivering the session as there is a lot of technical content to deliver in a well-defined (and relatively short) time frame. And if the speaker got distracted by anything (e.g. beamer issue, long question), it will be very difficult to recoup the lost time.

Anyway, Nigel Deakin (JMS Specification Lead) did this challenging exercise during last JavaOne. By having attended Nigel's 'JMS 2.0 Best Practices in 50 Minutes' session, I can say that this was a very good (and technical) session on JMS! The content should be useful for JMS newcomer but also for people with good JMS knowledge. You can watch the replay below and download the slides here.

(*) That also work with '45' and '55' but nobody ever dared to try with '42'! 

Wednesday Jan 14, 2015

Calling All JSON Enthusiasts: Join JSON-P 1.1!

As many of you know the initial wave of Java EE 8 JSRs are now fully launched for a little while now, including the platform JSR itself, CDI 2, JSON-B, JMS 2.1, Servlet 4, JAX-RS 2.1, MVC and JSF 2.3. More recently three other Java EE 8 JSRs have been launched - Java EE Security, Java EE management and JSON-P 1.1 (more specifically the Java API for JSON Processing 1.1, launched as JSR 374). All three are now in the process of forming their initial expert groups. JSON-P 1.1 lead Kin-man Chung is specifically looking out for folks to join his expert group - go to the JSR page linked above to nominate yourself!

Although it's currently slated to be a point release, there is some very interesting work that may happen in JSON-P 1.1. Here is a very high level summary of the items currently under consideration:

  • Adding support for JSON Pointer.
  • Adding support for JSON Patch.
  • For those unaware, JSON Pointer and JSON Patch are both recently finalized IETF specifications. To go along with the JSON Pointer and JSON Patch work JSON-P 1.1 will also add support for editing/transformation operations to the JSON object model API, quite possibly using the builder pattern.
  • You can actually already use Java SE 8 streams and lambdas with JSON-P. JSON-P 1.1 will explore if Java SE 8 support may be improved across the API further.

Kin-man did an excellent job overviewing the possibilities in his JavaOne 2014 talk that you can see for yourself below.

Note that you can always participate in a JSR without officially being part of the expert group by simply subscribing to the JSR user alias. In case of JSON-P that alias is users at json-processing-spec dot java dot net - go to the JSON-P java.net project page to subscribe. Also remember that you can contribute on an even more lightweight format through Adopt-a-JSR.

Tuesday Jan 13, 2015

Reactive Jersey Client

One of the common problems of synchronous applications is that they are not using resources in an efficient manner. In a synchronous application, it often happens, for example, that threads are blocked waiting for something to happen.  That is clearly not efficient!  On the other hand, asynchronous applications allows to better utilize those threads but this often comes at a price as it is not that easy to write (complex) asynchronous applications.  Writing asynchronous applications involve having to deal with nested callbacks, the famous "callback hell".  And if the level of nested callbacks is too deep, it can also be very tricky to properly handle errors within the application, etc.

Reactive programming is a popular paradigm used to develop more easily asynchronous applications; it is based around data flows and changes propagations.  This Reactive approach also leads to be more maintainable too as the code is easier to write and understand.

Michal Gajdos of the Jersey Team has just written a series of posts introducing the 'Reactive Jersey Client API', a new generic API allowing end users to utilize the popular reactive programming model when using Jersey Client. 

Thursday Jan 08, 2015

Initial milestone of JSF 2.3

The JSF Expert Group has started to work actively on the next version of the JSF specification (JSF 2.3 - JSR 372) that is slated for inclusion in Java EE 8.  We are still far from the planned date for the finalisation of the specification but we can already see progress as they are being made.  The initial milestone of Mojarra (JSF Reference Implementation) has just been released (download it here).  The Release Notes describes the bugs fixed but also the new features introduced in this milestone.  And from that list, we can see that a lot of focus is put around improving the JSF/CDI integration.

So despite the fact that we are in the early days of JSF 2.3, it is already possible to test some of the new features.  And since Mojarra is open source, it is also possible to use, at any time, the current Mojarra snapshot.  Josh Juneau who is a JSF 2.3 EG member has written a post explaining how to build Mojarra directly from the sources.  So feel free to give JSF 2.3 a(n early) try and provide feedback, this is important for the evolution of the JSF specification. 

We have the usual fine print to conclude, we are still far from the finalization of JSF 2.3, a lot of things will evolve and this is clearly 'work in progress' but transparency is important!

Tuesday Jan 06, 2015

Interceptors in Java EE

Interceptors are used to implement cross-cutting concerns such as auditing, logging, security related tasks, etc. from the actual business logic.  Interceptors provide a clean separation between those cross-cutting concerns and the rest of the application logic.  Overall, this separation simplify the development and the maintenance of the application.

Interceptors are not new.  In fact, interceptors are nearly a decade old as the initial interceptor support has been introduced in Java EE 5... in the EJB 3.0 specification to be more precise.  But in those nearly 10 years, Interceptors have evolved quite a lot and have now their own specification.  The fact that interceptors are now independent of the EJB specification broadens their scope and reach to the complete Java EE platform.

Abhishek Gupta recently wrote a nice post on Interceptors.  In his article, Abhishek start with the history of Interceptors and then goes on the different type of Interceptors and how to use them. And as usual, you can also check the Java EE Tutorial section on Interceptors and this sample if you want to learn about Interceptors.

Monday Jan 05, 2015

Vasilis Souvatzis's Java EE 7 Thesis Using GlassFish

Hoping all of our readers happiness, health and wealth in this first post of the year! It's an awesome stroke of good luck to be able to start the year off by sharing a pretty cool Java EE 7/GlassFish 4.1 adoption/learning story. Vasilis Souvatzis, a computer science student at the Alexander Technological Educational Institute of Thessaloniki (ATEITHE) in Greece, decided to do his thesis project on Java EE 7. He basically taught himself Java EE 7, Java SE 8, GlassFish, NetBeans and PrimeFaces with little more than what is freely available online. He is now proudly a fan of the technology stack, particularly Java EE 7.

The end result of his project is a pretty sophisticated, non-trivial working code base simulating a web-based tutorial (there aren't too many students that I know of that has those bragging rights :-)). He actually made the project available on GitHub for all to see. He demos the project in the video below he took the time to create:

The GitHub project has instructions on how to setup and explore the project yourself. He would also welcome any contributions if you are so inclined. Enjoy and don't forget to spread the word on Vasilis's hard work useful to the Java EE community if you think it is cool!

Friday Dec 12, 2014

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!

I am very happy to say this has been yet another busy and eventful year for us. We finished the community survey effort to help drive the agenda for Java EE 8 and GlassFish 5; we released GlassFish 4.1 with support for Java EE 7, CDI 1.2, WebSocket 1.1 and Java SE 8; we released WebLogic 12.1.3 with support for WebSocket, JSON-P, JAX-RS 2, JPA 2.1 and Java SE 8; we officially launched the Java EE 8 JSRs; we are now in the process of spinning up Adopt-a-JSR for Java EE 8. 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, we will look forward to working harder than ever in engaging you through our development and evangelism efforts including this humble community blog. We hope the next year will bring a far more concrete vision of Java EE 8, some early work on GlassFish 5 and a fully Java EE 7 capable version of the best-in-class WebLogic commercial offering. We will also continue our work to strengthen the broader Java EE community and align the platform with emergent forces the likes of Java SE 8, HTTP 2, JavaScript/HTML5, Reactive Programming, Microservices, Docker, Big Data and the Cloud.

As you know, I and my colleague David Delabassee are the primary maintainers of this blog with some occasional help from folks like Bruno Borges and John Clingan. Both David and I will be enjoying some well-earned time-off with our families the next few weeks. As a result the guns will be mostly quiet at this particular Java bulwark to return recharged and full force in the new year. Others on our team will continue to work hard behind the scenes towards the goals stated.

Until then, thanks and best wishes once again. We hope to see you next year!

Thursday Dec 11, 2014

Named and Dynamic Binding in JAX-RS 2

Providers, interceptors and filters are excellent mechanisms to bring pluggability and cross-cutting concerns to JAX-RS. By default these artifacts are applied globally to all available JAX-RS resource methods. This is probably fine for the most part but in some cases it's useful to have a bit more control over where filters and interceptors are applied. Fortunately, JAX-RS 2 has two mechanisms to facilitate this - named and dynamic bindings. Named bindings are much like binding CDI interceptors in that it is declarative and static - you get to choose in a loosely coupled, type-safe fashion where you want a binding to occur but you can't change bindings at runtime. Dynamic bindings as the name implies gives you a much greater degree of flexibility. You can choose at runtime in a completely programmatic fashion where bindings should occur. The trade-off is that dynamic bindings are a bit more complex and verbose. Michal Gajdos explains both named and dynamic JAX-RS 2 provider bindings in a fairly brief but excellent blog post.

Towards the bottom of the post, Michal has links to the Jersey docs that is a great resource for understanding the concepts of providers, interceptors and filters in a general sense.

Wednesday Dec 10, 2014

Adopt-a-JSR for Java EE 8 Spinning Up

As some of you may be aware, Adopt-a-JSR was a very innovative JUG-led program that was initiated during the later parts of the Java EE 7 time-frame. The goal of the program is to make it as easy as possible for rank-and-file Java developers to contribute to the JCP through their local Java User Groups. By all accounts the program was successful as to a good number of JUGs adopting Java EE 7 JSRs. However we should aim a lot higher for Java EE 8 and Adopt-a-JSR. There is no reason not to hope that every major JUG worldwide should adopt at least one Java EE 8 JSR. Indeed although it is still very early a number of JUGs have already committed to helping with defining the next major revision of the platform including the London Java Community, Egypt JUG, Morocco JUG, the Japan Java User Group, Java Hellenic User Group and many others.

The Java EE/GlassFish team, JCP folks like Heather VanCura and the JUG community itself is trying to do as much as we all can to ensure the success for Adopt-a-JSR for Java EE 8:

  • We put together a page dedicated to Adopt-a-JSR for Java EE on glassfish.org. This page should be your first stop if contributing to Java EE 8 JSRs via the program interests you. We will make a point to keep the page up-to-date throughout the life-cycle of Java EE 8.
  • Heather, spec lead Ed Burns, JUG leader Mohamed Taman and I presented a talk on Adopt-a-JSR for Java EE at JavaOne 2014. Heather covered the Adopt-a-JSR program at a high level, Ed talked about the program from the perspective of a spec lead while Mohamed covered the adopter perspective. I finished by talking about Adopt-a-JSR in the specific context of Java EE 8. Video of the talk should be available soon and we will highlight it here as soon as we can.
  • Both I and Patrick Curran highlighted the program during our keynotes at JMaghreb and Java2Days (stay tuned for trip reports).
  • Heather has been and will continue to organize meetings (especially with spec leads) to keep promoting Adopt-a-JSR. Most recently Heather hosted an open meeting with Java EE 8 platform spec lead Linda DeMichiel. Heather blogged about the meetings here and posted the slides. The next meeting will be on December 19th at 10 AM Pacific time with Ed Burns and Manfred Riem, so stay tuned (details on how to join the meetings are on Heather's post).
  • Java EE/GlassFish author, speaker and advocate Josh Juneau is leading a meeting on Adopt-a-JSR for his local Chicago JUG in January.

You can help us too by spreading the word on Adopt-a-JSR to your local JUG. If you are interested, never hesitate to reach out as always.

Tuesday Dec 09, 2014

JavaOne 2014: A Small Step in the Right Direction?

JavaOne 2014 San Francisco was held September 28 – October 2. I think this was a particularly good year for JavaOne in many ways and it's certainly been a privilege to try to do justice to the crucial role of Java EE track lead (a role I took on for the first time this year). I'd like to share my thoughts, observations and experiences at JavaOne 2014 from that perspective. We did a few things differently this year that seemed to have paid off fairly well.

Besides helping organize the conference, I pitched in the keynote demo, scouted as many Java EE sessions as I could in my track and led a few sessions. More details on all of this, including thoughts, analysis, slide decks and code, is posted on my personal blog.

Thursday Dec 04, 2014

The Java 7 EE Tutorial - free eBook!

The Java EE 7 Documentation page has been recently refreshed with an improved and cleaner layout.   It should now be easier to locate, browse and read the Java EE API documentation, the Java EE SDK documentation and the Java EE Tutorials.

It is sometime useful to remind about the availability of useful resources such the "Java EE Tutorial"… even more when those resources a free!  The Java EE Tutorial is one of those gems that is sometime overlooked.  It covers Java EE 7 and is an invaluable set of resources for anyone wanting to learn Java EE but also for people already familiar with Java EE as it also covers some of the less known part of the Java EE platform such as JCA.

For new comers, there is "Your First Cup: An Introduction to the Java EE Platform", a crisp introduction to the Java EE platform.

The "Java EE 7 Tutorial" is available for free (online and PDF format).  In addition, the Java EE Tutorial is now also available in ePub and Mobi formats (hint: check the top right corner) so you can download and read it on your preferred eBook reader (tablets, iBook, Kindle, etc.).  Just check the top right corner.  And again, those great resources are free!

Finally if you are more old school, the "Java EE 7 Tutorial" is also available, for a fee, as a dead-tree version.

Tuesday Dec 02, 2014

JMS 2.0 Errata release

There is a clear plan to enhance the JMS specification and that is JMS 2.1 (JSR 368), slated for inclusion in Java EE 8.  The JMS 2.1 Expert Group is still in formation phase and once this is done, the EG will start the actual works on the next revision of JMS.  This work is expected to take time, Q3 2016 is the current ETA for the Java EE 8 final release. 

But let's not forget the current version of JMS, i.e. JMS 2.0 (JSR 343).  An errata is needed to correct a few errors in JMS 2.0 which can't wait for JMS 2.1 because they affect the ability of implementers to correctly implement JMS 2.0 today.  An 'errata' is a simple kind of maintenance release intended purely to correct errors in the specification, so clearly the intention is not define any new features (any new features should be discussed within the JMS 2.1 scope).

For that reason, Nigel Deakin (JMS 2.0 and JMS 2.1 Specification Lead) has proposed and started an errata for JMS 2.0.  An Errata release (and maintenance releases in general) don’t have an Expert Group.  Nevertheless Nigel is soliciting feedback on the various small issues that he plans to have addressed in the JMS 2.0 Errata.  You can check the changes proposed for the JMS 2.0 errata on this Wiki page, the jms-spec users mailing list is a good channel to provide feedback.

Monday Dec 01, 2014

Bulk Update/Delete using the Criteria API in JPA 2.1/Java EE 7

It has long been possible to do bulk updates and deletes using JPQL in JPA. Since JPQL is closely modeled after SQL, it has the key advantages that SQL does - namely that it is a very compact and powerful DSL for relational data manipulation. JPQL is also a natural transition mechanism to JPA for folks that have worked with SQL for a while (such as myself).

The big drawback for JPQL is that it is decoupled from the Java compiler and thus less type-safe/more error-prone. This weakness becomes particularly salient while needing to dynamically construct queries at runtime (with JPQL this basically turns into a lot of hard-to-read string manipulation) or with folks coming from a Java/OO background without much preexisting experience with SQL/RDBMS. For these reasons, the type-safe, Java centric Criteria Query API was added to JPA 2.0/Java EE 6.

In JPA 2.1/Java EE 7 the Criteria API has been moved even closer to JPQL with the addition of bulk update and delete capabilities (the Criteria API in JPA 2.0 supported queries which is by far still the primary use case for the API). Hantsy Bai has a very nice post demonstrating how bulk updates/deletes look like using the JPA 2.1 Criteria API.

For a more basic overview of the Criteria API itself, you should check out the official Java EE 7 tutorial.

Thursday Nov 27, 2014

JSR 375: Java EE Security API

Java EE has been used to develop and run enterprise applications securely since years.  Obviously, Java EE and its containers are just parts of the global security equation. When we zoom at the Java EE layer, we see that some of the security capabilities are backed into the specification while others security features are proprietary and specific to the different Java EE implementations.  Sometime, some of the security capabilities are also external add-on's (e.g. 3rd party libraries).  Security is not a self-contained matter as interactions between different components are often required (e.g. a Java EE Application Server needs to interact with an LDAP server).  Things also change when we go from an on-premises deployment to a cloud based deployment.  Finally, portability is never simple when it comes to security.

Java EE needs to evolve to stay relevant and clearly, if we look at the feedback from the Java EE 8 Community Survey, security is an area that could be improved.  And that is the goal of JSR 375 (Java EE Security API) which has just been submitted to the JCP for review.  JSR 375 is slated for inclusion in Java EE 8, its initial scope is based on the community survey feedback, on issues and RFEs filled against the Java EE specifications, on various exchanges EG members had overtime and also on various informal discussions we had during conferences, etc.

The JSR proposal gives a more detailed overview of what it will try to achieve.  In short, JSR 375’s goal is to simplify, standardize, and modernize the Security API across the platform in different area.

  • User Management: Standardization of a ’user service’ API which would enable an application to perform user management operations (e.g. create a user). The ‘user service’ would rely on a ‘user source’ which would be an abstraction of a physical user store (e.g. LDAP, data-bases, etc.).  The user service would be configurable to match the deployment requirements.
  • Password Aliasing: Standardization of syntax for pointing (alias) to passwords stored in a (secure) password repository.  This password repository might then be bundled with an application (e.g. think cloud deployment).
  • Role Mapping: Definition and standardization of a ‘role service’ API that would enable an application to perform various role mapping operations (e.g. querying a group role).  This would be done via different role mappers (e.g. LDAP, files) that would be adaptable based on the environment’s needs.
  • Authorization: Definition of a new CDI interceptor annotation that would be used to preform application-domain rules at the method level.
  • Authentication: Several enhancements are also planned around authentication (e.g. the ability for a web application to offers different authentication methods).

This is the just of overview of the initial scope. In addition, the Experts Group will also have to look at how some of the Java EE orthogonal technologies (e.g. CDI events, Expression Language, etc.) can be leveraged in order to simplify the use of those new APIs.  To know more about this JSR, make sure to read the JSR 375 proposal. You can also watch the replay of the "Java EE 8 Overview" that Linda DeMichiel gave during JavaOne as she has touched some of those ideas during her talk.

JSR 375 has entered the JCP review period; the next step should then be the approval ballot period. And if it passes this ballot, the Experts Group will be formed and the real works (and discussions) will start!   So we are just at the beginning of this effort but it’s nice to see the different pieces of Java EE 8 being put in place...