Oracle Blog

News from the GlassFish Community

Monday Jun 30, 2014

One of the most satisfying things that I've seen personally over the years is the steady growth of the Java EE community, by and large independent of vendors. Today you have so many key folks in the community like Adam Bien, David Blevins, Antonio Goncalves, Markus Eisele, Peter Pilgrim, Arjan Tijms, David Heffelfinger, Josh Juneau, Bauke Scholtz (aka BalusC) and Werner Keil just for starters that publicly advocate for and strongly support Java EE. This is a far cry from the largely vendor driven affair that was J2EE and frankly virtually unimaginable even in the Java EE 5 time period when I first decided to become active in the community myself as an independent. Java EE is most fortunate that many of these folks contribute directly back to the standard through JCP expert groups.

To this list of prominent names I am very happy to add another - Rudy De Busscher and his newly formed Java EE Squad. Don't let the name fool you - as Rudy explains in the blog entry linked, the squad isn't about contention or an antagonism to anything in particular. In fact that would be against the true spirit of Java EE that is open, inclusive, pluralistic and supportive of an ecosystem that may take any form it wishes while advancing the goals of choice, vendor-neutrality, stability, ease-of-use and compatibility though an open community standard.

The goal of the squad is most benign and community friendly - to educate through presentations, courses, articles and blogs from a small group of contributors. Perhaps it makes sense for you to even explore joining the group and adding to the growing voice of the Java EE community?

As the group marches forward we will highlight them here just as we highlight the many other parts of the community.

Wednesday Jun 25, 2014

The Oracle Technology Network (OTN) is running a new type of event, the Virtual Technology Summit! VTS are online technical events covering a wide set of topics such as Database, Middleware, Systems and, of course, Java. Those topics will be presented by renowned experts from Oracle but also from the community!

The first VTS is taking place is July and will be run 3 times to accomodate different time zones:

Crunching, aggregating, analyzing, transforming: real world data science applications usually perform several processing steps, each step adding more value to your data. Architecting and coordinating these processing pipelines in an efficient way requires a good understanding of the underlying mechanisms of MapReduce algorithms and a few tricks you only learn after you processed several terabytes. This presentation will show how to architect efficient MapReduce pipelines, how to integrate your pipelines with external datasources, like Redis, MongoDB or even relational databases, how to decide the best granularity for a job and when investing in a MapReduce architecture really pays off.

The sea change in HTML5 is likely to shift the pendulum away from today's thin-client based server-side web frameworks like Struts 2 and JSF to JavaScript powered next generation rich clients. With strong support for REST, WebSocket and JSON, Java EE is well positioned to adapt to this change. In this heavily code driven session, we will show you how you can utilize today's most popular JavaScript rich client technologies like AngularJS, Backbone, Knockout and Ember to utilize the core strengths of Java EE using JAX-RS, JSR 356/WebSocket, JSON-P, CDI and Bean Validation. We will also introduce Oracle's own JavaScript rich client solution code named project Avatar.

How to Become an Embedded Developer
by Angelia Caicedo, Java Evangelist and Java Embedded Expert

Jump into the Internet of Things using embedded Java. This session walks you through the steps required to start creating embedded Java applications by showing real examples of how to use GPIO and the I2C devices. See how easy it is to program embedded devices and have some fun!

Don’t miss out on this great opportunity to learn from some of the best minds in the Java community and register!

Tuesday Jun 24, 2014

CDI (Contexts and Dependency Injection for the Java EE Platform - JSR 346) is an important specification of the Java EE Platform but CDI is 'not just about' dependencies injection and contextual lifecycle management! For example, events is one CDI aspect that is sometime overlooked. CDI events provides a simple mechanism that allows beans to produce and consume events in a completely decoupled fashion with zero compile-time dependency between the interacting beans.

Many of you may also be aware of FishCAT. It stands for the GlassFish Community Acceptance Testing program. Through the program community members can help test early builds of GlassFish before the final release. Contributing to GlassFish through the FishCAT program is one of the easiest, most valuable and most effective ways in helping the Java EE and GlassFish communities move forward. We are now launching FishCAT for GlassFish 4.0.1. You can find the details for FishCAT for GlassFish 4.0.1 here.

