Wednesday Mar 02, 2016

Developers Continue to Affirm Strong Support for Java EE 7

Some of you might recall last year in the JavaOne time frame we highlighted a key DZone survey showing strong developer support for Java EE 7, even as compared to alternatives. Since then a few things have changed. WebLogic announced official commercial support for Java EE 7. It now is clear JBoss EAP, WebSphere Classic and TomEE are also very close to coming forward with their Java EE 7 support (as you know WildFly and WebSphere Liberty already officially support Java EE 7 in addition to GlassFish and others). We thought this was a good point to do another pulse check of the community to see where Java EE 7 adoption stands now. We could not think of a better way to do this than simply running our own Twitter survey.

We asked a very simple question on the survey - "Which version of Java EE are you running in production environments?". Frankly the results of the survey were far better than we could have ever expected. As the graph below shows almost 60% responded they use Java EE 7. 33% responded that they were using Java EE 6. Only 8% indicated they were using Java EE 5. We deliberately made the choices mutually exclusive and eliminated J2EE as irrelevant to our survey. 

Here is a link to the actual survey on the Java EE twitter account. There is no downplaying the fact a strong majority indicated Java EE 7 usage. This data point goes a long way to removing the severe Java EE 7 skepticism in certain corners of the Java EE ecosystem. A nice side effect of the survey is that we got in touch with a number of Java EE 7 adopters willing to share their story with the community. The folks that responded that they are using Java EE 6 and Java EE 5 represent both a challenge and an opportunity. While it is true Java EE 7 does not represent a major programming model change in the way Java EE 5 or Java EE 6 did, the reality is that there is simply too much in Java EE 7 worth taking advantage of in terms of the sheer amount of improvements to many APIs. If you are a fan of Java EE 7 you should educate colleagues on what it brings to the table.

No survey is perfect of course. Since it is a Twitter survey it is highly susceptible to selection bias. There is no denying the fact though that the sample size for the survey is extremely strong at over 1,100. That is a number well representative for the Java ecosystem and most certainly worth thinking about seriously.

We can hope that developer support for Java EE 7 continues to strengthen even further in coming months. I can only be very thankful to all the folks that participated in the survey and showed their sincere support for Java EE.

Tuesday Mar 01, 2016

Self-Documented Services Using JAX-RS Analyzer

One of the things I miss the most about SOAP is the fact that much like Java, it is strongly typed. That means one can take a look at a WSDL document to understand what a service does. Similarly tools can easily read and use a SOAP service including generating clients, GUI visualizations and accurate documentation. WADL was conceived of in the REST world to overcome some of these shortcomings. Unfortunately WADL is sparsely supported and even more sparsely used. This presents a pretty big problem if you are writing REST services that are consumed by folks outside of your own team and even worse people that you may not even know. The answer so far has been manually writing documentation for REST services that are laborious, error-prone and often out of date (incidentally you should be aware that Jersey, the JAX-RS reference implementation, does support WADL).

For JAX-RS developers though there is JAX-RS Analyzer to the rescue. JAX-RS Analyzer is a simple but extremely useful open source JAX-RS plugin written by Sebastian Daschner. It reads JAX-RS annotations/metadata to automatically generate documentation - in  plain text, AsciiDoc or Swagger. The Swagger option is especially compelling. Swagger is the closest thing at the moment to closing the WSDL/UDDI gap for REST.

If you are still unfamiliar with JAX-RS Analyzer, you should definitely take a look at Sam Sepassi's  excellent recent write-up on it. It will save you from hours of tediously documenting your REST APIs.

Monday Feb 29, 2016

Java SE 8 and Java EE 7 in Production at TecSinapse

One of the most important things to do at this stage of the life-cycle of Java EE is highlight successful adoption stories at a regular cadence. We have been doing just that for a long time through our adoption stories blog, this humble blog as well as JavaOne. Indeed JavaOne 2016 was particularly good in this regard. We had a number of solid adoption stories submitted that we could select from. A nice adoption story presented at JavaOne 2016 was from TecSinapse. The session was presented by Michael Santos.

