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.

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.

Thursday Jan 21, 2016

AngularBeans: Java EE 7/CDI Integration with AngularJS

In the highly volatile world of JavaScript frameworks, AngularJS has managed to maintain a lead at least for now. The good news for Java EE developers is that Java EE generally and Java EE 7 in particular works extremely well as a back-end for frameworks like AngularJS. To see why this is you need not look much farther than my talk on the topic and the corresponding example code (the code is deliberately self-contained with setup instructions so that you can explore it in detail on your own).

One of the drawbacks of the JavaScript rich client approach is that it often involves some boilerplate code that does not exist in server-side web frameworks due to the remote communication layer involved. To borrow concepts from the old J2EE design patterns, this boilerplate involves the creation and maintenance of DTOs (Data Transfer Objects) and remote proxies, not to mention the plumbing code necessary for the remote communication.  If you look carefully at my code example the boilerplate is not that hard to spot.

One way of avoiding this boilerplate is a tight binding layer with the underlying back-end technology that automatically generates the DTO, remote proxy and remote plumbing parts. In the process the binding layer can bring a lot of interesting back-end features forward to the client as well.

Fortunately for the Java EE ecosystem, my Tunisian friend Bessem Hmidi has formulated just such a solution focusing on CDI as the back-end component model. He has aptly named his project AngularBeans and the project is now on GitHub for everyone to use. I am very happy that we were able to host Bessem at JavaOne 2015 to talk about the project. In his session he explained the basic motivation for AngularBeans, discussed the features he has implemented so far and did quite a bit of live coding in the process! You can view the session below (click here if you can't see the embedded video).

The session really speaks volumes as to the power of the solution and why it is a very valuable part of the CDI/Java EE ecosystem. The project is at a very early stage, so this is a great time to get involved, evaluate the project and perhaps even contribute.

Thursday Dec 03, 2015

EJB and CDI - Alignment and Strategy

We often get questions related to EJB and CDI, to the convergence (or divergence!) between those 2 important Java EE technologies.  That particular topic was discussed a few months ago by Linda De Michiel (Java EE Specification Lead and former JPA Specification Lead) during JavaDay Tokyo 2015.

In her session, Linda first set the stage by discussing the history of both EJB and CDI, and how those 2 technologies have evolved over time. She then discussed the advantages and disadvantages, some of the gaps between those 2 technologies. Linda finally concluded by discussing some strategies to improve things going forward. For example, the @Transactional interceptors was introduced in Java EE 7. In Java EE 8, the idea is to continue on the path of extracting additional container services to make those more widely and more easily available in the platform. Java EE 8's CDI Security Interceptors and the new 'flexible MDB' comes to mind.

This is an interesting talk as it discusses the past, the present and the future of fundamental Java EE technologies. It should be mentioned that David Blevins and Jean-Louis Monteiro (TomEE) gave a similar talk during JavaOne : "EJB/CDI Alignment (What does it Mean?)"

Friday Oct 02, 2015

Bessem Hmidi on AngularBeans at JavaOne 2015

For the Java EE track at JavaOne 2015 we are highlighting some key sessions and speakers to better inform you of what you can expect, right up until the start of the conference.

To this end we recently interviewed Bessem Hmidi. Bessem is the JUG leader of the ESPRIT JUG Tunisia, an educator, a researcher, an international speaker and a Java EE enthusiast. He spoke to us about his accepted session at JavaOne 2015 on AngularBeans. AngularBeans is a very innovative open source project that marries AngularJS with CDI and Java EE (click here if you can't see the embedded video). We've highlighted AngularBeans on this humble blog in the past.

You can find details on Bessem's session on the JavaOne 2015 content catalog. The following are the other sessions we talked about:

Besides these sessions, we have a very strong program for the Java EE track and JavaOne overall - just explore the content catalog. If you can't make it, you can be assured that we will make key content available after the conference just as we have always done.

Monday Jun 01, 2015

Java EE @ Voxxed Days Algiers

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

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

Thursday May 28, 2015

AngularJS + CDI = AngularBeans

Even in the highly volatile world of JavaScript frameworks, AngularJS is still very clearly leading the pack. The good news for Java EE developers is that Java EE generally and Java EE 7 in particular works extremely well as a back-end for frameworks like AngularJS. To see why this is you need not look much farther than my talk on the topic and the corresponding example code (the code is deliberately self-contained with setup instructions so that you can explore it in detail on your own).

One of the drawbacks of the JavaScript rich client approach is that it often involves some boilerplate code that does not exist in server-side web frameworks due to the remote communication layer involved. To borrow concepts from the old J2EE design patterns, this boilerplate involves the creation and maintenance of DTOs (Data Transfer Objects) and remote proxies, not to mention the plumbing code necessary for the remote communication.  If you look carefully at my code example the boilerplate is not that hard to spot. One way of avoiding this boilerplate is a tight binding layer with the underlying back-end technology that automatically generates the DTO, remote proxy and remote plumbing parts. In the process the binding layer can bring a lot of back-end features forward to the client as well.

Fortunately for the Java EE ecosystem, my good friend Bessem Hmidi has formulated just such a solution focusing on CDI as the back-end component model. He has aptly named his project AngularBeans and first release is now on GitHub for everyone to use. His simple hello world example speaks volumes as to the power of this solution. Beyond simply removing boilerplate AngularBeans does far more (look at the GitHub page for full details):

  • Bean Validation on the client side
  • Built-in internationalization support from server-side property files
  • SockJS support
  • Server-side event binding

He has a more comprehensive example that demonstrates all the capabilities of AngularBeans. The project is at a very early stage, so this is a great time to get involved! In particular Bessem is looking to improve the project documentation.

On a slightly separate note, Bessem is the JUG leader of the ESPRIT JUG in Tunisia. He is one of the key Java EE advocates in North Africa, along with the likes of Egypt JUG leader Mohamed Taman. Bessem and I both very recently spoke at the inaugural Voxxed Days Algiers, Algeria (expect the trip report from that great event soon!).

Monday Apr 20, 2015

A Directory for CDI Plugins

One of the key goals of CDI was to significantly improve Java EE platform extensibility at the core component level. Generic dependency injection alone goes a long way in making it fairly easy to integrate third-party components and libraries. CDI goes much farther by offering an entire portable extension API geared specifically towards writing CDI plugins. The most obvious manifestation of a resulting CDI ecosystem is plug-in collection projects like Seam 3 and it's successor DeltaSpike. However, there is actually a lot more to the CDI ecosystem, most notably tools (think IDEs) and larger projects that offer CDI pluggability.

So far there has not been a concerted effort to create a directory of sorts for the CDI ecosystem. While such a directory will (hopefully) never be completely all-encompassing it is helpful to have one place you could go to in order to find out all the plugins available for CDI. Most recently the CDI specification site added an ecosystem section to try and address this need. The page is looking pretty good already including listings like DeltaSpike, VRaptor, Vaadin, Camel, Forge and Arquillian - you should check it out. I can already see a few missing though like MyBatis/CDI, Agorava, Struts 2/CDI, Wicket/CDI, ZK/CDI and a few more (I'll reach out to the CDI folks to see why these might be missing). If you similarly see any CDI plugins that should be listed, you should try and reach out (the top of the CDI ecosystem page says how you can do so).

Thursday Mar 26, 2015

New book: "Web Development with Java and JSF"

During JavaLand, I had the pleasure to meet Michael Müller. Michael is well known in the German Java sphere as he wrote numerous articles for various IT medias. In addition, Michael is an avid JSF user and a JSF EG member.

Michael is currently writing a book titled "Web Development with Java and JSF". Since Michael is a passionate JSF user, JSF is obviously an important topic in his book. But this is not another book about JSF only. Michael's goal is to cover Web Application development at large. That means that different but related topics are also discussed through his book. There are for examples sections on JPA, Bean Validation, Responsive Design, ... Michael also plan to touch on subject such as Web Application testing with Selenium, etc.

Michael has decided to use “a more fair” publishing approach where the book has 2 prices: a minimum and a suggested price. Based on that, the potential buyer is free to decide how much he wants to pay. This approach gives the buyer the ability to decide how much s/he think the book is really worth but this also gives the author more financial rewards as there is no intermediary between the publisher and the author.

A great deal of the book has already been written (+240 pages) but Michael is planning to add extra content.  You can read a sample here. "Web Development with Java and JSF" is available in the usual eBook formats (PDF, Mobi, ePub) and once you've bought it, you are entitled to get the updated versions for free.

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.

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.

Monday Feb 02, 2015

CDI and DeltaSpike Overview by CDI Specification Lead

For those of us that have been using CDI for a while it's easy to forget that basic refreshers are extremely valuable for newcomers. Fortunately this point is not lost on current CDI specification lead Antoine Sabot-Durand. He recently finished presenting a three-part webinar covering CDI and DeltaSpike.

In the first of these webinars Antoine covered the very basics of CDI (along with some advanced features). The slides are here and the video is below:

In the second webinar in the sequence Antoine covered a few more advanced features, most notably CDI portable extensions. The slides are here and the video is below:

In the third webinar installment Antoine gave a basic overview of DeltaSpike. DeltaSpike is a very handy set of CDI plugins that all Java EE developers should we aware of. DeltaSpike very deservedly won the Duke's Choice Award for 2014. The slides are here and the video is below:

You should also check out Antoine's more forward looking JavaOne 2014 talk on CDI 2 posted here.

Friday Jan 23, 2015

Vaadin, CDI and Java EE

While some people miss this point, one of the key goals of introducing CDI into Java EE was to easily enable integrating solutions outside the standard into the platform. I was recently reminded of this myself when I saw the announcement that Vaadin now officially supports CDI and Java EE.

Vaadin has long been a very compelling GWT based Java web framework. Although it lags behind the likes of JSF and Spring MVC in terms of adoption, it is extremely polished, it is very much aligned with the Java EE design philosophy and it has a very strong following that hasn't dissipated even with the rise of HTML 5 and JavaScript frameworks. Some folks have been using Vaadin with Java EE for a while using CDI as glue. I am glad both CDI and Java EE (including Java EE 7) is now officially supported by the Vaadin team itself. Like everything else Vaadin, the Java EE/CDI integration is extremely polished with a very nice tutorial explaining the features (see the link above). Another very good resource to get started with Java EE 7, CDI and Vaadin is the YouTube video below featuring Geertjan Wielenga of the NetBeans team and Matti Tahvonen of Vaadin. They use GlassFish and NetBeans for the demo.

Another great GWT based Java web framework worth checking out that works with CDI and Java EE is Errai.

Wednesday Jan 21, 2015

Better CDI Alignment in JPA 2.1/Java EE 7

A long standing open debate within the Domain-Driven Design (DDD) community is whether entities should be able to access application services (roughly business facades in J2EE patterns parlance) and repositories (roughly DAOs in J2EE patterns parlance). If we think it's OK for entities to access these parts of the application, it poses a problem in JPA and other mainstream data access technologies - how do you inject objects into an entity? The answer today in JPA is that you can't do that. There are good technical reasons why it's difficult to allow CDI injection directly into JPA entities - it becomes very difficult to figure out how to manage the entity life-cycle if it is managed by both the CDI and JPA runtimes at the same time.

So is there a solution to this problem? The good news in JPA 2.1 and Java EE 7 is that there is a clever workaround. While you can't use CDI injection in entities, entity listeners now fully support injection. If needed you can then pass in an appropriately scoped injected object (probably an application scoped bean) into the entity or anything else that you need from the entity listener. This is exactly the technique demonstrated by Hantsy Bai in explaining CDI support in JPA 2.1 entity listeners. Besides entity access to services and repositories, being able to use injection in entity listeners is generally very helpful for more complex cross-cutting concern like requirements at the JPA layer. Prior to JPA 2.1 both Apache CODI and Seam 3 enabled injection into JPA entity listeners.

If you happen to need a basic introduction to JPA entity listeners, Alexandre Gama has one of the best compact write-ups I've seen so far.

For the record, I do think accessing application services and repositories in entities violates the separation of concerns principle and should be done very sparingly :-).

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

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.