Thursday Mar 26, 2015
Monday Mar 16, 2015
By reza_rahman on Mar 16, 2015
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
By reza_rahman on Feb 23, 2015
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
By reza_rahman on Feb 02, 2015
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
By reza_rahman on Jan 23, 2015
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.
Another great GWT based Java web framework worth checking out that works with CDI and Java EE is Errai.
Wednesday Jan 21, 2015
By reza_rahman on Jan 21, 2015
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
By David Delabassee-Oracle on Jan 06, 2015
Monday Oct 27, 2014
By reza_rahman on Oct 27, 2014
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
By reza_rahman on Sep 11, 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
By reza_rahman on Aug 25, 2014
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
By reza_rahman on Aug 22, 2014
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.
Wednesday Aug 13, 2014
By reza_rahman on Aug 13, 2014
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
By David Delabassee-Oracle on Jul 17, 2014
- 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.
Monday Jul 14, 2014
By reza_rahman on Jul 14, 2014
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
By reza_rahman on Apr 15, 2014
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||
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.
Podcasts & Videos
- JavaOne CFP is Open - Your Invitation to Submit to the Java EE Track
- New book: "Web Development with Java and JSF"
- Forge Powered Java EE Rapid Application Development Comes to NetBeans!
- JMS 2.0 Revision A
- Java EE 8/Adopt-a-JSR Updates: Morocco JUG!
- Java EE Management API 2.0 (JSR 373) Spins Up
- Java EE Container Lifecycle
- Migrating a JSF Application from Spring to Java EE 7/CDI
- Java EE 7 Hands-on-Lab Updated for You to Use!
- Templating in the MVC JSR