Can I use runtime parameters to fix out of bad API calls in Java?

Question

Not sure if this is the right spot to ask but I'm having a Java issue. I have some Java code that works in Java 6 but not in Java 7, the error is:

java.lang.IllegalStateException: This function should be called while holding treeLock

Using Java6 works but a few of our external users are running Java 7. I figured out the error was caused by a call to validateTree(), which works in java6 but in Java7 we need to call validate() . When I test it locally it works.

Here's my problem, I started working at a big corporate and they won't let us make any changes to the code until its been very throughly looked at(my working change is going to take affect in April 2013) but until then our users are getting annoyed. I'm not the best with Java and was wondering if there was a way I could pass a runtime parameters to have this changed? or is there anything I can do without touching the code base?

I'm embrassed to ask this question since it could be solved easily by just implementing the fix but any ideas or direction would be very helpful.

Update: I'm ideally looking for something that I can get support to put in the java runtime parameter that would change all validateTree() references to validate().

Answer 1

Can I use runtime parameters to fix out of bad API calls in Java?

As a general rule, no.

In a specific case, you could look at the source code of the relevant classes Java 7 version of the class library to see if there is a backwards compatibility property.

---

Assuming that you can't find a fix, you are kind of stuck. I'd suggest:

• Recommend to your customers that they use Java 6 until a fix can be issued.
• Discuss with your management whether they can make an exception to their policy to allow this problem to be fixed urgently.

If neither of those works, then the real problem is between your customers and your management. You've done as much as you can do. Leave it to "the higher ups" deal with it.

---

You might be interested in my Answer to a related SO Question which touches on the issue of why they made this "breaking" change. My take is that the change is to force people to fix a class of insidious, hard-to-reproduce application bugs that cause strange UI behaviour. And that is a good thing ... in the long term.

Based on that, you could make a stronger case for issuing an out-of-band fix. The fix to replace validateTree() calls with validate() calls is actually a necessary fix for all Java platforms, not just for Java 7.

Answer 2

I have some Java code that works in Java 6 but not in Java 7, ..

One 'workaround' (I can see this being unpopular) is:

Deploy the applet using JNLP and use a J2SE version attribute of 1.6*. See Java Web Start - Runtime Versioning for details.

Note it will only work embedded in a Plug-In 2 JRE (a sub-set of 1.6 JREs) & even then, the client will likely receive warnings about 'uses an earlier JRE'. If the applet can be launched free-floating using JWS, it will work (supposedly) with around 1.4.2+.

The fix it to change the applet code to be compatible with both JREs, as outlined by kleopatra's 2nd comment & the answer of Stephen C.

Answer 3

The object returned by Component#getTreeLock() is used as a thread sychronization monitor. The documented thread-safety of certain methods was deprecated in the transition from version 6 to 7; an example is seen here. In general, verify that Swing GUI objects are constructed and manipulated only on the event dispatch thread. One of the approaches cited here may be helpful in automating the search for violations.

Answer 4

if (System.getProperty("java.version").startsWith("1.6")) {
...
} else{
...
}