Category Archives: java

Bash function to switch Java versions

setjava() {
	if [ "$1" = "-q" ]; then
                local quiet=true
                shift
        fi

	local jdk=~/Applications/Java/jdk1.$1
        if [ ! -d "${jdk}" ]; then
                echo Jdk not found: ${jdk}
                return 1
        fi
	export JAVA_HOME=${jdk}
        export PATH=${JAVA_HOME}/bin:${PATH}
        if [ -z "${quiet}" ]; then
                java -version
        fi
}

export -f setjava

I have symlinks for all major versions of Java so that in IntelliJ and the command line I can upgrade minor Java versions just by changing the symlink:

$ ls -la ~/Applications/Java/
total 20
drwxrwxr-x. 5 dan dan 4096 Mar 27 10:12 .
drwxrwxr-x. 8 dan dan 4096 Mar 27 10:13 ..
lrwxrwxrwx. 1 dan dan   11 Mar 27 10:12 jdk1.6 -> jdk1.6.0_45
drwxr-xr-x. 8 dan dan 4096 Mar 26  2013 jdk1.6.0_45
lrwxrwxrwx. 1 dan dan   11 Mar 18 13:55 jdk1.7 -> jdk1.7.0_51
drwxr-xr-x. 8 dan dan 4096 Dec 19 03:24 jdk1.7.0_51
lrwxrwxrwx. 1 dan dan    8 Mar 27 10:12 jdk1.8 -> jdk1.8.0
drwxr-xr-x. 8 dan dan 4096 Mar  4 11:18 jdk1.8.0

Then I can switch version by either just saying the major version:

$ setjava 8
java version "1.8.0"
Java(TM) SE Runtime Environment (build 1.8.0-b132)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode)

or I can be specific about minor version:

$ setjava 6.0_45
java version "1.6.0_45"
Java(TM) SE Runtime Environment (build 1.6.0_45-b06)
Java HotSpot(TM) 64-Bit Server VM (build 20.45-b01, mixed mode)

I’ve also started adding the following to my build and execution scripts so they can specify the Java version themselves:

type -t setjava > /dev/null && setjava -q 8 || if [ -n "${JAVA_HOME}" ]; then PATH=${JAVA_HOME}/bin:${PATH}; fi

Currently this is designed to be optional and will fallback to JAVA_HOME etc.

Error: Invalid or corrupt jarfile

I was creating a Jar via the Java API’s and I couldn’t get it to run my main class:

 $ java -jar foo.jar
Error: Invalid or corrupt jarfile foo.jar

Running it via the class path worked fine:

 $ java -cp foo.jar Bar
Hello world!

So now I knew it was something to do with the manifest file but it wasn’t being caused by

  • The 65535 file limit (See Zip64 and Java 7 ).
  • The 72 bytes limit per line
  • Missing newline at the end of the Main-Class (Displays “no main manifest attribute, in foo.jar”
  • A blank line before Main-Class (Displays “Error: An unexpected error occurred while trying to open file foo.jar”

So after scratching my head for a while I tried comparing a working jar with the failing jar:

$ unzip -lv foo.jar 
Archive:  foo.jar
 Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
--------  ------  ------- ---- ---------- ----- --------  ----
      75  Defl:N       75   0% 2014-02-17 16:01 b1eac370  META-INF/MANIFEST.MF
     825  Defl:N      464  44% 2014-02-17 16:01 942f187c  Working.class
$ unzip -lv foo.jar 
Archive:  foo.jar
 Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
--------  ------  ------- ---- ---------- ----- --------  ----
      75  Defl:N       75   0% 2014-02-17 16:01 b1eac370  /META-INF/MANIFEST.MF
     825  Defl:N      464  44% 2014-02-17 16:01 942f187c  Failing.class

So don’t prefix the META-INF folder with a slash! Also note it is case sensitive!

java.lang.ClassNotFoundException: org.apache.log4j.FileAppender

Hopefully this will stop someone from wasting a day of their life…
If you pass in the following when you start your Java application:

java -Dlog4j.configuration=file:///some/path/log4j.properties

And that file contains a class that is not on the class path

log4j.appender.myAppender=biz.minaret.log4j.DatedFileAppender
log4j.rootLogger=error, myAppender

Then due to the log4j static initialisers you will not see an error for the class in question but instead:

Caused by: java.lang.ClassNotFoundException: org.apache.log4j.FileAppender
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)

Unfortunately for me this was caused by a transitive dependency changing in Maven. Damn you Maven/Log4J