Programming - 3

When using jEdit to edit files, be careful not to change any file you are working on (with svn commands, other editors, etcetera). By default it will immediately reload the file from disk, destroying your in-editor changes without prompting and with no way to recover your work.¹ There is a preference option:

• Utilities
  • Global Options...
    • jEdit
      • General
        • If open files are changed on disk: automatically reload

I definitely recommend changing this option to prompt if you ever work on your source files using revision control or multiple editors so an accidental svn revert, for example, does not destroy your work in an open jEdit window.

At least with the Hibernate/PostgreSQL combination (possibly other databases), you MUST encapsulate all queries, even just SELECT statements in transactions. If you do not, you will get hanging PostgreSQL processes like this:

postgres: <dbname> <dbname> <host> idle in transaction

These will eventually fill up your connection pool / exhaust your RAM / cause your application server to lock when trying to redeploy, etc. Not that I have experienced these personally...

Anyone who uses Netbeans when working with Javascript or CSS would be well advised to try out the Netbeans Javascript Editor. These modules offer both code completion and syntax highlighting for Javascript and CSS. There is one downside, it only works on standalone .js and .css files, not within jsp.

Using fragments combined with jspx (xml compliant jsp) is problematic. Standard jspf pieces stored in WEB-INF/jspfs can't use any elements not allowed in standard jspf or the application server will complain about those elements not being allowed (even when using <jsp:directive.include file="blah" />, which isn't supposed to pre-parse the file). If you set is-xml to true for jspfs in the web.xml, it fixes that error, but of course as it's a fragment and not a real xml file, it errors out saying such.

Workarounds include:

• keeping your fragments to jspf parsable elements


• building fully pre-parsable pieces that output the needed elements and using <jsp:include page="blah" /> (doesn't work if you want to do things like bean or variable declarations to communicate across elements)


• using another parsing engine and forget about fragments, like struts tiles (if using struts) or SiteMesh

Be warned when using java.util.Date and java.sql.Timestamp; these cannot be converted back and forth cleanly due to different precisions and the way they store dates internally. Unfortunately Java's date handling classes are pretty much well known to have seriously annoying issues. And be especially careful with java.util.Date vs java.sql.Date; the latter isn't 'actually' a timestamp like the former, so times will get truncated.

Few better ways exist to enjoy coding than hanging out outside, enjoying some fresh air, and firing up Netbeans.  Although it does make me crave one of those newer laptops with brighter screens.

I started using Netbean's Matisse for production applications, and have been astounded at how quickly I've been able to develop an application.  Between all I have learned about Java recently and the power this tool gives me to rapidly develop a Swing application, it is going to be tough for me to do web development until I find a similar tool.  I might have to give Sun's Creator tool a try, although now I am so used to Netbeans 5 I feel inclined to hold out for their updated version.

I have been working on a company-wide PDF search using Lucene and PDFBox.  Everything is being indexed nicely (tip, when debugging wierd search results with Lucene, try Luke sooner instead of later, chances are you need to tune your index options) and I have a pretty html page where users can do plain text searches of all our PDFs or by category.

As hundreds to thousands of results can be returned, I want an easy way for users to page through the results.  Traditionally with PHP or Perl I would parse http get options for the starting results and manually make some navigation code for this.  I am lazy though, so I started searching for Java libraries to help make this easier.  I hit the jackpot with the Display tag library.

With Hibernate's new EJB3 Annotation support, you can easily write classes, add annotations in code, and have Hibernate generate your database schemas for you without needing to manually build any xml config files or build your database schemas yourself.  This is really bleeding edge though, so it has some issues.  The Hibernate tools classes haven't caught up to the new feature set, for example, so when you try:

java -cp <classpaths> org.hibernate.tool.hbm2ddl.SchemaExport --config=hibernate.xml.cfg

To get the schema out so you can build your database, you get errors like:

org.hibernate.MappingException: An AnnotationConfiguration instance is required to use <blah>

Even when everything is properly setup and you have included the Hibernate Annotations jars in your classpath.  Fortunately, there is a simple workaround.

After having spent an hour trying to figure out why Netbeans 5.0 wasn't working with my Java 1.5 enum syntax, I stumbled upon the cause.  By default, Netbeans projects force the source version to Java 1.4.  If you want to use Java 1.5 constructs in Netbeans projects, be sure to de-select the "set source level to 1.4" checkbox when creating a new project, or set the source level to 1.5 in the sources preference for the project.

I have been trying out a configuration management package for a recent project, JFig.  First I built a wrapper class as I want to have a defined set of configuration values and cross platform handling of configuration file locations.  Then I built the functionality I needed into the rest of the application, fired things up, and everything seems to be working well.  But then I noticed, that's strange, the configuration file isn't getting updated.  Isn't JFig supposed to handle that for me?

The short version is no, not only does it not handle it for me, it doesn't provide any way to save configuration changes at all!

I am a big advocate of open source software, but every once in a while commercial software does something that illustrates to me why it will never be completely replaced by open source.  I came across this IEBlog entry at Microsoft recently.  For years printing from web browsers has been terrible; you almost never get anything like what the page looks like; elements fall off page borders, content doesn't resize to page width in a sane way, frames aren't rendered correctly if at all, etc.

I am finding an increasing amount of 'open source' products where the source code is under the GPL and the project is indeed technically open source, but the structure of their project denies both them and their clients any real benefit from this distribution model. This type of pseudo-open source project takes four forms, often in combination: No open user documentation, no open bug tracking system, inadequate or expensive developer documentation with a highly complicated codebase, and no access to the development work in progress. Each of these methods act to further destroy or prevent the development of a user community behind the product.

Whenever using struts html:text tags, be careful with the 'disabled' flag. It may appear that it just disables the field for input, and indeed it shows the value in the form in the grayed-out field. In reality though, it is going to send a null value when you submit the form regardless of what seems to be the case.

Use the 'readonly' flag instead if you want a non-null value to be submitted.

In the course of working on more J2EE web applications, I am starting to run into things that annoy me about Java. One of the biggest annoyances I run into when developing web applications in Java is the lack of support for String in case constructs. Apparently I am not alone.

I have been using Netbeans 4.1 for J2EE and Struts development for a while now. I like Netbean's out-of-the-box support for such development without the need to mess around getting plugins installed. I watched the new Netbeans 5.0 beta demo this evening and really liked what I saw. It takes about 30 minutes to watch and is definitely worth your time if you already use Netbeans or are not completely happy with what you are using now (which is pretty much always with most programmers I believe).