For those unaware, Michael Santos is an active member of the Brazillian Java community. He is a Java Champion, JavaOne Rock Star Speaker, blogger, OpenJDK committer, JCP expert and open source advocate. Michael is part of SouJava's board - one of the largest and most influential JUGs in the world. As head of development and operations at TecSinapse he oversaw real world adoption of both Java SE 8 and Java EE 7 in customer projects. TecSinapse is a consulting, solutions and integration provider out of Brazil. Some of their clients include Audi, Mercedes-Benz, Harley-Davidson, Jaguar, Land Rover, Nissan, Toyota and BMW. At JavaOne Michael provided specific insights on how he used Java EE 7 and Java SE 8 together. He also did not shy away from pointing out where Java SE and Java EE integration should improve. You can view his very well-delivered session below (click here if you are having trouble seeing the embedded video).

If you have a similarly great Java EE adoption story to share with the community (particularly migration stories from other technologies), please do feel encouraged to reach out. In the spirit of Java EE centric vendor neutrality, what Java EE implementation or tool set you choose does not matter at all and neither does which part of the globe you are in.

Sunday Feb 28, 2016

Java EE @ ConFoo 2016

ConFoo 2016 took place 24-26 February in Montreal, Canada. To my knowledge it is the largest developer conference north of the border. The conference has roots in PHP, but has been making an effort to better attract a Java audience hence it was important for me to support the conference. If you are a Canadian Java developer, I would consider adding ConFoo to your radar as a more convenient (and possibly cheaper) event to go to in order to stay up-to-date. Topics covered included PHP, Ruby, Python, methodology, usability, JavaScript/HTML5, mobile, cloud, big data, DevOps, NoSQL, Java and .NET.

I delivered sessions on developing practical microservices with Java EE as well as aligning Java EE with Reactive programming. More details on the sessions and ConFoo 2016, including slide decks, videos and code, posted on my personal blog.

Friday Feb 26, 2016

The next VTS round is fast approaching!

Virtual Technology Summit is a set of free online events covering a wide variety of technical topics (Java, Middleware, Database, IoT, etc.). And there is something for everyone (see full agenda). In the upcoming edition, the following sessions should be particularly interesting for WebLogic users:
  • Down-to-Earth Microservices with Java EE
  • Java SE 8 for Java EE Developers
  • Thinking Beyond ORM in JPA
  • Developing Java EE 7 Applications with WebLogic Server 12.2.1
There are 3 VTS events to suit your geographic location - Americas (March 8th), APAC (March 15th) and Europe (April 5th).  For schedules and abstracts for all sessions, please see OTN Virtual Technology Summit All Track Agenda and Abstracts and make sure to register today!

Monday Feb 22, 2016

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

One of the most important things to do at this stage of the life-cycle of Java EE is highlight successful adoption stories at a regular cadence. We have been doing just that for a long time through our adoption stories blog, this humble blog as well as JavaOne. Indeed JavaOne 2016 was particularly good in this regard. We had a number of solid adoption stories submitted that we could select from. We will highlight all of those stories here. A very nice adoption story presented at JavaOne 2016 was from the TAS Group. The session was presented by Andrea Folli, the CTO of the cashless business unit of the TAS group that recently re-architected their legacy systems using Java EE 7.

The TAS Group is a very important player in back-end e-payment solutions worldwide and certainly in Italy/Europe (so think the folks that do the actual heavy lifting behind e-commerce credit card processing, in-store credit card readers and bank ATMs). The Italy based company has 15 years of experience in providing mission-critical infrastructure for some of the largest financial organizations in Italy and the EU. They manage over 100 million cards world-wide. Over 65% of acquiring systems and more than 50% of issuing systems in Italy alone are managed by them. The company's legacy systems had been written with a combination of COBOL, Spring and J2EE. They successfully migrated these legacy systems to Java EE 6 and now Java EE 7. In adopting Java EE, Andrea cited standardization, portability, vendor neutrality, lack of third party dependencies and runtime performance as some of the reasons. Besides Java EE 7 APIs like JSF, CDI, EJB 3, JPA, JAX-RS, JAX-WS, batch and JTA he noted the use of Eclipse, Maven, Subversion, soapUI, trac and SonarQube. Although he did not name them specifically Andrea touched upon concepts like microservices, reactive architectures and Domain-Driven Design (DDD) using Java EE during his talk. He also shared some very cool Java EE best practices he discovered for his use cases along with cool architectural insights for e-Payment processing. You can view his well-delivered session below (click here if you are having trouble seeing the embedded video).

