David R. Heffelfinger

Trying to keep an open mind in the Spring Vs Java EE Debacle

One common criticism of my Spring to Java EE Migration article series (see part 1, part 2, part 3 and part 4) is that the article uses an old version of Spring against a modern version of Java EE. There's a reason for that, since project using older versions of Spring are the most likely ones to be looking to migrate to a newer technology stack, be it a newer version of the Spring Framework, Java EE or something else.

Nevertheless, truth be told, I've been focusing on Java EE projects for the last few years, and the times I've used Spring have been when maintaining legacy applications that don't use modern versions of the Spring framework.

Trying to keep an open mind, I bought Just Spring by Madhusudhan Konda for my Kindle Fire. The book uses Spring 3.0, versus Spring 2.5 in my article series. I decided to go for this book since it is a quick read (just over 60 pages), I didn't want to have to go through a 300+ behemoth of a book just to see if my opinion of Spring was outdated.

Quite frankly, the book did little to change my opinion in the Java EE vs Spring debacle. Although annotations get a brief mention in Konda's book, most of the examples still use XML configuration, and the seemingly endless XML needed to do anything nontrivial in Spring is one of the main reasons I'm not a fan of the framework.

To learn more about Java EE development, please check out my own books, Java EE 6 with GlassFish 3 Application Server and  Java EE 6 Development with NetBeans 7.

Posted at 08:38AM Apr 29, 2012 by David R. Heffelfinger in Java  |  Comments[5]

Spring to Java EE Migration Article, Part 4

The fourth and final part of my Spring to Java EE migration article series has been published.

Spring to Java EE Migration, Part 4 

Part 4 compares equivalent functionality in Java EE and Spring, covering topics such as MVC design pattern implementation, data access, transaction management, and dependency injection. 

Posted at 01:20PM Apr 28, 2012 by David R. Heffelfinger in Java  | 

Spring to Java EE Migration, Part 2

Part 2 of my Spring to Java EE migration series has been published. 

