LINQ Revisited

One of the very first posts I made decried the usage of LINQ as just more inline SQL coding that leads to ugly, coupled code. Looks as though my prediction, based on at least this blog entry, was not far off.

Making your apps version available - using Apache Ant

One thing I prefer to do with the builds I manage and deploy to live servers and environments is to make sure that the build is able to self report what version and repository revision it was built from. My current place of work uses subversion as its source code management tool. Grabbing the subversion revision number for ant build on your local checkout of a repository is relatively straight forward - all you need is SVNKit. Here is what I do...

<target name="svnrevision" description="Retrieve svn info">
   <java classname="org.tmatesoft.svn.cli.svnversion.SVNVersion"
         outputproperty="svn.revision">
     <classpath>
       <fileset dir="${build.lib.dir}" />
     </classpath>
     <arg path="${basedir}" />
   </java>
 </target>

That ant target will nab the revision number and stuff it in a property named svn.revision for use later in the ant script. In the event that you are working on an exported code base that is not a local svn repo, your svn.revision property will have a value of "exported", thus keeping the build from breaking if you are building from an export or don't even have an svn client installed. All you need is the svnkit libraries for svnkit.jar and svnkit-cli.jar on your classpath (as I have done by placing them in the directory referenced by the ${build.lib.dir} property).

Once you have the revision number in a property, creating a version string for a properties file , for example, can be done with the propertyfile ant task:

<target name="versionproperties" depends="svnrevision">
  <propertyfile file="build/classes/version.properties" >
    <entry key="name" value="${project.name}" />
    <entry key="version" value="${project.version}" />
    <entry key="revision" value="${svn.revision}" />
  </propertyfile>
</target>

Which will create a property file at the root of your classpath (assuming that is what is in build/classes) that looks similar to the following:

#Sat Jan 10 06:44:37 EST 2009
version=1.5.1
revision=3827
name=your_project_name

This properties file can easily be slurped up by your app using Java's Properties class and referenced very easily by some servlet or some Swing component to easily provide version reporting.

JavaFX "+" operator works like it ought to

This morning I took off to the coffee shop with the intention of learning a bit of JavaFX. I have some free time this AM so I figure this would be a good chance to get started on the tutorials provided by Sun, which is also how I initially learned Java.

One thing I noticed right off the bat, after dinking around for no more than 10 minutes, is that Sun got usage of the "+" operator correct, in my opinion, unlike it did with java. In other words, I hate the fact that in java the "+" operator gets used for mathematical addition AND string concatenation. I dislike this for two (well documented) reasons:

1. String concatenation when performed in a loop, results in allocation of lots of unnecessary objects
2. It leads to unexpected results when concatenating numbers and Strings and the programmer did not think to use String.valueOf() or the toString() method of the wrapper class of a primitive.
   

For instance, take this snippet of java code:

public class Main {
  public static void main(String[] args) {
    String ten = "10";
    Integer five = 5;
    Integer two = 2;
    System.out.println(ten + five + two);
    System.out.println(two + five + ten);
  }
}

With the resultant output of:

1052
710

Because of the order of operations, both of those lines with println produce "correct" results, but probably not the expected results of a developer who would write such a line. Any java developer worth their salt will know not to do anything of the like... but that did not stop a senior developer at my employer, who has very strong kung-foo, from making that very mistake when he was tired and hurried.

The language spec writers for JavaFX script apparently got wise and corrected this. For instance, the following in JavaFX Script

function add(foo: String, bar: Integer) {
 var result = foo + bar;
 println("{foo} + {bar} = {result}");
}

results in the following compile time error

+ cannot be applied to strings. Use a string expression "{foo}{bar}"

The fact that JavaFX Script doesn't allow concatenation between a String and a non-String type unless you use an actual String expression such "{foo}{bar}", thus making the type conversion to a String explicit and not implicit, is a win, in my opinion.

Recursive Bash Function for `svn update`

I work with a pretty fair number of subversion repositories at my employer and am constantly updating each of them manually - which can be both time consuming when remembered at the time I do it, or potentially cause conflicts and be error prone if I forget to do it. So to save myself the trouble of forgetting I have written and crontab'ed this script:

#!/bin/bash
source ~/.bashrc

SVN_ROOT=~/svn

function svnUpOrTraverse {
  path=$1
  if [[ -d $path ]]
  then
    upOutput=$(svn up $path)
    if [[ $(echo $upOutput | grep 'Skipped') ]]
    then
      for d in $(find $path -maxdepth 1 | grep -v "$path\$")
      do
        svnUpOrTraverse $d
      done
   else
      echo "$path Updated":
      echo; 
    fi
  fi
}

svnUpOrTraverse $SVN_ROOT

Modular JVM good for server side Java?

While the hoopla over a modular Java VM distribution has been centered around benefits for the client side - resulting in a light download and a small footprint at runtime for mom and pops' computer at home, I personally have not heard of, nor considered myself, any benefits a modular JVM might contain for server side Java applications. That is until I came across this particular thread on the Java Posse's Google group.

To highlight, here are the bullet points from Neil Bartlett's excellent post on that thread on how a modular JVM could help Java on the server:

1. Could remove the concept and implementation of the classpath
2. Results in modules that are swappable and able to be updated at runtime
3. Provides modularity for security updates - for instance, there would be no need to pull down an update for the latest Swing fixes if your app does nothing but typical website delivery.
4. Allows modules to advance at their own pace - thus decoupling the modules from the platform itself.
   
   

To be honest, I find each of these to be VERY good reasons to support a modular JVM. The classpath is an old deprecated thing and having to fight classpath / classloader problems is a bit of a pain in the arse to me (especially given I recently spent an entire night working on such an issue in early December).

More important to me, however, are items #2 and #4. Seeing as how I work mostly with server side technologies (read: EE containers and service buses for SOA that are expected to have virtually %100 uptime), being able to, hypothetically speaking, allow my developers to use some updated package in what might be the latest and greatest Java (say JSR 310's new Date/Time API), for one portion of their app while sandboxing the rest of the app or other apps on the container so that they still use a preexisting package *and* without the cost of upgrading to the next major Java version along with potentially no need to restart the container, would be absolutely brilliant.

Of course, this is slightly pie in the sky thinking and I have not really considered the negatives... but one man can dream, can he not?