The voice of the community has always been important to us and we need your help. Please do consider donating some of your time to the FishCAT program.

Thursday Jun 19, 2014

Any application server which conforms to the Java EE Full Profile needs to include a messaging provider which supports the JMS API. Open Message Queue (aka Open MQ), the world first JMS 2.0 compliant MOM (Message Oriented Middleware), is the JMS provider for GlassFish. As GlassFish, Open MQ is open source too. Currently, GlassFish 4.0 is using Open MQ 5.0. In GlassFish 4.0.1, we plan to move to Open MQ 5.0.1. The 5.0.1 release comes with a set of fixed issues (see here) but also introduces new features such as WebSocket and STOMP support.

The JMS specification is a messaging API and as such, it doesn't define the protocol to use on the wire. It is up to the JMS implementer to decide how to handle this. Open MQ supports socket TCP connections, it also supports HTTP/S tunnelling to make JMS messages easily flows through firewalls (See Annex C of the Open Message Queue Administration Guide).

With Open MQ 5.0.1, it is now possible to use WebSocket as the communication protocol between a client and an Open MQ JMS broker. Under the hood, Open MQ uses Grizzly and Tyrus.

A Java client will continue to use the JMS API so this is transparent. The only thing you have to take care is to specify, in your connection factory, the WebSocket URL of the Open MQ JMS Broker (imqAddressList=mqws://<broker-host>:<broker-ws-port>/<ws-service-name>).

In addition, Open MQ 5.0.1 introduces 2 additional types of WebSocket clients, i.e. 'non JMS' clients that can be used to exchange messages with applications that do use JMS :

Those new types of clients are particularly interesting as they open the space for new scenarios (e.g.. simple JavaScript clients). The only thing the client need to have, in order to exchange messages with JMS applications, is STOMP and WebSocket support.

Wednesday Jun 18, 2014

I am very pleased to share with you that the JavaOne Java EE track content is now finalized. In this brief but detail-rich entry on my personal blog, I want to take this opportunity to tell you a little bit about the track, key content and star speakers this year. The collective passion and dedication of all the folks that submitted helped us construct a very strong offering for the community at large. JavaOne is a key part of the global Java community far beyond the walls of Oracle and all of you are a large part of keeping it successful.

I hope to see you all at JavaOne. In the next coming weeks and months we will be sharing more details on the Java EE track, content and speakers at JavaOne. Lastly having been on the other side of the fence I know as much as you might come to JavaOne, it might not be a practical reality for you for a variety of good reasons. I want to remind you that we make a point to make JavaOne content openly available to all. That being said I want to tell you that you should make the pilgrimage to JavaOne at least once as a Java developer.

Tuesday Jun 17, 2014

"The biggest guru-mantra is: never share your secrets with anybody. It will destroy you." (Chanakya)

You have probably already heard of OAuth as it is widely used by many online services providers such as Google, FaceBook, LinkedIn, Yahoo, Twitter, ... to name just a few! OAuth is an authentication protocol that allows users to approve application to act on their behalf without sharing their password.

OAuth support was introduced, several years ago, in Jersey 1.x. 'Recently' ... well more than 6 months ago (*), OAuth support has been added to Jersey 2.x, this post post covers in more details the OAuth support added to Jersey 2.3.

If you are not yet familiar with OAuth, it is probably a good time to start to look at this open protocol. The OAuth chapter of the Jersey documentation should be a good starting point.

(*) It's sometime difficult to keep up with the Jersey release cadence! At the time of writing, the current release is Jersey 2.9!

Monday Jun 16, 2014

As many of you know, JAX-RS 2 is one of the most important parts of Java EE 7. One key enhancement in JAX-RS 2 that doesn't seem to get much attention is it's integration with Bean Validation 1.1 (specifically method validation). The key significance of the enhancement is that it allows for highly declarative data validation for edge client interfaces (in fact the method validation feature introduced in Bean Validation 1.1 is valuable for WebSocket or local/EJB services for this same reason). Bhakti Mehta explains JAX-RS 2 and Bean Validation 1.1 integration well in this blog post. In addition to covering JAX-RS 2, she also discusses how Bean Validation can be used with JAX-RS 1.1. You should also check out the following excellent video by celebrated Java champion Adam Bien showing JAX-RS 2 and Bean Validation 1.1 in action using live coding with NetBeans and GlassFish:

Friday Jun 13, 2014

Those of us that have been around Java/Java EE for a little while sometimes tend to forget that Java is still an ever expanding ecosystem with many newcomers. Fortunately, not everyone misses this perspective, including well-respected Java veteran Yakov Fain. Yakov recently started a free online video tutorial series focused on Java and Java EE for absolute beginners. The first few parts of the series focused on Java SE but now Yakov is beginning to cover the very basics of Java EE. In a recent video he covered:

The basics of the JCP, JSRs and Java EE

How to get started with GlassFish 4

The basics of Servlets

Developing Java EE/Servlets using Eclipse and GlassFish

The excellent video is posted below. The slides for the tutorial series generally are available here. If there are folks you know that would benefit from this content, please do pass on word. Even if you are an experienced developer, it sometimes helps to sit back and review the basics...

It's quite remarkable that someone of Yakov's stature took the time out to create content for absolute beginners. For those unaware, Yakov is one of the earliest Java champions and one would be very hard pressed to match his many contributions to the Java community. The tutorial demonstrates his continued passion, commitment and humility.

As of today, there are already 3 Java EE 7 compatible Application Servers, coming from different 'vendors' (Oracle, TmaxSoft and Red Hat). Two of those Java EE 7 Application Servers are free and open source. We expect the list of Java EE 7 compatible Application Servers to grow over the coming months.

According to a recent independent survey, one third of the Java EE users who participated in that survey is already using Java EE 7. This is a good sign but it also means that a lot of people are not yet on Java EE 7. So if you haven't yet embarked on Java EE 7, now is really the time to do so!

There are various ways to learn Java EE 7, in no particular order ...

Continue to read The Aquarium. Through this blog, we are relaying Java EE news but we are also doing our best to highlight relevant technical contents such as articles, community tutorials, etc.

Watch the GlassFish YouTube channel. Amongst others, it contains the different videos of the Java EE 7 launch, those videos will give you good technical update on Java EE and its different components specifications (JMS 2.0, JAX-RS 2.0, EJB 3.2, etc.)

Take a formal training. Oracle University is starting to roll-out Java EE 7 trainings like the 'Java EE 7: New Features' class.

Read books. There are more than 25 (!) books related to Java EE 7 or to one of the Java EE 7 component specification.

There are many more ways to learn Java EE but if I have to suggest one and only one way, I would recommend the Java EE 7 Tutorial. It's exhaustive and clear, it's free and it continues to evolve.

And finally as the introductory quote suggest, participation is key to learning. Participate in JUGs, participate in Adopt-a-JSR, get involved in the different open source communities evolving around Java EE, participate in the JCP... in one word, participate!

Wednesday Jun 11, 2014

"Those who have knowledge, don’t predict. Those who predict, don’t have knowledge."

– Lao Tzu

You may have noticed Thoughtworks recently crowned the likes of AngularJS, etc imminent successors to server-side web frameworks. They apparently also deemed it necessary to single out JSF for righteous scorn. I have to say as I was reading the analysis I couldn't help but remember they also promptly jumped on the Ruby, Rails, Clojure, etc bandwagon a good few years ago seemingly similarly crowning these dynamic languages imminent successors to Java. I remember thinking then as I do now whether the folks at Thoughtworks are really that much smarter than me or if they are simply more prone to the Hipster buzz of the day. I'll let you make the final call on that one. I also noticed mention of "J2EE" in the context of JSF and had to wonder how up-to-date or knowledgeable the person writing the analysis actually was given that the term was basically retired almost a decade ago. There's one thing that I am absolutely sure about though - as a long time pretty happy user of JSF, I had no choice but to speak up on what I believe JSF offers. If you feel the same way, I would encourage you to support the team behind JSF whose hard work you may have benefited from over the years.

True to his outspoken character PrimeFaces lead Cagatay Civici certainly did not mince words making the case for the JSF ecosystem - his excellent write-up is well worth a read. He specifically pointed out the practical problems in going whole hog with bare metal JavaScript, CSS, HTML for many development teams. I'll admit I had to smile when I read his closing sentence as well as the rather cheerful comments to the post from actual current JSF/PrimeFaces users that are apparently supposed to be on a gloomy death march. In a similar vein, OmniFaces developer Arjan Tijms did a great job pointing out the fact that despite the extremely competitive server-side Java Web UI space, JSF seems to manage to always consistently come out in either the number one or number two spot over many years and many data sources - do give his well-written message in the JAX-RS user forum a careful read. I don't think it's really reasonable to expect this to be the case for so many years if JSF was not at least a capable if not outstanding technology. If fact if you've ever wondered, Oracle itself is one of the largest JSF users on the planet. As Oracle's Shay Shmeltzer explains in a recent JSF Central interview, many of Oracle's strategic products such as ADF, ADF Mobile and Fusion Applications itself are built on JSF. There are well over 3,000 active developers working on these codebases. I don't think anyone can think of a more compelling reason to make sure that a technology is as effective as possible for practical development under real world conditions.

Standing on the shoulders of the above giants, I feel like I can be pretty brief in making my own case for JSF:

JSF is a powerful abstraction that brings the original Smalltalk MVC pattern to web development. This means cutting down boilerplate code to the bare minimum such that you really can think of just writing your view markup and then simply wire up some properties and event handlers on a POJO. The best way to see what this really means is to compare JSF code for a pretty small case to other approaches. You should then multiply the additional work for the typical enterprise project to try to understand what the productivity trade-offs are. This is reason alone for me to personally never take any other approach seriously as my primary web UI solution unless it can match the sheer productivity of JSF.

Thanks to JSF's focus on components from the ground-up JSF has an extremely strong ecosystem that includes projects like PrimeFaces, RichFaces, OmniFaces, ICEFaces and of course ADF Faces/Mobile. These component libraries taken together constitute perhaps the largest widget set ever developed and optimized for a single web UI technology. To begin to grasp what this really means, just briefly browse the excellent PrimeFaces showcase and think about the fact that you can readily use the widgets on that showcase by just using some simple markup and knowing near to nothing about AJAX, JavaScript or CSS.

JSF has the fair and legitimate advantage of being an open vendor neutral standard. This means that no single company, individual or insular clique controls JSF - openness, transparency, accountability, plurality, collaboration and inclusiveness is virtually guaranteed by the standards process itself. You have the option to choose between compatible implementations, escape any form of lock-in or even create your own compatible implementation! Open standards like JSF also tend to have strong out-of-the-box tools/IDE support.

As you might gather from the quote at the top of the post, I am not a fan of crystal ball gazing and certainly don't want to engage in it myself. Who knows? However far-fetched it may seem maybe AngularJS is the only future we all have after all. If that is the case, so be it. Unlike what you might have been told, Java EE is about choice at heart and it can certainly work extremely well as a back-end for AngularJS. Likewise, you are also most certainly not limited to just JSF for working with Java EE - you have a rich set of choices like Struts 2, Vaadin, Errai, VRaptor 4, Wicket or perhaps even the new action-oriented web framework being considered for Java EE 8 based on the work in Jersey MVC...

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

Tuesday Jun 10, 2014

The Java Persistence 2.1 specification (JSR 338) adds support for various new features such as schema generation, stored procedure invocation, use of entity graphs in queries and find operations, unsynchronized persistence contexts, injection into entity listener classes, etc.

JPA 2.1 also add support for Type Conversion methods, sometime called Type Converter. This new facility let developers specify methods to convert between the entity attribute representation and the database representation for attributes of basic types.

For additional details on Type Conversion, you can check the JSR 338 Specification and its corresponding JPA 2.1 Javadocs. In addition, you can also check those 2 articles. The first article ('How to implement a Type Converter') gives a short overview on Type Conversion while the second article ('How to use a JPA Type Converter to encrypt your data') implements a simple use-case (encrypting data) to illustrate Type Conversion. Mission critical applications would probably rely on transparent database encryption facilities provided by the database but that's not the point here, this use-case is easy enough to illustrate JPA 2.1 Type Conversion.

Monday Jun 09, 2014

Yeap, it has been 8 years since the term J2EE was replaced, and still some people refer to it (mostly recruiters, luckily!). But then comes the question: what has changed besides the name? Our community friend Abhishek Gupta worked on this question and provided an excellent response titled "What's in a name? Java EE? J2EE?". But let me give you a few highlights here so you don't lose yourself with YATO (yet another tab opened):

J2EE used to be an infrastructure and resources provider only, requiring developers to depend on external 3rd-party frameworks to then implement application requirements or improve productivity

J2EE used to require hundreds of XML lines of codes to define just a dozen of resources like EJBs, MDBs, Servlets, and so on

J2EE used to support only EAR (Enterprise Archives) with a bunch of other archives like JARs and WARs just to run a simple Web application

And so on, and so on! It was a great technology but still required a lot of work to get something up and running. Remember xDoclet? Remember Struts? The old days of pure Hibernate code? Or when Ajax became a trending topic and we were all implementing it with DWR Servlet? Still, we J2EE developers survived, and learned, and helped evolve the platform to a whole new level of DX (Developer Experience).

A new DX for J2EE suggested a new name. One that referred to the platform as the Enterprise Edition of Java, because "Java is why we're here" quoting Bill Shannon. The release of Java EE 5 included so many features that clearly showed developers the platform was going after all those DX gaps.

Radical
simplification of the persistence model with the introduction of JPA

Support of Annotations following the launch of Java SE 5.0

Updated XML APIs with the introduction of StAX

Drastic simplification of the EJB component
model (with annotations!)

Convention over Configuration and Dependency Injection

A few bullets you may say but that represented a whole new DX and a vision for upcoming versions. Clearly, the release of Java EE 5 helped drive the future of the platform by reducing the number of XMLs, Java Interfaces, simplified configurations, provided convention-over-configuration, etc! We then saw the release
of Java EE 6 with even more great features like Managed Beans, CDI, Bean Validation, improved JSP and Servlets APIs, JASPIC, the posisbility to deploy plain WARs and so many other improvements it is difficult to list in one sentence. And we've gotta give Spring Framework some credit here: thanks to Rod Johnson and team, concepts like Dependency Injection fit perfectly into the Java EE Platform. Clearly, Spring used to be one of the most inspiring frameworks for the Java EE platform, and it is great to see things like Pivotal and Spring supporting JSR 352 Batch API standard! Cooperation to keep improving DX at maximum in the server-side Java landscape.

The master piece result of these previous releases is seen and called today as Java EE 7, which by providing a newly and improved JavaServer Faces release, with new features for Web Development like WebSockets API, improved JAX-RS, and JSON-P, but also including Batch API and so many other great improvements, has increased developer productivity and brought innovation to server-side Java developers. Java EE is not just a new name (which was introduced back in May 2006!) but a new Developer Experiencefor server-side Java developers.

If you are a licensed vendor, perhaps you want to continue using the "Java EE Compatible" logo.

A message to all job recruiters: stop using J2EE and start using Java EE if you want to find great Java EE 5, Java EE 6, or Java EE 7 developers

To not only save you recruiter valuable characters when tweeting that job opportunity but to also match the correct term, we invite you to replace long terms like "Java/J2EE" or even worse "#Java #J2EE #JEE" or all these awkward combinations with the only acceptable hashtag: #JavaEE. And to prove that Java EE is catching among developers and even recruiters, and that J2EE is past, let me highlight here how are the jobs trends! The image below is from Indeed.com trends page, for the following keywords: J2EE, Java/J2EE, Java/JEE, JEE. As you can see, J2EE is indeed going away, while JEE saw some increase. Perhaps because some people are just lazy to type "Java" but at the same time they are aware that J2EE (the '2') is past. We shall forgive that for a while :-)

Another proof that J2EE is going away is by looking at its trending statistics at Google. People have been showing less and less interest in the term J2EE. See the chart below:

Recruiter, if you still need proof that J2EE is past, that Java EE is trending, and that other job recruiters are seeking for Java EE developers, and that the developer community is aware of the new term, perhaps these other charts can show you what term you should be using. See for example the Job Trends for Java EE at Indeed.com and notice where it started... 2006! 8 years ago :-)

