- Two Live Streaming Java Sessions from vJUG
- Minecraft Modding Course at Elementary School - Teach Java to Kids
- Nighthacking at JavaLand
- Java in Phantasialand
- Join JavaOne in Brazil
- Java 9 and Beyond
- New Java Champion: Tom Schindl
- EclipseCon NA 2015!
- New Java Champion: Peter Lawrey
- Announcing Java SE 8 Update 40
Wednesday Sep 24, 2014
Wednesday Sep 25, 2013
By Janice J. Heiss on Sep 25, 2013
Adam Bien, who is not only a Java Champion and JavaOne Rock Star, but
was named in 2010 as Oracle Magazine’s Java Developer of the Year, spoke
to an enthusiastic crowd where he addressed some core issues about Java
EE. He encouraged questions – “The more heretical or offensive the
better.” It was obvious that Bien loves to think about and code in Java.
He remarked, “The more I code the happier I am”. Spoken like a
hard-core Java developer!
First, he asked, “What is Java EE? Innovation vs. Standardization”? For Bien, Java EE is nothing but a release of co-existing APIs. Before Java EE, there was a mess with lots of application servers, with absolutely no chance of finding two application servers with similar APIs. Java EE resulted in a huge simplification. Now with Java EE 7 a wealth of are applications available. Java EE, insisted Bien, was never about innovation because building a standard precludes innovation. “Java EE will always lag behind,” he observed. “For instance, Hibernate will always have more features than JPA. Spring will always have more features than CDI. Java EE is the 80% that makes products work. It was never about innovation.”
He boiled down the whole point of Java EE: “What matters are small WARs – the smaller the WAR, the faster the build and deployment. The faster the build and deployment, the more productive you become,” he insisted. He explained that Java EE enables you to not put everything into the WAR and place as much as possible on the application server and less on the WAR. He explained that most of his WARs in Java EE 6 or Java EE 7 projects are very small
Bien asked, “Are EJBs bloated?” He explained that the question implies some voodoo stuff behind the scenes making EJBs bloated. He offered a means to answer this question.
He went on to answer a wealth of questions in a way that was thoughtful, incisive, witty and, at times, a bit provocative.
Here's some of the topics/issues (pulled directly from his slides) that Adam touched on in this fast-paced session:
*Do we need transactions?
*Is Dependency Injection Black Magic, VooDoo, or both?
*Is EJB pooling needed? Are EJBs bloated? What happens, if you violate the EJB programming restrictions?
*Why AOP didn't take off in Java EE?
*Stateless vs. Stateful programming model?
*HA without a Cluster?
*Are there any POJOs out there? What happens during deployment?
*Is Java EE faster than J2EE? Does JMS 2.0 scale and perform well? Is Java EE only suitable for the "big" enterprise?
*Is JSF the silver bullet? What is the deal with CORBA and RMI?
*How to unit test Java EE applications? Why we don't build a best of breed server from scratch?
This was a lively, entertaining and information-packed session. Just what you would expect from a pro developer as Adam Bien. I highly recommend viewing this session.
Adam Bien’s Blog
Check out Parleys.com where you can listen to the session in early October.
Tuesday Apr 24, 2012
By Janice J. Heiss on Apr 24, 2012
He concludes the series with these remarks:
“In this series of articles, we developed a Java EE version of Spring’s Pet Clinic application. We saw how the advanced tooling provided by NetBeans enables us to quickly develop a Java EE application…. Once we were done building the Java EE version of the application, we compared it with the Spring version, noting that the original version has several dependencies whereas the Java EE version has none, because it takes advantage of all the services provided by the Java EE application server.
Finally, we compared how to implement similar functionality such as MVC and DAO implementation, transaction management, and dependency injection with Spring and Java EE. In every case with Spring, some XML configuration needs to be done besides adding annotations to the code. Java EE relies on convention, and in most cases, no XML configuration is needed in order to implement these services.
Although newer versions of Spring rely a lot less on explicit XML configuration than earlier versions, there are always a few little lines here and there that we need to add to an XML configuration file in order to get most of the Spring annotations to work, violating the DRY (don’t repeat yourself) principle...
Additionally, Spring applications tend to have several dependencies, because they are meant to run in a “lightweight” Servlet container such as Tomcat or Jetty and these containers don’t provide all the required functionality. In contrast, Java EE applications are meant to be deployed in a full-blown Java EE 6 application server such as Oracle GlassFish Server...
For these reasons, I always recommend Java EE over Spring for enterprise application development.”
Have a look at the article here.
Friday Mar 30, 2012
By Janice J. Heiss on Mar 30, 2012
In a new article up on otn/java, Java EE expert David Heffelfinger continues his series exploring the relative strengths and weaknesses of Java EE and Spring. Here, he demonstrates how easy it is to develop the data layer of an application using Java EE, JPA, and the NetBeans IDE instead of the Spring Framework.
In the first two parts of the series, he generated a complete Java EE application by using JavaServer Faces (JSF) 2.0, Enterprise JavaBeans (EJB) 3.1, and Java Persistence API (JPA) 2.0 from Spring’s Pet Clinic MySQL schema, thus showing how easy it is to develop an application whose functionality equaled that of the Spring sample application.
In his new article, Heffelfinger tweaks the application to make it more user friendly.
From the article:
“The generated application displays primary keys on some of the pages, and these keys are surrogate primary keys—meaning that they have no business value and are used strictly as a unique identifier—so there is no reason why they should be visible to the user. In addition, we will modify some of the generated labels to make them more user-friendly.”
He concludes the article with a summary:
“The Java EE version of the application is not a straight port of the Spring version. For example, the Java EE version enables us to create, update, and delete veterinarians as well as veterinary specialties, whereas the Spring version of the application enables us only to view veterinarians and specialties. Additionally, the Spring version has a single page for managing/viewing owners, pets, and visits, whereas the Java EE version of the application has separate pages for each of these entities.
The other thing we should keep in mind is that we didn’t actually write a lot of the code and markup for the Java EE version of the application, because the bulk of it was generated by the NetBeans wizard.”
Have a look at the complete article here.
Friday Feb 03, 2012
By Janice J. Heiss on Feb 03, 2012
In a new tech article up on otn/java, adapted from a series of innovative blog postings, Downstream's Senior Java Architect Daniel Zwolenski develops ways to build apps in JavaFX 2.0 -- from Spring to controller injection to client servers. The article is derived from several blogs wherein he explores ways to create applications in JavaFX 2.0, building upon a direct port of Oracle Chief Client Java Architect Richard Bair’s FXML+Guice dependency injection example into Spring.
As Zwolenski says, “Many developers still believe that Spring is all about XML configuration files, but it has evolved a lot since the early days. I’m going to use Spring’s annotation-based configuration to create a pure Java example (i.e., zero Spring XML) that looks almost identical to the Guice one.”
Zwolenski is the creator of JFX Flow which he describes as, “a free, open source framework for developing rich, interactive and user friendly web-style GUIs for desktops using JavaFX (2.0+). JFX Flow combines the powerful feature set of JavaFX (styling, animations, FXML, etc.) with a simple ‘web flow’ style framework that is easy to use and that fosters clean architectural patterns, especially when developing Java EE applications. JFX Flow is currently in Alpha release and may still have some bugs. The core framework is usable however, and the API is quite stable.”
Read the complete article here.
Friday Dec 16, 2011
By Janice J. Heiss on Dec 16, 2011
Part 1 began with a Java EE rewrite of Spring's Pet Clinic sample application and developed the persistence layer of the application using Java Persistence API (JPA) 2.0, using NetBeans to generate most of the persistence layer from an existing database schema. Heffelfinger analyzed the generated code, which employed advanced JPA features.
In part 2, he continues this process by developing Enterprise JavaBeans (EJB) 3.1 session beans that act as Data Access Objects (DAOs), as well as JavaServer Faces (JSF) 2.0 managed beans and pages. Readers get to see the generated code in action and are given a look under the hood to see what’s going on.
Heffelfinger concludes Part 2 with a look ahead to Part 3:
“In the next installment of this series, we will modify the generated code to make it a bit more user friendly and we will compare the Java EE and Spring versions of the Pet Clinic application.”
Read the complete article here.
Wednesday Nov 02, 2011
By Janice J. Heiss on Nov 02, 2011
Heffelfinger observes that, “Every time I work on a Spring project, I start mumbling under my breath. I know I will have to go through long and convoluted XML files to determine what is going on with the project. I also know that my project will have approximately 10,000 dependencies and that the generated WAR file is going to be a monster.”
He contrasts this with Java EE, where most of the needed services are required by the application server, reducing the number of required dependencies, and typically Java EE provides configuration by exception, meaning there is little configuration necessary. When configuration is needed, it is usually done through annotations, which allows the developers to get the whole picture from the source code. Also, with Java EE, the advanced tooling from NetBeans is available.
Again, from the article itself:
“In this series of articles, we will rewrite the sample Pet Clinic application provided with Spring using Java EE. In this first article, I illustrate how we can quickly develop an application that has equivalent functionality to the Spring version by taking advantage of the excellent Java EE tooling provided by NetBeans. The Java EE version employs JavaServer Faces (JSF) for the user interface, Data Access Objects (DAOs) are implemented using Enterprise JavaBeans (EJB) 3.1 session beans, and data access is provided by Java Persistence API (JPA) 2.0.”
Read the article in full here.