Class loading issues can happen in complex execution environments. Situation gets worst when there are different versions of the same library “loaded” and we are not sure which our application is picking up.
To help debugging this issue, we could check at runtime which version of the library is loaded with the our application.
A code like the following can help:
// Example using HTMLEmail from Apache Commons Email
Class theClass = HtmlEmail.class;
// Find the path of the compiled class
String classPath = theClass.getResource(theClass.getSimpleName() + ".class").toString();
System.out.println("Class: " + classPath);
// Find the path of the lib which includes the class
String libPath = classPath.substring(0, classPath.lastIndexOf("!"));
System.out.println("Lib: " + libPath);
// Find the path of the file inside the lib jar
String filePath = libPath + "!/META-INF/MANIFEST.MF";
System.out.println("File: " + filePath);
// We look at the manifest file, getting two attributes out of it
Manifest manifest = new Manifest(new URL(filePath).openStream());
Attributes attr = manifest.getMainAttributes();
System.out.println("Manifest-Version: " + attr.getValue("Manifest-Version"));
System.out.println("Implementation-Version: " + attr.getValue("Implementation-Version"));
The above code shows how to find jar file path and how to read the contents of a file (it is usually the Manifest) to read some info from it.
Oracle has released new Java 7 CPU (see meaning here) release: 7u25.
The release contains, in addition to usual security bug fixes, several changes that are also targeted to improve security.
The complete list of changes is here but let me remark the most important changes:
several changes on signed jar management including the check, before execution, that the certificate is valid (not revoked). The check can delay applet/application startup.
new attributes on JAR manifest file (permissions, to control jar execution authorizations, and codebase,to control who is using the JAR) has been introduced to let JAR author to better control JAR usage.
Java Runtime Environment (JRE) and Java Development Kit (JDK) version numbers follow a strict policy that Oracle has changed few months ago.
Knowing the rules behind the version numbers let us understand which are the benefits and the risks to migrate our environment to newest versions.
First of all, two Oracle definitions:
Limited Edition : release that includes new functionalities and/or bug fixes not related to security problems. Limited Edition releases have always even numbers.
Critical Path Update (CPU): release that includes only security bug fixes. No new functionality. CPU releases have always odd numbers.
So JRE/JDK 7 release 11 (in short 7u11 where u = update) is a CPU release while JRE/JDK 6 release 38 (6u38) has introduced new functionality because it is a Limited Edition.
In general it’s worth to migrate to a new CPU update (to secure our application) as soon it is available. Limited Edition releases can (should) be tested with more time before adoption.
Since last December, Oracle release plan was quite stable but in the last months a significant amount of security vulnerabilities have been discovered and fixed. The traditional numbering scheme needed to be updated: more odd numbers were needed.
So for the future, the numbering scheme is the following:
Limited Edition: use 20 as numbering step (from 20 to 40 to 60..) instead of 2
CPU: use 5 as numbering step (+1 if final number is even) like : 45 (first CPU after 40), 51 and 55.
The odd numbers not used (41, 43, 47.. in the above example) will be used, if necessary, for urgent security fixes.