If you have a similarly great Java EE adoption story to share with the community (particularly migration stories from other technologies), please do feel encouraged to reach out. In the spirit of Java EE centric vendor neutrality, what Java EE implementation or tool set you choose does not matter at all and neither does which part of the globe you are in.

Thursday Feb 18, 2016

Java EE @ DevNexus 2016

DevNexus 2016 was held in historic Atlanta on February 15-17. For those of you not familiar with it, DevNexus is the most significant Java centric (but not Java focused) 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 Stuart Marks, Stephen Chin, Heather VanCura, Venkat Subramaniam, Yakov Fain, Burr Sutter, Freddy Guime, Bob Paulin, Jason Porter, Rafael Benevides, Scott Kramer and so on. Topics included Java SE, NoSQL, mobile, cloud, Docker, HTML5/JavaScript and of course Java EE. This was a solid, fully sold out year for DevNexus.

I ran a whole day workshop on the basics of Java EE as well as delivering a session on developing practical microservices with Java EE. More details on the sessions and DevNexus 2016, including slide decks, videos and code, posted on my personal blog.

Wednesday Feb 10, 2016

Java EE in Practice for Secure Online Voting at Scytl

One of the most important things to do at this stage of the life-cycle of Java EE is highlight successful adoption stories at a regular cadence. We have been doing just that for a long time through our adoption stories blog, this humble blog as well as JavaOne. Indeed JavaOne 2016 was particularly good in this regard. We had a number of solid adoption stories submitted that we could select from. We will highlight all of those stories here in the coming months. A particularly nice adoption story presented at JavaOne 2016 was from Scytl. The session was presented by Alex Soto.

Scytl is a very innovative and important company that enables secure online voting across the world. Alex was the architect of a service-only back end system at Scytl written using vanilla Java EE and TomEE. Alex talked about the reasons they chose Java EE (over Spring in this case) such as ease-of-use, productivity, simplicity, standardization, lack of third-party dependencies, simple deployment, fast startup and performance. He also discussed their use of some pretty cool TomEE features, Arquillian, Docker and Apache Mesos. For those unaware, Alex is a Java EE advocate, blogger, author, JCP expert and open source commiter. You can view Alex's well-rated session below (click here if you are having trouble seeing the embedded video).

If you have a similarly great Java EE adoption story to share with the community (particularly migration stories from other technologies), please do feel encouraged to reach out. In the spirit of Java EE centric vendor neutrality, what Java EE implementation or tool set you choose does not matter at all and neither does which part of the globe you are in.

Tuesday Feb 09, 2016

Cargo Tracker Java EE 7 Blue Prints Now Running on WebLogic

For those unaware the Cargo Tracker project exists to serve as a blue print for developing decently designed Java EE 7 applications, principally utilizing Domain-Driven Design (DDD). The project has long run on GlassFish 4 and Java SE 7. The project was recently enhanced to run the same code base also on WebLogic 12.2.1 and Java SE 8. The instructions for running the project on WebLogic are available here. Feel free to give it a spin to get a feel for both Java EE 7 and WebLogic 12.2.1.

The fact that a fairly non-trivial project like Cargo Tracker can run on both GlassFish and WebLogic with no code changes and some very minimal configuration differences handled via Maven profiles speaks to how much Java EE portability is a reality with Java EE 7. Some initial work has also been done to run the project on WildFly - hopefully we will be able to highlight that work here soon as well.

Monday Feb 08, 2016

Revamping the Security API in Java EE 8

JAAS, JASPIC, JACC. If those acronyms do not sound familiar, you are in good company. I have been developing with Java EE for almost two decades and I was not terribly familiar with them until I seriously started thinking about revamping Java EE security in the early Java EE 7 time frame. Those are the three main Java EE related standard APIs that have remained largely unchanged since the J2EE era. That is until the Java EE Security API aimed for Java EE 8.

