David R. Heffelfinger

A new edition of my NetBeans book has recently been published by Packt Publishing. 

The book covers NetBeans 7's support for all major Java EE 6 APIs,
including JSF 2.0, EJB 3.1, JPA 2.0, CDI 1.0 and Servlets 3.0. The book
also covers NetBeans support for PrimeFaces, a very popular high quality
JSF 2.0 component library.

Development of web applications taking advantage of new Servlet 3.0 and JSF 2.0 features is covered. New
JSF 2.0 features such as XML-less configuration, project stages, new
JSF 2.0 conventions, resource directories, Facelets templating
(including predefined templates included with NetBeans) are covered as
well. The book also explains how NetBeans can help application
developers build JSF 2.0 components using markup only, without having to
develop any Java code.

The book explains how to develop sophisticated JSF 2.0 applications with PrimeFaces.

New EJB 3.1 features such as the new EJB timer service are covered.

The book also covers NetBeans 7 support for JPA 2.0, including the new
Criteria API, and how to use NetBeans to automatically generate JPA code
from existing databases; as well as generating complete Java EE CRUD
applications from an existing database schema.

Contexts and Dependency Injection (CDI) is covered as well, including coverage of CDI
named beans, scopes, CDI Qualifiers, Stereotypes and Interceptor
Binding Types are covered as well.

After finishing the book, readers not only will be well versed in the latest Java EE technologies,
but they will also be able to take advantage of NetBeans 7
functionality that allows developing Java EE applications in record
time.

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.

Over the last few weeks, we have been having a giveaway for my latest book, Java EE 6 with GlassFish Application Server.

The giveaway is now over, and we have randomly selected three winners.

Without further ado, here are the winners:

• nico
• Hannu
• Charles

Congratulations to all the winners!

Obtaining a copy of the book

If you would like a copy of the book and you are not one of our lucky winners, I encourage you to purchase it directly from Packt Publishing.

Thanks to everybody that participated and congratulations once again to our winners!

As some of you know, my latest book, Java EE 6 with GlassFish Application Server, was recently published by Packt Publishing.

Packt Publishing was kind enough to offer me three copies of the book to give away.

About the Book

The book covers all aspects of Java EE 6 development using GlassFish 3, some of the topics include:

• JavaServer Faces (JSF) 2.0
• Java Persistence API (JPA) 2.0
• Enterprise JavaBeans (EJB) 3.1
• Contexts and Dependency Injection (CDI) 1.0
• Java API for RESTful Web Services (JAX-RS) 1.1
• Java API for XML Web Services (JAX-WS) 2.1
• Servlet 3.0

How to Enter for a Chance to Win

All you have to do is answer one (or both) of the following questions in a comment below:

1. What would you like to learn from the book?
2. Why would you like to win a copy of the book?

If you prefer a certain book format and you are a USA or Europe resident, please note that in your comment as well, and we'll do our best to accommodate you (paperbacks are only available for USA and Europe residents).

Giveaway Details

The duration of this giveaway is 20 days. The giveaway ends on Monday, September 6^th, 2010 after which comments will be disabled on this post.

Three winners will be randomly selected to win a copy of  Java EE with GlassFish 3 application Server, authored by David Heffelfinger (yours truly) and published by Packt Publishing. Make sure you use a valid email address in the comments so that we can contact you if you win. Winners will be announced on Friday, September 10^th, 2010 and also contacted via email. Good luck!

Update: The giveaway is now over. Thanks to all that participated. Winners will be announced this Friday, September 10th.

We've all been there at some point or another. We just inherited a big pile of legacy Java code that we need to maintain. This code likely is using some big convoluted ANT script to be built. This being legacy code, it does not use a dependency manager like Ivy or the one included with Maven.

We, of course, want to be able to build using our favorite Java IDE, be it Eclipse, NetBeans or IntelliJ IDEA. Our Java IDE, of course, has no idea of what our project dependencies are, therefore our code is riddled with squiggly red lines due to missing dependencies all over. We are going to manually add dependencies to our project, oh joy. In many cases, these dependencies are scattered across multiple directories, we may have to inspect the contents of most of our JAR files to find many of our dependencies, especially those built in-house.

I was recently in this situation myself, to ease my pain, I came up with a Groovy script that recursively inspects every JAR file in the current directory and every subdirectory. It takes a single parameter, the name of the class to look for (case sensitive), then recursively checks every JAR file in the current directory all subdirectories. It's only requirement is that the "jar" executable be in the PATH, which should be the case for most Java programmers anyway.

Without further ado, here is the script. Enjoy

#!/usr/bin/env groovy

