Just got back from the April NEJUG meeting on JavaServer Faces, which didn’t go so smoothly. The projector lamp went out about 10 minutes into the presentation, which left David Geary with no access to his slides for about 1.5 hours. He gracefully answered questions instead of going through his presentation; following are excerpts of the questions & answers I found intriguing. Hopefully he’ll post his slides, although the OnJava.com newsletter mentioned that JSF is *the* hot topic for the next couple months so I’m sure there is going to be apt coverage elsewhere.

· David was one of the original developers of Tiles, which was highlighted in the Struts in Action book I’ve read. It didn’t originally float my boat, but I should go back and look into it a bit more. On Oreilly: Programming Jakarta Struts: Using Tiles, Part 1, Part 2, Part 3, Part 4.

· 1 sentence summary of JSF: It’s Struts++ with an event model and components.

· On the record Sun will say that JSF doesn’t replace Struts, off the record it does.

· Also off the record, David mentioned that JSF might be (or is) the most expensive JSR ever.

· Lots of people were curious about how closely tied JSF was to JSP. The short answer is that it’s not, David mentioned that you simply need to ‘… create a new renderer..’ for whatever platform you are targeting. He mentioned multiple times that JSF is platform independent and that you could output to XUL, Swing or Midlets. Which makes me wonder how hard it would be to write a JSF application that outputs to Flex or Laszlo. Swing & Midlets though? I could be wrong, but I think what it actually does it create *data* that these platforms can then use. I don’t think you can create an application in JSF and then write a J2ME renderer that creates a jar file that you can deploy to a phone. Tell me if I’m wrong on that though, because it would be remarkable otherwise.

· Couple questions about the similarities between Webforms & ASP.NET. Some differences I picked up:

a) the tags and UI components aren’t browser aware, they don’t target a specific browser platform, which is different from ASP.NET (which will output different HTML depending on which browser is requesting data).

b) by default form data is persisted to session scope (is this really true?) although I don’t see how this is an improvement over Struts (which has form persistence already if you use the Struts <html:form> tags)

· Question re: the complexity of JSF: easier or harder to learn than Struts? David replied that he thought that newbies to each would take longer to learn JSF. Struts users should have an easier time learning how to use it.

· Question re: migrating from Struts to JSF: Take a look at the document Craig McClanahan put together here, Struts-Faces integration library

· Question re: Tapestry & WebWork: Both were definitely looked at during the JSR process, turns out the Tapestry guy is local to Boston.

· JSF supports 2 types of events: action events (which are fired onclick of a button or a link) and change events (which are fired when the value of an input component changes). Both require a round trip to the server, change events require the user to click on a submit button OR the developer to write a JavaScript onchange event handler to then fire the form submission process. This is different than ASP.NET, where you can declare onchange events in your ASP.NET tags and the corresponding JavaScript is automatically generated for you. Whether this is good or bad depends on how much you like the generated code, but it definitely makes it easier for people who don’t know anything about JavaScript).

· Question re: debugging: is it easier than Struts? No.

· David mentioned a couple times that he thought that Tomcat sucked and that he really likes Resin. Note to self: check out Resin

· The WebSphere™ Boston Users Group will be doing a presentation entitled “WSAD, JSF, and More” on April 29th. More information here.

That’s it for now.

Update 04/15/2004: The presentation files are now available on the NEJUG site.

Seems like this new ‘feature’ of Tomcat 5 is buried in Google, bringing it to the top for anyone interested. If you port a servlet from Tomcat 4.x to Tomcat 5 and you use (pseudo) code like this:

public void doPost(HttpServletRequest req,HttpServletResponse res) {
   // some sort of logic
  if (something) {
   forward("/somewhere", req, res);
  } else {
   // do this
  }
   // continue on with the page
}

public void forward(String url, HttpServletRequest req, HttpServletResponse res)
throws IOException, ServletException {
  RequestDispatcher rd = req.getRequestDispatcher(url);
  rd.forward(req, res);
}

you’ll find that the servlet will throw a java.lang.IllegalStateException with the message: Cannot forward after response has been committed. This condition is easily fixed by adding a ‘return’ statement after you call the forward method. So instead, you’d have this:

  if (something) {
   forward("/somewhere", req, res);
   return;
  } else {
   // do this
  }
   // continue on with the page

I bet this one catches alot of people coming from a scripting background where it’s fine and dandy to do a response.redirect() (ASP) or a <cflocation> and then continue on as if nothing had happened.

Read it on jakarta.apache.org here.

If you live in the Boston area, check out the NEJUG meeting @ the Sun office in Burlington this Thursday. David Geary will be giving an talk on Java Server Faces. Registration & further information here, you can read more about his book (Core JavaServer Faces) here.

I’ll be commuting from the city out to Burlington, ping me if you need a ride.

James Turner, a committer on the Struts project and a Senior Editor at LinuxWorld Magazine, wrote an article for the magazine a couple days ago that caught the eye of a couple bloggers (Beattie, Colburn). There are a bunch of interesting comments on Russell’s blog in reference to his commens on the article. Notable among the comments:

… the difference between “Computer Science” and “Software Engineering” – the former being concerned with fundamental constructs and abstractions, the latter being concerned with putting them together into useful things — sort of like the distinction between Physics and Mechanical Engineering (or perhaps Civil Engineering), although much the way Computer Science is an abuse of the term Science, Software Engineering mistreats the term Engineering…. CS gives us things like Boyer-Moore search, Bloom filters, and LZ compression; SE gives us things like Apache and Google

