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.

Monday Oct 27, 2014

MyBatis-CDI: Persistence Alternative for Java EE

ORM is a by and large proven technique that has been around for a long time now (believe it or not TopLink was created in the early nineties for Smalltalk and then ported to Java). It maximizes code flexibility and database independence while minimizing boilerplate code and allowing the construction of rich domain models. Even for relatively complex domain models and queries, ORM engines tend to generate better quality SQL optimized to the underlying database than the average Java developer would with considerable time and effort. This is precisely why JPA is the persistence standard for Java EE and why a majority of modern server-side applications use ORM (indeed almost every other major development platform including .NET and Ruby on Rails positions ORM as it's default persistence solution).

That being said, there can certainly be cases where using hand-written native SQL is necessary or desirable. Most people don't seem to realize it, but JPA has always included very good support for native queries to meet these use cases (JPA 2.1 now even includes formal support for stored procedures - the ultimate form of database bound query execution). If you weren't aware of this, you should definitely read Taudo Wenzel's excellent write-up on using JPA native queries to generate reports (a common use case for native queries).

In fact you have other options for native SQL centric persistence in Java EE applications. One of the nicest ones is MyBatis-CDI. It provides a very nice CDI based abstraction for MyBatis, making it extremely easy to use in Java EE applications (in case you are wondering MyBatis is the successor to the old iBatis project). Here is how simple MyBatis CDI code can look like:

In addition to JTA transactions, MyBatis-CDI also supports local transactions. I've personally also successfully used Apache Commons DbUtils with CDI to quickly port over a legacy application with tons of hand-written SQL to Java EE/GlassFish.

Thursday Sep 11, 2014

Antoine Sabot-Durand's CDI Sessions at JavaOne 2014

For the Java EE track at JavaOne 2014 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 Antoine Sabot-Durand. Antoine is the newly minted CDI specification lead. In the short time that he has been at Red Hat, he has already had the CDI 1.2 specification under his belt and he has already started work for CDI 2 (CDI 2 is a major overhaul of the specification targeted for Java EE 8). I have known about Antoine since he worked on Agorava, a social media module for CDI/Java EE. Besides working on the CDI specification, he is also responsible for the CDI ecosystem at Red Hat - currently focused on DeltaSpike.

We wanted to talk to Antoine about his CDI sessions at JavaOne 2014:

Antoine has several sessions on the track that he talked about:

  • Introducing Contexts and Dependency Injection: This is essentially a CDI primer for folks that are still newcomers or evaluating. It's probably worth attending as a refresher even for more experienced folks.
  • Going Farther with CDI 1.2: This is a slightly more advanced session talking about less commonly used features as well as the changes in CDI 1.1/CDI 1.2. The CDI ecosystem generally is also covered.
  • The Path to CDI 2.0: This is essentially a CDI futures talk. It's probably the best way to find out what is in the works for CDI 2.
  • CDI 2.0 BOF: This informal Birds-of-a-Feather session is a rare chance for you to interact directly with the folks leading the CDI specification and share your ideas, questions and feedback. It's probably the best and easiest way for most folks to contribute directly to the CDI specification.

Besides Antoine's 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 Aug 25, 2014

A Fresh Look at CDI Events

Type safe events have been one of the most elegant and innovative features in CDI for a long time. For some odd reason however they seem to continue to be fairly under-appreciated and not written about that often. It's very good to see CDI specification co-lead Antoine Sabot-Durand recognizing this and aiming to do something about it. In his most recent blog post, Antoine wrote up an excellent refresher on CDI. He covers the basics of events, some of the more advanced features as well as some best practices. The blog post actually covers some of the more fine grained changes in CDI 1.1 and CDI 1.2. Antoine also briefly talks about some of the possible enhancements to events in CDI 2.

It's definitely well worth a read if you are already a CDI fan or just beginning to explore it. Do pass the link on if you know anyone that may benefit from it. Note that the upcoming GlassFish 4.1 release will support CDI 1.2.

Friday Aug 22, 2014

Java EE @ NFJS Central Iowa Software Symposium Des Moines

As some of you may be aware I recently joined the well-respected US based No Fluff Just Stuff (NFJS) Tour. The NFJS Central Iowa Software Symposium was held August 8 - 10 in Des Moines. The Des Moines show is one of the smaller ones but still was good overall. It is one of the few events of it's kind that take place this part the country so it is extremely important.

I had five talks total over two days, more or less back-to-back. I had decent attendance for all my sessions and had many of the same folks staying for multiple sessions which is always a very good sign. I did talks on Java EE 7/Java EE 8, WebSocket, the Cargo Tracker Java EE Blue Prints, JavaScript + Java EE and NoSQL + Java EE. More details, including slide decks and code as well as my NFJS tour schedule, posted on my personal blog.

Wednesday Aug 13, 2014

Introducing DeltaSpike 1.0

It is disappointing to come across the occasional mindset that Java EE somehow limits you to using only what is in the standard and nothing more. This is really not the case now and never was. Java EE is intended to provide a stable, open, compatible and reliable core that the ecosystem can build upon without the risks of vendor lock-in or monopolies. The idea is to provide a seamless platform that just works for the vast majority of cases. The ecosystem on the other hand is free to innovate and extend much farther beyond the standard core, ideally to cover every reasonably conceivable use case. The standard can then draw from well understood, successful use cases and bring those back into the core. To this end, almost every Java EE API today is designed with extensibility in mind. In fact, extensibility through CDI and CDI portable extensions in particular was a core goal for Java EE 6.

DeltaSpike is one of the projects that demonstrates these principles in action. For those unaware, it is a consolidation of Seam 3, Apache CODI and a few smaller projects. It is a set of portable CDI extensions that provide useful features for Java EE applications. In fact, the DeltaSpike team has already been instrumental in standardizing some of the innovative changes in Java EE 7. The project just released version 1.0 and it is a great time to check it out if you haven't done so already. Veteran Java EE advocate Arun Gupta has an excellent write-up on DeltaSpike 1.0.

Here are just some of the things that are in DeltaSpike 1.0 right now:

  • Many Java EE 7 features that you can use in Java EE 6 such as @Transactional, @TransactionScoped, CDI support in bean validation/JSF converters, @ViewScoped in CDI and so on.
  • An excellent higher level abstraction for reducing boilerplate in JPA based repositories.
  • A simplified, pluggable security framework for Java EE.
  • Simple integration with Quartz 2.
  • Injecting common Servlet objects.
  • Many, many more...

A great place to start is actually the excellent DeltaSpike site. The project is almost entirely community driven, completely vendor-neutral  and very friendly to contributors. DeltaSpike was nominated for the Duke's Choice Awards this year - they certainly deserve to win.

Thursday Jul 17, 2014

Contexts and Dependency Injection for Java 2.0 (CDI 2.0)

CDI (Context and Dependency Injection) is a 'recent' specification. CDI 1.0 has been introduced in Java EE 6 and has been slightly revised (CDI 1.1) for Java EE 7. In just a few years, CDI has become a key technology for the Java EE platform. CDI is becoming increasingly important as different parts of the platform are leveraging CDI more and more (e.g. JTA 1.2 @Transactional, Beans Validation 1.1 method level validations, etc.). And it is expected that CDI adoption within Java EE will only continue to grow as, for example, some upcoming Java EE 8 specifications are considering leveraging CDI too (e.g. JMS 2.1). 

Red Hat, the CDI Specification Lead, has just submitted to the JCP a JSR proposal for CDI 2.0. CDI 2.0 would be a major evolution of the current CDI specification, with 2 main focus : Java SE support and modularity.
  • Java SE support : Define the behaviour of CDI in a pure Java SE environment. 
  • Modularity : Define a granular, modular CDI model to help other Java EE specifications to better integrate with it. This would also probably be useful when CDI will be used in a pure Java SE context.
CDI 2 will be targeted for inclusion in Java EE 8. The Java SE features of CDI 2.0 would work on Java SE 8. In terms ot timing, CDI 2.0 is aligned with the current Java EE 8 roadmap. The CDI 2.0 JSR proposal will soon be posted on the JCP site for a 2 weeks JSR review period, the JSR approval ballot should then follow. 

In the meantime, you can read the CDI 2.0 JSR proposal here and for some technical background on what CDI 2.0 might be, you should check Antoine Sabot Durand (CDI 2.0 Specification Lead) 'Forward CDI 2.0' piece.

Monday Jul 14, 2014

VRaptor 4: A CDI Based MVC Framework for Java EE

As you may know one of the surprising results of the Java EE 8 survey was the desire for an action oriented MVC framework for Java EE. What many folks may not be aware is that there are actually a few action oriented web framework solutions out there that are already very aligned with Java EE. One such solution that really stands out is VRaptor.

Built on top of CDI, it has some very interesting defaults geared towards ease-of-use/productivity. It also supports key Java EE APIs such as JPA and JTA. To build a bit more awareness for the web framework, key commiter Rodrigo Turini recently wrote an excellent article on InfoQ. It is a very well-written article that serves as a good getting started guide with the innovative framework. Rodrigo will also be talking about VRaptor 4 at JavaOne 2014.

Jersey MVC has also long provided a very similar action oriented solution based on top of JAX-RS. All of these solutions could certainly be used now and serve as valuable input to any future effort to standardize an action oriented web framework in Java EE.

Tuesday Apr 15, 2014

Asynchronous CDI Events?

CDI events are a very powerful feature that enable loose coupling in a very simple and type-safe way. One aspect of CDI events that surprises many folks is the fact that they are synchronous rather than asynchronous. The surprise is perhaps fairly natural as similar event systems are usually asynchronous. Piotr Nowicki explores the issue in a very well thought out post exploring the various options for making CDI events asynchronous using plain Java EE features such as EJB @Asynchronous, Singleton locks and JMS. Exploring this issue further is probably very timely with the gradual rise of node.js/Reactive Programming.

Very encouragingly CDI 2 specification lead Antoine Sabot-Durand himself mentioned asynchronous CDI events as a possibility in his personal CDI 2 wish list. He suggests adding an asynchronous flag to the @Observes annotation. A possible downside to this is that the consumer rather than the producer makes the decision to go asynchronous. Another possibility is putting the asynchronous marker on the producer possibly using the type annotations facility introduced in Java SE 8:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
public class EventProducer {
 
@Inject Event event;
 
public void doSomething() {
MyEvent e = new @Async MyEvent();
e.data = "This is a test event";
e.eventTime = new Date();
event.fire(e);
}
}
 
public class EventConsumer {
 
public void afterMyEvent(@Observes MyEvent event) {
// .. Insert event logic here
}
}
view raw CdiAsyncEvents.java hosted with ❤ by GitHub

What do you think about the issue and the possibilities? This is the time to sound off as the horizons for CDI 2 are emerging.