The reason I mostly didn't need to know about these APIs is because of the way Java EE security has evolved over the years. As of Java EE 7 the way applications work is that you do some minimal web.xml configuration declaring what type of authentication you want (basic, form, digest, etc), what application server "realm" (logical link name to application server security configuration) and what roles (security groups) have access to secure parts of the application. Most of the real work is typically actually done in application server admin GUI wizards like configuring what identity store you want to use (database, LDAP, etc) and how underlying groups map to roles (for most of my applications the application roles and identity store groups are exactly the same). There are certainly some benefits to this approach that most other technologies do not have. Most of the heavy lifting for security is just a few mouse clicks as opposed to writing and maintaining code. You can hand off the work of securing the application to an admin where this work often best belongs. Application servers have sophisticated security admin tooling that seems to have everything under the Sun including things like federated security through SAML.

This is not the approach more feature poor runtimes that lack admin GUIs take and the approach also has some downsides. The most significant downside is that beyond learning Java EE APIs as a developer you also need to know about each application server's security administration features. This also means that these features are slightly different from one application server to another, limiting application portability. In a PaaS environment it is a lot easier if all security configuration is done inside the application itself, making the application more self-contained. The last problem is related to the age and focus of the current APIs used in Java EE - JAAS, JASPIC, JACC. These APIs have not gone through a significant revision in a while and their focus is on vendor plug-in writers, not application developers. This becomes a problem when developers need to do things that the application server does not have built-in support for such as using a custom data store (say using a security database with a poorly designed legacy schema) or using a custom authentication mechanism (say your own homegrown HTTP headers for federated security). There are third party frameworks in the Java EE ecosystem such as Shiro and PicketLink that attempt to solve these issues - in particular making application security embedded. These frameworks are of course non-standard and increase the need to add more runtime dependencies in the application.

The new Java EE Security API slated for Java EE 8 aims to solve these problems by simplifying and modernizing security in the platform. The Security API will make it possible to embed security in most common cases in the application in the simplest way possible. It will allow for easy extensibility by providing a much simpler, modernized, developer-focused alternative to JASPIC, JAAS and JACC. In the process it will introduce simple standard terms and interfaces for Java EE security. It will also add some cool new authorization mechanisms in addition to the basic role based security that Java EE offers today.