Last but not least, the Google Trends for Java EE term (including the still wrong but forgivable JavaEE term) shows us that the new term is catching up very well. J2EEis past.

Oh, and don't worry about the curves going down. We developers like to be hipsters sometimes and today only AngularJS, NodeJS, BigData are going up. Java EE and other traditional server-side technologies such as Spring, or even from other platforms such as Ruby on Rails, PHP, Grails, are pretty much consolidated and the curves... well, they are consolidated too. So If you are a Java EE developer, drop that J2EE from your résumé, and let recruiters also know that this term is past. Embrace Java EE, and enjoy a new developer experience for server-side Java developers.

Friday Jun 06, 2014

Devoxx UK is taking place next week (12th and 13th June) in London. As with any Devoxx conference, this UK edition will have a nice mix of content, an impressive list of speakers and obviously Java EE will be well will covered too:

In addition, there will be 2 BoF related to Java EE on Thursday evening, the first BoF will be about the Java EE platform and the second one will be about the Java EE Reference Implementation, i.e. GlassFish.

I will participate in the Java EE Community BoF where will discuss Java EE general but with all recent activities, I suspect that a large portion of the BoF will spent on discussing the current plans for Java EE 8. Right after and in the same room, I will join Steve Millidge of C2B2 for the GlassFish is here to stay! BoF. The goal is to discuss on GlassFish, the current status, the plans for the next release, how the community can contributes, etc.