def cDir = new File(".");
def jarContents;
cDir.eachFileRecurse{file ->
  if (file.name =~ /.*\.jar$/)
  {
    jarContents = "jar tvf ${file}".execute().text;
    jarContents.eachLine{line ->
      if (line.contains(args[0])){
        print "*** found in ${file.canonicalPath}:";
        println line;
      }
    }
  }
}

Recently I needed to write a Groovy script to SFTP a file to a server. With a little bit of googling, I came to the conclusion that the easiest way to do that was to use AntBuilder ANT's scp task.

Since this script is going to be used by several people, I wanted to use groovy Grapes to pull the dependency automatically.

Turns out that AntBuilder doesn't see dependencies pulled with the Grab annotation, after a little bit of some more googling I found the solution. Instead of using the @Grab annotation, use the static grab() method of the Grape class to pull the dependencies, this allows us to specify that we need the rootLoader as the class loader, which AntBuilder can see.

Without further ado, here is the script in it's entirety for your copying and pasting pleasure:

#!/usr/bin/env groovy
import groovy.grape.Grape;

Grape.grab(group:"ant", module:"ant-jsch", version:"1.6.5", classLoader:this.class.classLoader.rootLoader)
Grape.grab(group:"com.jcraft", module:"jsch", version:"0.1.42", classLoader:this.class.classLoader.rootLoader)

def ant = new AntBuilder();
def pw;

print "password: ";
//the following line does not work under Cygwin, System.console() returns null
pw = System.console().readPassword();
def pwStr = new String(pw);
ant.scp(trust:'true',file:"/path/to/file.txt",
        todir:"user@host:/home/user",
        password:"${pwStr}",verbose:"true");

Lately I've been noticing some referrals from YouTube in my server logs. Curious about it, I looked into it and turns out there is not one, but two video tutorials explaining how to use my free online PDF unlock utility, both of them in Spanish.

I'm a long time BlackBerry user, however for a while I've been tempted by the Android platform. The openness of the platform seems very attractive to me.

The other day I went to the T-Mobile store to try the MyTouch 3G, unfortunately I wasn't very impressed with it. The problem I had was with the virtual keyboard, the wrong letters would show up when I pressed most keys. I looked around online to see if this was a common complaint about the device, and couldn't find much about it. Maybe the unit I tried at the T-Mobile store was defective. Nevertheless, I figured the MyTouch's virtual keyboard would be a recipe for frustration, so I stuck to my BlackBerry Bold for the time being.

Browsing around the web I learned that Sprint will get two new Android phones soon. The HTC Hero, which got a glowing review from ZDNet is coming out this Sunday, October 1st. Based on the review I got really tempted to get one.

While doing some more research I also found out that another Android phone, the Samsung Moment will be released on November 1st, three weeks after the Hero.

I've been researching both devices and at this moment I think I would prefer the Samsung, since it has a much faster processor (800 Mhz, vs 528 Mhz for the Hero) and a physical keyboard. It also seems to come with a more "Standard" Android OS, which I think would make it easier to upgrade the device with future versions of Android.

The Hero comes with "value added" software from HTC, which, although it may be very nice, it may make it harder to upgrade the OS in the device, if nothing else for fear of losing the HTC specific software. Other advantages of the Hero include slightly more memory (288 MB vs the 256 MB that the Moment has), and a 5 megapixel camera (vs the 3.2 megapixel that the Moment has). On the flip side, the Moment's camera has a flash but the Hero's doesn't.

Both seem like very nice devices, but the much faster processor and the physical keyboard of the Samsung Moment, plus the apparent ease of upgradability of the Hero tilt the scale in favor of the Samsung device, at least in my book.

I also looked at Sprint's plans and they seem to have some good ones. I like AT&T's rollover minutes which Sprint lacks, however Sprint's data plan includes GPS functionality, which AT&T charges extra for; and live streaming video through  Sprint TV, which as far as I know AT&T lacks. Also, with Sprint I can make and receive any domestic cell phone number from any carrier. Most of the calls I make and receive are to/from mobile phones anyway, so this is a big plus for me.

I'll be dropping by my local Sprint store in about three weeks to test the Samsung Moment out.

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>

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.

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.

Like I mentioned in my last post, I've been reading about Groovy lately. I'm finding Groovy very useful to automate small tedious tasks that I have to do in a regular basis.

For example, many times I have to zip up a directory, but there are some files or subdirectories I want to leave out. What I usually did was I would zip up the whole directory, then manually delete whatever I didn't want in the zip file. Alternatively, I would try to do it from the Linux command line, but I invariably would forget the syntax to do it, this would happen so often that I wrote a blog post explaining how to do it primarily so that I could refer to it myself.