— a link to an article that Joel Spolsky wrote back in 2001 (Don’t Let Architecture Astronauts Scare You)
— Carlos Perez chewed on the usuability of API’s for a bit (Even More Wisdom on Designing Usable APIs), which I found interesting because he talks about how Microsoft actually has done research into the usability of API’s (cognitive dimensions framework).

I think Russell misses the point; he brings up Bill Day using a PHP weblog solution as proof that Java is too hard. I use Moveable Type for my weblog, but that doesn’t mean I’d write a banking application in Perl or PHP. With that said, I completely agree with Mr. Turner’s assessment of the Bouncy Castle Crypto API. I tried to use it for the exact same thing that James did last week and I never did get it working. I bet we both would be using the Bouncy Castle API had they taken a couple hours to write a short and sweet introduction to the API.

Follow up to the last entry on Java & PGP, I found this article on Java World entitled “When Runtime.exec() won’t” that made a couple of great points. First, in reference to the 2 methods available to developers working with the Process class (waitFor() and exitValue()), he said:

If an external process has not yet completed, the exitValue() method will throw an IllegalThreadStateException; that’s why this program failed. While the documentation states this fact, why can’t this method wait until it can give a valid answer?

A more thorough look at the methods available in the Process class reveals a waitFor() method that does precisely that. In fact, waitFor() also returns the exit value, which means that you would not use exitValue() and waitFor() in conjunction with each other, but rather would choose one or the other. The only possible time you would use exitValue() instead of waitFor() would be when you don’t want your program to block waiting on an external process that may never complete. Instead of using the waitFor() method, I would prefer passing a boolean parameter called waitFor into the exitValue() method to determine whether or not the current thread should wait. A boolean would be more beneficial because exitValue() is a more appropriate name for this method, and it isn’t necessary for two methods to perform the same function under different conditions. Such simple condition discrimination is the domain of an input parameter.

Does the above mean that if you want to execute or invoke a long running external process using Java, you should simply call the exitValue() method on the process immediately after calling Runtime.exec() and then ignore the IllegalThreadStateException exception that gets thrown?

Second, he mentions:

One final pitfall to cover with Runtime.exec() is mistakenly assuming that exec() accepts any String that your command line (or shell) accepts. Runtime.exec() is much more limited and not cross-platform. This pitfall is caused by users attempting to use the exec() method to accept a single String as a command line would. The confusion may be due to the fact that command is the parameter name for the exec() method. Thus, the programmer incorrectly associates the parameter command with anything that he or she can type on a command line, instead of associating it with a single program and its arguments.

The call to the PGP executable I wrote a couple days ago does work, but it could be improved by breaking up the program (pgp.exe) from the arguments (-eatw c:\pgp6.5.8\tempfile.txt aaron.s.johnson@gmail.com) like this:

String[] args = {"c:\\pgp6.5.8\\pgp", "-eatw", "c:\\pgp6.5.8\\tempfile.txt", "aaron.s.johnson@gmail.com"};
Process process = rt.exec(args);


Other links:
Java World: When Runtime.exec() won’t
Mountain Storm:Java’s Runtime.exec() and External Applications

One of the Java projects I’m working on required that the application encrypted certain pieces of information (not files, but strings) using PGP, and from what I can tell, there aren’t a whole lot of libraries and/or examples out there. The one I saw mentioned most frequently was the Bouncy Castle Crypto API, but in the short time that I looked through the documentation and the examples (org.bouncycastle.openpgp.examples), I saw nothing that looked like it would help me. So I downloaded PGP 6.5.8 (the version we’ve standardized on at work) from pgpi.org and hacked away at a version that works from the command line. Here’s the result:

String information = "The random text information I want to encrypt.";
String filename = "tempfile.txt";
// path to where I have pgp installed
String directory = "c:\\pgp6.5.8\\";
// my pgp key
String pgpkey = "aaron.s.johnson@gmail.com";
// create a file and write the string to it
File outputfile = new File(directory + filename);
FileWriter out = new FileWriter(outputfile);
out.write(information.toCharArray());
out.close();
// get a runtime object
Runtime rt = Runtime.getRuntime();
// execute pgp from the command line
// e=encrypt a=ascii t=text file w=wipe the file
Process process = rt.exec(directory + "pgp -eatw " + directory + filename + " " + pgpkey);
// wait for the execution to end
process.waitFor();
// read the armored ASCII file
File inputfile = new File(directory + filename + ".asc");
BufferedReader isr = new BufferedReader(new FileReader(inputfile));
StringBuffer decrypted = new StringBuffer();
String line = "";
while ((line = isr.readLine()) != null) {
  decrypted.append(line + "\n");
}
// close the reader
isr.close();
inputfile.delete();
// print out the encrypted string for kicks
System.out.println(decrypted.toString());

A quick summary. The PGP executable assumes that you’re encrypting and decrypting files, so I first take the string that I want to encrypt and write it to a text file using the File and FileWriter classes. Then I use the Runtime class to execute PGP from the command line, which encrypts the file and deletes the original plain text unencrypted file that I just created. I call the waitFor() method on the Process to make sure that the execution is complete, and then I read in resulting armored ASCII file using the File, FileReader and BufferedReader classes. Finally, I delete the armored ASCII file. Obviously in production you’d want to use a unique name for the file so that you don’t overwrite or delete a file that another thread just created. Other than that, are there any issues that I missed?