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

Asked 10/10, 2012 at 13:54 Answered 10/10, 2012 at 18:49

Solved java swing applet jtree illegalstateexception

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().

Phalanstery answered 10/10, 2012 at 13:54 Comment(12)

For better help sooner, post an SSCCE that shows the behavior (preferably in an hybrid application/applet). – Spelt 10/10, 2012 at 14:4

In this case just tell the customers that it only works under Java 6 especially as your company has not tested under 7 - What other issues are there under Java 7. Major version upgrades need a major test – Teniacide 10/10, 2012 at 14:5

good track-down :-) No idea for a solution, though – Jaw 10/10, 2012 at 14:5

@AndrewThompson not needed - just look at the code of validateTree: they added the check for the treeLock, thus enforcing the precondition Synchronization should be provided by the method that calls this one – Jaw 10/10, 2012 at 14:7

Right now, support is telling clients to use Java7 but the problem is chrome and other systems automatically update users to the latest version so telling them to uninstall just ends up with the software being installed again a few weeks later. I feel bad for the users so tried to fix this on my own(I'm not responsible for this code), just want to help. Sorry I don't want to get in trouble by posting the actual code though. – Phalanstery 10/10, 2012 at 14:7

@Mark Or deploy the applet using JNLP and use a J2SE version attribute of 1.6*. See Java Web Start - Runtime Versioning for details. – Spelt 10/10, 2012 at 14:9

@Jaw Thanks for your (always erudite) elucidation. :) No SSCCE on this one, folks! – Spelt 10/10, 2012 at 14:11

you should try to trigger an emergency release: your company's code had been wrong (by not aquiring the treelock prior to calling validateTree) always, only now it's blatantly visible. – Jaw 10/10, 2012 at 14:11

If support is telling users to use Java 7 and the program does not work under Java 7 your company has a problem - this is what managers are paid to deal with – Teniacide 10/10, 2012 at 14:11

@Mark probably just a missing not, judging by the further explanation about automatic updates of the jdk :-) – Jaw 10/10, 2012 at 14:21

opps sorry..meant support is telling users to use java 6..sorry – Phalanstery 10/10, 2012 at 14:22

maybe there is more like in this thread, isn't about proper (some bugs were there???) changes in the Java7 APIs ??? – Finger 10/10, 2012 at 15:55

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.

Starlastarlene answered 10/10, 2012 at 14:16 Comment(2)

Yes it was a typo..thanks your answer was very helpful I couldn't find any backwards compatiability property, does that mean I'm totally out of luck or can I somehow pass a parameter that would replace all validateTree() to validate(). I don't think its possible but I'm thinking of something like a symbolic link in *nix – Phalanstery 10/10, 2012 at 15:54

Story of my life. Thanks for your tips though Stephen! – Phalanstery 11/10, 2012 at 16:4

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.

Spelt answered 10/10, 2012 at 14:16 Comment(1)

I think I suggested this but by default in the Java control panel java 6 and 7 are enabled and Java7 is taking over and giving the error(if java7 is unchecked then it works). This is the area where I realized I could change the behavior of java at runtime so I was looking of a way to send parameters. I think I need to wait for our corp to implement the fix. :-( – Phalanstery 10/10, 2012 at 15:59

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.

Spallation answered 10/10, 2012 at 18:49 Comment(1)

certainly true ... just that's not the problem here: the documentation didn't change - it always pushed the responsibility of getting the monitor to the calling code (of validateTree). With 7 it "only" added a precondition check for whatever reason – Jaw 11/10, 2012 at 7:45

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

Litchfield answered 10/10, 2012 at 16:15 Comment(1)

I did that and it works the problem is its going to take forever to push this code to production. In the interm I was trying to see if I could something on the client side(like using parameters or settings to overcome this). – Phalanstery 10/10, 2012 at 16:27

Recommended topics

Hot tags