This part of the article shows off NetBeans Java EE capabilities, such as automatically generating JSF pages, JSF managed beans and Data Access Objects (DAO's) implemented as EJB session Beans. 

Posted at 06:57AM Dec 17, 2011 by David R. Heffelfinger in Java  |  Comments[1]

James Gosling, Father of Java, Leaves Google

A while back, there were news all over the blogosphere about James
Gosling, father of Java, leaving Oracle shortly after the database giant
bought Sun Microsystems.

Gosling was unemployed for a while, but in March 2011, he went to work for Google. Today he published a new blog entry, announcing that he left Google to join a company called Liquid Robotics, a company that makes an unmanned ocean vehicle called the Wave Glider.

I'm
surprised that Mr. Gosling decided to leave Google after less than six
months of employment; nevertheless I wish him the best of luck in his
new endeavors. I'm sure Liquid Robotics will benefit greatly from the
positive public relations of having the father of Java join their
company, and I'm sure they are hoping his tenure will be longer than the
one he had at Google.

Posted at 06:51PM Aug 31, 2011 by David R. Heffelfinger in Java  | 

Reports of Java's Demise Have Been Greatly Exaggerated

It seems like every other day a new article or blog post comes out declaring Java as a dead language. Every time I read one of these articles, I scratch my head in confusion. Are these people serious? If Java is so dead then why is there so much demand for it?

What does it mean for a language to be dead anyway? Is it that there is no demand for programmers with expertise in the language? If this is the case, then Java is definitely not dead since I routinely get emails out of the blue from companies looking for Java developers. I have been doing contract work since the late 1990's, and I move from one project to the next with ease, in most cases I have several offers before my current project is over. Therefore in this sense, Java is not dead.

Is a programming language dead if it's not evolving? If that's the case Java is certainly not dead.  JDK 7 is just around the corner, and there are so many Java libraries out there, which release new versions periodically. Java is still very much evolving and improving, therefore in this sense Java is definitely not dead.

I can't think of any other reason why a programming language may be considered "dead", other than lack of demand for expertise or lack of evolution, therefore I'm pretty certain that Java is very much alive and well.

Perhaps the bloggers and reporters declaring Java's demise are actually doing us Java developers a favor, the less Java developers out there, the less competition for Java projects, which would in turn increase the demand (and billing rate) of us Java programmers. Keep stating that Java is dead folks, me, my colleagues (and our bank accounts) will thank you.

Posted at 07:15PM Mar 16, 2011 by David R. Heffelfinger in Java  |  Comments[5]

Maven pom.xml configuration for Servlet 3.0

Good old servlets are getting a facelift in the next major version of Java EE after been somewhat neglected for so long.

One of the major changes of the new Servlet 3.0 API is that a web.xml is no longer required. Instead, servlets can be configured directly in the source code via annotations.

I wanted to try out this new feature, deploying in GlassFish 3 preview, which is the only Java EE 6 compliant application server at the moment.

As usual, I created a Maven project to test out this functionality, unfortunately, nobody has told Maven that a web.xml is no longer required. My build was failing with Maven complaining about the lack of a web.xml.

After some research, I found out how to configure Maven to avoid it complaining about this non issue.

Here is my pom.xml in it's entirety.

<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>net.ensode.glassfishbook</groupId>
  <artifactId>simpleapp</artifactId>
  <packaging>war</packaging>
  <version>1.0</version>
  <name>simpleapp</name>
  <url>http://maven.apache.org</url>
  <build>
    <finalName>simpleapp</finalName>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-war-plugin</artifactId>
        <version>2.1-beta-1</version>
        <configuration>
          <failOnMissingWebXml>false</failOnMissingWebXml>
        </configuration>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <configuration>
          <source>1.6</source>
          <target>1.6</target>
        </configuration>
      </plugin>
    </plugins>
  </build>
  <repositories>
    <repository>
      <id>java.net</id>
      <url>http://download.java.net/maven/2</url>
    </repository>
  </repositories>
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>javax</groupId>
      <artifactId>javaee-api</artifactId>
      <version>6.0-SNAPSHOT</version>
      <scope>compile</scope>
    </dependency>
  </dependencies>
</project>

Posted at 08:13PM Sep 22, 2009 by David R. Heffelfinger in Java  |  Comments[1]

JasperReports 3.5 For Java Developers Published

I'm proud to announce that the second edition of my JasperReports book, JasperReports 3.5 for Java Developers has been published.

The book has been updated to cover the latest features added to JasperReports since the first edition was published. Here is the table of contents:

Chapter 1: An Overview of JasperReports
Chapter 2: Adding Reporting Capabilities to our Java Applications
Chapter 3: Creating your First Report
Chapter 4: Creating Dynamic Reports from Databases
Chapter 5: Working with Other Datasources
Chapter 6: Report Layout and Design
Chapter 7: Adding Charts and Graphics to Reports
Chapter 8: Other JasperReports Features
Chapter 9: Exporting to Other Formats
Chapter 10: Graphical Report Design with iReport
Chapter 11: Integrating JasperReports with Other Frameworks

The full table of contents can be found here.

I also added JPA integration as part of the chapter on JasperReports integration with other frameworks.

An article based on the book can be found at the Packt Publishing web site, it covers the most common use for JasperReports, which is generating reports from database data.

Also, chapter 10, Graphical Report Design with iReport, is available for free, no registration required.

Posted at 06:08PM Aug 13, 2009 by David R. Heffelfinger in Java  | 

Java DB / Apache Derby: Insecure By Default

Both JDK 1.6 and GlassFish come bundled with Java DB, which is nothing but a rebranded Apache Derby RDBMS. If you have ever done anything with Derby, you know that a database can be created by simply by passing the create attribute with a value of true. For example, to create a database on a server called myserver.com, all that is needed is to use the following JDBC URL:

jdbc:derby://myserver.com:1527/mydb;user=foo;password=bar;create=true

The above JDBC URL will create a database called "mydb", and, in Derby/Java DB, the default schema matches the user name, so the above URL will create a schema called "foo" and set it as the default schema.

This is great in the sense that creating a database is very easy, but it is not so great in the sense that it allows anybody to create a database on the server and do whatever they want with it.

If this wasn't bad enough, by default passwords are ignored, therefore, with the default configuration in place, anybody can connect to the database as user "foo", for example, the following JDBC URL would connect you just fine:

 jdbc:derby://myserver.com:1527/mydb;user=foo;password=aaa

Notice that in this second JDBC URL, the password is different than the one we used when we created the database, it doesn't matter, in the default Derby configuration, the password is ignored, it is as if it didn't exist, therefore this URL would allow us to log in just fine.

Standalone Derby / Java DB only listens for connections from localhost, so in this case the default behavior is not too bad (there is still some security risk in a server with multiple users, however random people cannot connect through the network and create databases/log in to a database willy nilly).

However, GlassFish comes bundled with Java DB/Derby. When starting the database through GlassFish's asadmin utility:

asadmin start-database

The database by default listens accepts network connections. Unfortunately all other (lack of) security defaults stay in place, therefore with GlassFish's JavaDB's default configuration, random Joe's out there can connect to our databases without using a password, and can also create their own databases. This is a major security hole.

Luckily, Java DB/Derby can be easily configured to require valid user credentials, it is unfortunate that it is not configured this way by default. There are various ways to configure authentication in Derby/Java DB, it can be "hooked up" to an LDAP server, additionally, custom code can be written to handle authentication, and finally, a property file can be written set up authentication. The Derby Developer's Guide has all the details, in this entry, I'll just explain the simplest way, in case you are panicking because I just made you realized your database is exposed to the world.

The property file to create to enable authentication has to be called derby.properties it should look something like this:

derby.connection.requireAuthentication=true
derby.authentication.provider=BUILTIN

# Users definition
derby.user.someusername=password1
derby.user.john=doe

derby.connection.requireAuthentication=true tells Derby/Java DB that authentication is required.

derby.authentication.provider=BUILTIN sets up Derby to use its internal, built-in authentication mechanism.

After setting the above two properties, we need to add some users, they are added as shown in the above sample derby.properties file, properties preceeded by "derby.user." are understood to be users, the user name is the string immediately following "derby.user.", and the password is the value to the right of the equal sign. For example, if we wanted to add another user with a username of "joe", and a password of "secret", we would add the following line to derby.properties:

derby.user.joe=secret

Once we have created this file, we need to put it in $DERBY_HOME/bin if we are using the standalone Java DB/Derby or the Java DB version that is bundled with JDK 1.6. Java DB is placed under $JAVA_HOME/db in in Linux and under C:\Program Files\Sun\JavaDB in Windows.

If we are using the Java DB version that is included with GlassFish, then the derby.properties file needs to be placed under $GLASSFISH_HOME/databases, where $GLASSFISH_HOME is the directory where GlassFish is installed.

After copying the file to the appropriate location, the Java DB/Derby needs to be restarted for the changes to take effect.

Posted at 10:14PM Aug 07, 2009 by David R. Heffelfinger in Java  | 

A Slightly Biased Comparison Between Wicket and JSF

Recently I will start working on a project using Wicket. I used Wicket briefly in the past, I wrote an article about it and even worked as a technical reviewer for a book on Wicket, but I have never used it in production systems.

On the other hand, I have written two books that cover JSF, I also teach a class that covers JSF development, and I have worked on some projects that use JSF in production. As the author of two books that cover JSF, I have a vested interest in having JSF remain popular, therefore I am obviously somewhat biased, however I'll try to be as objective as possible when making this comparison.

All of my Wicket experience happened a few years ago, I haven't used it much in about three years, so for the past few days I've been refamiliarizing myself with this framework.

When comparing Wicket with plain vanilla JSF wicket is the clear winner. The fact that the markup in Wicket is plain HTML (with special wicket specific attributes) makes Wicket much more accessible, since no special knowledge of Wicket components is needed to come up with the markup. This allows web designers to do what they do best, design their user interfaces with their preferred tools such as Dreamweaver or other web design tools. The changes to the markup to make it work with Wicket are minimal, the wicket specific attributes need to be added to HTML tags that will be replaced at runtime with Wicket components. However, very few people use "vanilla" JSF. Most JSF developers use a component library such as ICEFaces or RichFaces. Furthermore, Facelets is a very popular view technology that can also use standard XHTML to develop JSF views. When component libraries and Facelets enter the picture, picking a winner is not so easy.

The fact that Wicket uses standard HTML for its markup may be an advantage or a disadvantage depending on your situation. If you are working with a professional web designer, then having straight HTML as markup is a real advantage. However, if your team consists primary of Java developers with little or no web design skills, then using a JSF component library that renders its pages using predefined CSS and Javascript, then in this case JSF may have the advantage.

Wicket reminds me a lot of working with Facelets, when using Facelets, we can develop pages that are plain XHTML, however we are not prohibited from using JSF specific tags. When previewing a Facelets page in the browser, the JSF specific tags are simply ignored.

Wicket also has some Wicket specific tags, however they are used to ignore parts of the HTML when it is rendered in the browser and other functionality, they are not really meant to be rendered. On the other hand, HTML tags in Wicket can have an wicket id corresponding to a component that renders HTML on the page, for example, a <span> tag could map to a custom Wicket component, therefore, a Wicket page may not preview exactly like it will be rendered when the application is deployed, which is the case with Facelets as well.

My impression on which one is better is, like in most cases, it depends. If a professional web designer is available, then Wicket may be the better choice, however if most of the development team are backend Java developers, then using JSF with Facelets plus a component library such as IceFaces or RichFaces may be a better choice.

Posted at 11:32AM Jun 07, 2009 by David R. Heffelfinger in Java  |  Comments[4]

Confessions of a Java Snob

For the past couple of months I've been working on porting a PHP application to Java EE using JSF, JPA and EJB 3 (in case you are wondering, yes, I've been using NetBeans and GlassFish).