Specification lead Alex Kosowski described all of this well during his JavaOne 2015 talk embedded below (click here if you can't see the embedded video).

The Java EE Security API is one of the most important and perhaps most awaited parts of Java EE 8. It is not very surprising that it is one of the Java EE 8 JSRs that has seen the most active participation from the community - Alex refers to some of this participation in his talk. You should feel encouraged to participate yourself perhaps starting by viewing the video above.

Friday Feb 05, 2016

Some Interesting Real World CDI Usage Statistics

The good folks over at Genuitec developing MyEclipse recently asked the Twittersphere about real world CDI usage. They ran a week-long Twitter survey asking the simple question - "Do you use CDI in your Java EE applications?". The results of the survey were pretty interesting and certainly worth sharing. As the graph below shows 60% responded they use CDI. 21% responded that they did not. 19% did not know what CDI was.

Here is a link to the actual survey on the MyEclipse twitter account. For those unaware the MyEclipse team is working hard to bridge the CDI and Java EE support gaps in Eclipse - hence the question.

It is definitely very good that a clear majority said they were using CDI. CDI is key to writing effective Java EE applications. This data point goes a long way to removing the severe CDI skepticism in certain corners of the Java EE ecosystem. The 19% that responded that they did not know what CDI was pose both a challenge and an opportunity. If you are a Java EE or CDI fan it should tell you that there are colleagues that you should educate on CDI. I am often still taken aback when a developer does not know what CDI is or still refers to Java EE as "J2EE" (the term J2EE has been long retired with the likes of "J2SE" and COM/DCOM). A large number of these same developers are very pleasantly surprised to learn how much modern Java EE can help make their day-to-day work easier.

No survey is perfect of course. The sample data size for the survey is small but respectable at around 300. Around 500-1000 data points is probably more representative of the Java ecosystem. Since it is a Twitter survey it is probably highly susceptible to selection bias. That being said the results are definitely good enough to think about seriously.

Wednesday Feb 03, 2016

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

One of the most important things to do at this stage of the life-cycle of Java EE is highlight successful adoption stories at a regular cadence. We have been doing just that for a long time through our adoption stories blog, this humble blog as well as JavaOne. Indeed JavaOne 2015 was particularly good in this regard. We had a number of solid adoption stories submitted that we could select from. We will highlight all of those stories here in the coming months. A particularly nice adoption story presented at JavaOne 2016 was from Segurnet Portugal on migrating from Java EE 5 to Java EE 7.

Segurnet is a data sharing platform for key insurers in Portugal. It used by 65 companies, about 30,000 users with close to 1.5 million page views and over 3 million server requests. Roberto Cortez detailed how the platform was recently migrated from legacy Java EE 5 to Java EE 7 - showing specific code examples. As the end result of the migration Roberto noted latest technology adoption, improved standardization, simplicity, a net reduction in code, an increase in productivity, faster deployment times and better performance. Roberto's experience is typical for anyone considering such a migration. You can view the session below (click here if you are having trouble seeing the embedded video).

The slide deck for the talk is available on SlideShare. For those unaware, Roberto is a passionate Java EE advocate, frequent speaker, blogger and JUG leader. He now works on the TomEE Java EE application server.

If you have a similarly great Java EE adoption story to share with the community (particularly migration stories from other technologies), please do feel encouraged to reach out. In the spirit of Java EE centric vendor neutrality, what Java EE implementation or tool set you choose does not matter at all and neither does which part of the globe you are in.

Monday Feb 01, 2016

HTTP/2 and Servlet 4 in Java EE 8

HTTP is very easily the most important standard in server-side Java. The much awaited HTTP/2 standard is now complete, was fifteen years in the making and promises to radically speed up the entire web through a series of fundamental protocol optimizations. Slated to be a part of Java EE 8, Servlet 4 is the primary vehicle for making HTTP/2 available to the server-side Java ecosystem. In a key JavaOne 2016 session Servlet 4 specification leads Ed Burns and Shing wai Chan discussed Servlet 4 in detail. You can view the video below on the JavaOne 2016 YouTube playlist (click here if you can't see the embedded video). The slide deck for the talk is available here.

In the session they took a detailed look at the changes in HTTP/2 and discussed how these changes will be adopted by the Servlet 4 specification as well as technologies like JSF.

Friday Jan 29, 2016

EJB3 @Lock Annotation for CDI Beans

The EJB 3 @Lock annotation is pretty unique, interesting and useful. It provides an elegant declarative way of controlling concurrency for beans that can be shared across multiple threads such as singletons. As of Java EE 7 the annotation is only available to EJB 3 @Singleton session beans. There is a lot of value to making this bean available to all CDI beans in general. Very recently Stephan Knitelius did exactly that through a pretty simple CDI interceptor. You can read his nice write-up here.

In the longer term this work probably belongs somewhere in the standard such as in an update of the Java EE Concurrency specification or a modular CDI 2 specification. Another good place for Stephen's work is the DeltaSpike project. There are many other cool EJB 3 features that could be similarly made available to CDI beans generally such as @Startup, @Asynchronous and @MaxConcurrency. Some of these issues have long been discussed in the EJB specification JIRA entries.

Wednesday Jan 27, 2016

Java EE @ Oredev

Oredev 2015 was held on 3-6 November in Malmo Sweden. This was my third time at the largest IT conference in the Scania region. The conference is rooted in .NET and development process/methodology but has been trying hard to beef up it's Java content. This year it attracted a decent section of the Java crowd including my fellow Oracle colleagues Bruno Borges and Stephen Chin. Topics covered included .NET, Java SE, Java EE, mobile, methodology, agile, HTML5, JavaScript and NoSQL.

I did talks on Java EE 8 and aligning Java EE with the reactive movement. More details, including slide decks and session videos, posted on my personal blog.