About Mike Miller

Mike is a software developer who loves to learn how things work. A Java programmer who caught the Groovy & Grails itch and is always looking for opportunities to include them as part of the solution.

Minor Gotchas from migration to Java 7

After several years of pushing, we are finally starting to pull our application out of the dark ages  in terms of software levels and one of those steps is upgrading our Java version to Java 7. For the most part, this has been fairly painless, but there have been a couple surprises:

    • Test cases that had been running successfully for years started failing when we switched to Java 7.  It turns out that we had some test cases that depended on previous test cases within the same class.  This is bad on two fronts, 1) the test cases should each be independent and 2) the execution order of test cases within a test class is not guaranteed, although, up to now(before Java 7), the order was the order found in the source code.  I found this link that helped explain the inconsistent
       
      ordering I was seeing within Eclipse.  This is not a problem with Java 7 but rather with our test cases.   Just  something that cropped up when we started running with Java 7
    • Our Swing clients began throwing ClassCastExceptions, and this is code that has been in place for over 10 years, dating back to Java 1.4   Reading the javadocs helped explain the problem, but I decided to research a bit more to find out exactly why this was happening now.   We were adding entries to a TreeSet to hold forward and backward traversal keys for the FocusManager, putting KeyStroke objects into the TreeSet.   The javadoc clearly states that the objects put in the TreeSet (or TreeMap underneath) must be Comparable or you need to create the TreeSet with a Comparator for ordering the objects. We were doing neither,  and not getting exceptions.  Digging into the java source code,  I found that starting in Java 7, the TreeMap class has starting enforcing this ‘requirement’, where the earlier versions of the class had that code commented out, thus not really requiring the comparator.    The fix was easy, I created a KeyStrokeComparator and passed that to the TreeSet constructor.
    • I also noticed that our java jar signing had started logging a warning about the certificate not being valid.   Wanting to keep the build clean and not have these warnings, I did some searches and found several postings related to Java 7 and the removal of the MD2withRSA algorithm from the code signing certificates.   I worked with support from Verisign to help with the removal of that algorithm from our certificate chain and the warning went away!  Unfortunately, that was not the end of the code signing problems.
    • Next, our web start clients would no longer start successfully, instead throwing an exception with the all-too-familiar  ‘not all jars signed with the same certificate‘ error message frequently encountered by web start programs, at least during development!  I’ve written another blog post about how to help debug through this and figured it was just ‘one of the usual suspect jars’ that we have problems with, but nope, that wasn’t it.   Knowing that all this happened since the certificate was updated caused me to review all of our signed jars to look for clues.   All the jars had been signed with the same certificate, but the 3rd party jars were signed BEFORE the chain entry was remove, whereas our application code was signed as part of the build process, AFTER the certificate was changed.   This led me to believe that even though the jars were signed with the same certificate, that there must be some difference between the jars signed before and after the change to the certificate.

When jars are signed,  entries are generated in the MANIFEST.MF file inside the jar, one entry for each class in the jar.  These entries contain the name of the class along with some signing algorithm information and after reviewing the MANIFEST.MF files,  I found the difference.  The 3rd party jars signed before the change included a SHA1-Digest entry for each class but our jars signed from the current build contained entries with SHA-256-Digest.   Re-signing all of our 3rd party jars with the updated certificate resolved most of the problems.   We had a minor problem in our re-signing process, where we over-wrote the existing MANIFEST.MF with our own generated version and this caused problems for a couple of jars that contained additional service provider information in the manifest file.

All in a days work!  Just Happy to be current on the Java level. Next up, migrating to EJB3 and Hibernate 3 or 4.

Hope this helps!
 

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

One Response to "Minor Gotchas from migration to Java 7"

  1. mebigfatguy says:

    The first one is just due to a new version of junit, specifically junit 4.11

Leave a Reply


eight − 5 =



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close