Tuesday, October 30, 2012

Run jar file in a secure way

Often we download java tools/applications that are either from known sources or to try out their features.  Mostly they would come with either a bat/sh file to setup the path for the application and launch the jar.  Say you are logged in with an elevated user and what if the application you want to try just wipes out C drive!!

Always run the jar files (tweak the shell/batch scripts if required) to enable java security manager.  All that we need to do is launch jvm as java -Djava.security.manager -jar <jarFile>

This will use the default policy file that comes with JDK at JAVA_HOME/lib/security/java.policy, which is good enough.

Monday, October 29, 2012

Oracle jdbc driver changed since 9i

Came across this while going through the tomcat docs.  Since Oracle 9i release the jdbc driver class oracle.jdbc.driver.OracleDriver is deprecated and oracle.jdbc.OracleDriver is the new one to be used.  We use 10g and have been using the old driver since last 3 years.  Not sure if this will make any difference interms of performance though.  Will update once we have some stats.

Friday, October 26, 2012

Intro to OSGi

Came across the nice book by Neil Bartlett on OSGi while reading news on Jigsaw getting delayed and plans to include it in Java 9.

His book is so nice and I finished reading the intro, below are quick facts we should look to design for OSGi

Version Dependency
METAINF.MF could be used to declare the dependencies, but can not enforce version.

1. For example, suppose we determine somehow that a JAR has a dependency on Log4J. Which version of Log4J do we need to supply to make the JAR work?

2. Versions cause other problems. Suppose our application requires two libraries, A and B, and both of these libraries depend in turn upon a third library, C.  But they require different versions: library A requires version 1.2 or greater of C, but library B requires version 1.1 of C, and will not work with version 1.2!

Lack of Information Hiding Across JARs
Classes within a JAR need to have access to the classes in other packages of the same JAR. That means we must make those classes public, because that is the only access modifier which makes classes visible across package boundaries.  As a consequence, all those classes declared public are accessible to clients outside the JAR as well.  Therefore the whole JAR is effectively public API, even the parts that we would prefer to keep hidden.

I hope to continue and complete this book.