I've never had any real exposure to PHP, so this is a new experience for me. I'm not sure if what I'm seeing is typical PHP code, but comparing this legacy system to the typical enterprise Java system shows some striking differences in architecture. When analyzing the PHP code, it became obvious to me that the mindset of PHP developers is very different from your typical Java developer.

In the Java world, we love our design patterns, we can't live without our DAO's and MVC. In PHP, it seems to be no big deal to mix presentation, business logic and data access in a single file.

Having worked with Java for over 13 years and Java EE/J2EE for about 10 years, I have to confess that the architecture (if you can call it that, more like "lack of architecture") seemed appalling to me. In the enterprise Java world, we've been conditioned to think that separation of concerns is a good thing.

Our presentation logic should contain presentation only, that way if in the future we want to switch say, from straight JSPs and servlets to JSF, the rest of the code shouldn't be affected. Additionally, if we want to convert our web application to a desktop application using Swing, it should be fairly straightforward to do so.

Data access logic should be done via Data Access Objects (DAO's), that way if today we are using straight JDBC and tomorrow we want to use an object relational mapping tool such as JPA or Hibernate, all we need to do is change the data access layer, the rest of the code should not be affected.

Communication between layers in our applications should be done via Value Objects, which shouldn't really change if we change our data access layer or presentation layer.

Controllers should manage flow from one page to another, again these should only be rewritten if we change our presentation layer. Most Java web application frameworks provide their own controllers, however they are not self sufficient, for example, in Struts we need to use Actions and in JSF we need to write managed beans, therefore changing the presentation layer would usually involve changing the controller as well.

After analyzing the code for the legacy system I got the impression that PHP is a language for amateurs and Java/J2EE/Java EE is for professional software engineers and architects. Am I right? Or I am just a Java snob? Feel free to set me straight.

Posted at 08:34AM May 23, 2009 by David R. Heffelfinger in Java  |  Comments[23]

Solving JasperReports Dependencies with Ivy

Lately, I've been doing some work with JasperReports. On my previous JasperReports projects, I've either used Maven, which automatically takes care of resolving dependencies, or I have simply downloaded the project's dependencies by hand.

Using Maven is nice, since it resolves dependencies, however, JasperReports comes with a series of useful ANT tasks to compile reports, preview them etc. I wanted access to these tasks and I also wanted dependency management.

There were a couple of ways I could achieve both. I know ANT targets can be called from Maven, this could be one approach. Also, there is a dependency manager for ANT called Ivy. I had briefly used Ivy before, I thought I would try this approach.

Ivy works by adding a series of custom ANT tasks, installing Ivy is very simple, all that needs to be done is to copy the Ivy jar file to ${ANT_HOME}/lib. Once Ivy is installed, custom Ivy tasks are available in our ANT build files.

Some additional configuration needs to be done in an Ivy specific XML file, named ivy.xml. In this file is where we actually specify our dependencies.

I set up my project to depend on JasperReports and tried to have Ivy automatically download all of JasperReports dependencies, unfortunately the build failed, complaining about some missing dependencies, specifically mondrian and commons-javaflow.

[ivy:retrieve] 		::::::::::::::::::::::::::::::::::::::::::::::
[ivy:retrieve] 		::          UNRESOLVED DEPENDENCIES         ::
[ivy:retrieve] 		::::::::::::::::::::::::::::::::::::::::::::::
[ivy:retrieve] 		:: commons-javaflow#commons-javaflow;20060411: not found
[ivy:retrieve] 		:: mondrian#mondrian;2.3.2.8944: not found
[ivy:retrieve] 		::::::::::::::::::::::::::::::::::::::::::::::
[ivy:retrieve] 
[ivy:retrieve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS

After some googling, some head scratching (and some hair pulling and banging on the table for good measure), I found out what was going on.

JasperReports has some optional dependencies declared in its pom.xml, these dependencies are not downloaded by default when using Maven, however Ivy attempts to download them. For some reason these dependencies do not exist in the repository, because of this the ANT build fails.

After some research, I found out the necessary modifications to ivy.xml to make the build succeed:

<ivy-module version="2.0">
    <info organisation="ensode" module="mymodule"/>   
    <dependencies>
        <dependency org="jasperreports" name="jasperreports" rev="3.1.2" conf="*->default"/>
    </dependencies>
</ivy-module>

What I had to do was to  use the conf attribute of the <dependency> tag to specify that I wanted that configuration for this particular dependency. The *-> default means that all your module configurations depend on the 'default' configuration of JasperReports, as explained by Xavier Hanin in this message of the Ivy users mailing list.

After making this change, Ivy was able to successfully download all JasperReports dependencies.

[ivy:retrieve]     commons-beanutils#commons-beanutils;1.8.0 by [commons-beanutils#commons-beanutils;1.7.0] in [runtime]
    ---------------------------------------------------------------------
    |                  |            modules            ||   artifacts   |
    |       conf       | number| search|dwnlded|evicted|| number|dwnlded|
    ---------------------------------------------------------------------
    |      runtime     |   14  |   12  |   12  |   2   ||   11  |   11  |
    ---------------------------------------------------------------------

I figured I would document this procedure in case others are having similar issues.

Posted at 11:04PM Feb 26, 2009 by David R. Heffelfinger in Java  | 

Common JPA Questions

1. How can I have a composite primary key in JPA?
   
   There are several ways to do it, this page explains them.
   
   
2. How can I prevent users from overwriting each other's changes to the database?
   
   Use the @Version annotation.
   
   
3. Is there a way to do bulk updates and/or deletes with the Java Persistence Query Language (JPQL)?
   
   Yes.
   
   

Posted at 01:30PM Feb 21, 2009 by David R. Heffelfinger in Java  | 

Upgraded to Roller 4.0.1

Since I just upgraded JavaDB, I figured this was a good time to upgrade to the latest version of roller as well. I was using roller 4.0, which is fairly up to date, but I figured it wouldn't hurt to upgrade to the latest, 4.0.1.

I simply downloaded roller 4.0.1, created a war file from the roller directory and deployed it to GlassFish, but for some reason the upgrade didn't go smoothly, I kept getting a "Roller Weblogger has not been bootstrapped yet" error.

I tried various ways of deploying, using asadmin, copying the war file to the autodeploy folder, etc, but I kept getting the same error. I restarted GlassFish several times, I restarted the database (JavaDB/Derby) several times, nothing seemed to solve the problem.

I then decided to reinstall roller 4.0 (thank goodness I made a backup), and it came back up successfully. After doing this, I then redeployed roller 4.0.1 using a different temporary context root, and this time, it installed successfully, asking me to upgrade the database. I did upgrade the database (the only thing that needs to be done when going from roller 4.0 to roller 4.0.1 is change the version number), and I had both roller 4.0 and 4.01 running in parallel with different context roots.

I then undeployed roller 4.0, and changed the context root of 4.0.1 to match the one I had in 4.0 (/roller), I am now in business.

Why wouldn't roller 4.0.1 just install over 4.0 is anyone's guess, however I was glad I was able to work around the issue.

Posted at 11:29AM Feb 21, 2009 by David R. Heffelfinger in Java  | 

Java EE 5 Reference Material

My Books

Two of my books cover Java EE 5, one focuses on GlassFish deployment, the other focuses on developing using NetBeans.

Java EE 5 Development using GlassFish Application Server - free chapter on JSF

Java EE 5 Development with NetBeans 6 - free chapter on JSF

Java EE 

The Java EE 5 Tutorial covers most aspects of Java EE 5. Examples can be downloaded as NetBeans projects.

JSF

JavaServer Faces is the standard component framework for Java EE 5.

JPA

The Java Persistence API is the standard Object Relational Mapping (ORM) tool for Java EE 5. It takes the best ideas from Hibernate and other ORM tools and incorporates them into the standard.

Posted at 12:29PM Feb 15, 2009 by David R. Heffelfinger in Java  | 

OpenPortal First Impressions

I recently got involved in a project that may need some portlet development. The project is a completely new application to be built from the ground up.

The customer has been using GlassFish as their application server and they are very pleased with it, therefore it just makes sense to continue using it.

The OpenPortal Portlet Container can be installed in GlassFish from its update tool, therefore it made sense to try it out.

Once installed, I also installed the NetBeans Portal Pack plugin from NetBeans 6.5 RC2, that can be installed directly from the NetBeans Plugin Manager.

The plugin makes deploying portlets to OpenPortal a breeze, as can be seen in this flash demo.

My main complaint? The default look and feel of the portlet is, let's just say, not the best looking.

As far as I can tell the only way to change the default look is to hack the CSS and JSPs by hand. I noticed the icons to minimize a portlet, maximize it, edit it, etc had transparent backgrounds, therefore it gave me some hope that they should be able to be used when simply changing the background color of the portlet bar. I made a simple modification to the CSS to test this, unfortulately it seems like some of the pink background creeped into the icons.

Also, as far as I can tell, modifying the available tabs to match our application requirements will involve some customizations of the JSPs included with OpenPortal, there is no tool to create or modify tabs as necessary.

Even with these disadvantages, I'm leaning towards using OpenPortal if we in fact turn out to need portlets for this project. The tight integration with GlassFish and NetBeans is a great advantage and I can live with having to do some CSS and JSP hacking to make it look the way we need it to look.

Posted at 10:04AM Nov 01, 2008 by David R. Heffelfinger in Java  |  Comments[3]