It should be mentioned that attending those BoFs is completely free, just make sure to register here. So if you are in London next week, mind the Geek and see you at Devoxx UK!

Thursday Jun 05, 2014

Pivotal, the company currently funding development of the popular Spring Framework, recently announced JSR 352 (aka Batch Applications for the Java Platform) compliance for the Spring Batch project. More specifically, Spring Batch targets JSR-352 Java SE runtime compatibility rather than Java EE runtime compatibility. If you are surprised that APIs included in Java EE can pass TCKs targeted for Java SE, you should not be. Many other Java EE APIs target compatibility in Java SE environments such as JMS and JPA. You can read about Spring Batch's support for JSR-352 here as well as the Spring configuration to get JSR-352 working in Spring (typically a very low level implementation concern intended to be completely transparent to most JSR-352 users).

JSR 352 is one of the few very encouraging cases of major active contribution to the Java EE standard from the Spring development team (the other major effort being Rod Johnson's co-leadership of JSR 330 along with Bob Lee). While IBM's Christopher Vignola led the spec and contributed IBM's years of highly mission critical batch processing experience from products like WebSphere Compute Grid and z/OS batch, the Spring team provided major influences to the API in particular for the chunk processing, listeners, splits and operational interfaces. The GlassFish team's own Mahesh Kannan also contributed, in particular by implementing much of the Java EE integration work for the reference implementation. This was an excellent example of multilateral engineering collaboration through the standards process.

For many complex reasons it is not too hard to find evidence of less than amicable interaction between the Spring ecosystem and the Java EE standard over the years if one cares to dig deep enough. In reality most developers see Spring and Java EE as two sides of the same server-side Java coin. At the core Spring and Java EE ecosystems have always shared deep undercurrents of common user bases, bi-directional flows of ideas and perhaps genuine if not begrudging mutual respect. We can all hope for continued strength for both ecosystems and graceful high notes of collaboration via efforts like JSR 352.