ANT has a zip core task that can easily exclude files or directories from the resulting zip file, through Groovy's AntBuilder class, it is trivial to write Groovy scripts to invoke ANT tasks. It didn't take long to put two and two together, and write a simple Groovy script that would invoke the ANT zip task, specifying any unwanted files or directories.

Without further ado, here's the script:

#!/usr/bin/env groovy

def excludes="**/*.swp, somefile.txt, somedir/**"

def ant = new AntBuilder()

println "args = ${args}"

if (args.length > 0) {
 if (args[0].endsWith("/") || args[0].endsWith("\\")) {
    args[0] = args[0].substring(0, args[0].length() -1)
  }
  ant.zip(baseDir:args[0], destFile:args[0] + ".zip", excludes:excludes,
    update:true)
}
else {
  println "usage: ZipDir.groovy [dirName]"

}

Simply edit the value of the excludes variable to contain any valid comma-separated ANT patterns matching the files or directories you want to exclude from the zip file. Enjoy.

Lately I've been reading a bit about Groovy .Today I had to do a search and replace across several files, and decided to put my newly found Groovy knowledge to use. I wrote a simple script to search all files with a given extension, and search and replace a String inside each file.

I know this can be accomplished as a one liner, but I don't want to try and remember the syntax every time I need to do it. Also, there may be a "groovier" way to do it, being primarily a Java developer I don't really know (and quite frankly, I don't care that much, it works). Without further ado, here is the script for your copying and pasting pleasure:

#!/usr/bin/env groovy

def currentDir = new File(".");

def backupFile;
def fileText;

//Replace the contents of the list below with the 
//extensions to search for
def exts = [".txt", ".foo"]

//Replace the value of srcExp to a String or regular expression
//to search for.
def srcExp = "dummy"

//Replace the value of replaceText with the value new value to 
//replace srcExp
def replaceText = "awesome"

currentDir.eachFileRecurse(
  {file ->
    for (ext in exts){
      if (file.name.endsWith(ext)) {
        fileText = file.text;
        backupFile = new File(file.path + ".bak");
        backupFile.write(fileText);
        fileText = fileText.replaceAll(srcExp, replaceText)
        file.write(fileText);
      }
    }
  }
)

I could have made it a bit "fancier", taking command line parameters and what not, but this is just a simple script I solved to have a simple immediate problem I was having. With a couple of simple changes it can be adapted to search different file types, search and replace strings. Enjoy.

One of the features I really liked about NetBeans was it's Visual Web Pack (VWP) functionality, it allowed developing the GUI of a JSF application by simply dragging and dropping components from a palette into the page.

Although I have no trouble actually typing code or markup by hand, especially with a  good code editor such as the one provided by NetBeans, the convenience of VWP didn't stop with the visual drag and drop.

When creating a VWP page, a managed bean was created automatically, and automatically added to faces-config.xml. Although on the surface this sounds simple, it was a big time saver. Additionally, a database table could be dragged to some of the components, and a lot of "plumbing" code was automatically generated to display or update, as illustrated in this tutorial.

Visual Web Pack used the Woodstock JSF component library, in October 2008, Sun announced that it would be abandoning project Woodstock, but luckily provided a migration path to IceFaces, going as far as having IceFaces provide a VWP plugin for NetBeans. Unfortunately it looked like this was the beginning of the end of VWP.

I actually used the IceFaces VWP NetBeans plugin for a small project, although my initial impression of the NetBeans IceFaces plugin was less than favorable, after a while I started liking it. Lately, I've been using the NetBeans 6.7 release candidate, one of the first things I did after installing this version of NetBeans was to get the IceFaces NetBeans plugin for it. To my surprise and dismay, it does not provide Visual Web functionality.

It is really unfortunate that for whatever reason, IceFaces decided to drop support for visual web development, as far as I can tell, all their current NetBeans plugin does is provide a palette that introduces markup to JSF pages (mind you, this is not visual), and include the IceFaces libraries in any JSF project declared to use IceFaces.

Dragging and dropping into markup is not really that useful, we can simply type an opening angled bracket ("<") and hit ctrl+space to see all the JSF tags we can use, this is actually faster than moving the hand to the mouse, scroll the components in the palette up and down until we find the one we need, then drag it and drop it to the appropriate location on the page.

The one thing I will miss the most is the automated managed bean generation, in practice, I rarely used the feature where a database table could be visually linked to a JSF component since th generated code was a bit convoluted an unusual. I want to say it used JDBC, but this is not exactly accurate, it used a VWP specific concept of a dataprovider to link the database data to the component, I tend to use JPA in my Java EE projects, the fact that the database table drag and drop functionality did not generate JPA code kept me from using it in my project.

In any case, it looks like VWP is dead, long live VWP!

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.