Java 6 and SwingUtilities2

tags:

java
swing

views:

377

answers:

+2 Q:

Java 6 and SwingUtilities2

There is component within the application that uses com.sun.java.swing.SwingUtilities2 Now I understand that this class shouldn't be used, but it's a component within the system that uses it.

Therefore since it's no longer available in Java 6 I get a NoClassDefFoundError. How can I get around this issue without having to upgrade the component as I don't yet know if that's an option.

+1 A:

Da-dum! This is precisely why you should pay attention to those pesky warnings admonishing you not to rely upon internals of the JVM!

Rob 2009-10-19 20:30:52

But do you have a solution?

Stephane Grenier 2009-10-19 20:33:27

@Rob you assume that @Stephane made the problem he has to support. How do you solve the problem if you had to fix the issue?

reccles 2009-10-19 20:49:01

It's actually in a component that was purchased to include in the software. The component, since it's proprietary, is obfuscated. I also had no idea (nor how could you even) know it was using this class.

Stephane Grenier 2009-10-19 21:13:31

Even obfuscated you should be able to see what the code is using. For instance using `strings` on the class files. Not necessarily an interesting thing to do though.

Tom Hawtin - tackline 2009-10-19 21:59:05

+3 A:

If you have absolutely no other choice, then you should figure out exactly what it was that the class is using from SwingUtilities2, and then make proxies for that functionality in your own SwingUtilities2. You can then stick it in your own com.sun.java.swing package, which will overlap with the original one, and if the same class loader that loads your component is also aware of SwingUtilities2, then the one will see the other and your application will work.

Depending on what the component is, and what it used out of SwingUtilities2, this could be significantly harder than upgrading it or even rewriting it.

jprete 2009-10-19 20:38:11

I agree. Do you have any idea if the source is available anywhere. I understand it's not open source, but someone must have created some kind of class to replace it...

Stephane Grenier 2009-10-19 20:44:18

Other than just decompiling it.

Stephane Grenier 2009-10-19 20:45:18

http://www.google.com/search?q=SwingUtilities2.java

Sam Barnum 2009-10-19 21:03:07

It looks like they just changed the package name to sun.swing

Sam Barnum 2009-10-19 21:04:06

In regards to googling it, I did (well before asking here). The issue is that there are several different "versions" of the same code. So which is right? And more importantly, how well do you trust them...

Stephane Grenier 2009-10-19 21:10:54

That's what I got too. The problem is that there is some code in an obfuscated jar that's the culprit. Which unfortunately means I don't have the luxury of just changing the code :(

Stephane Grenier 2009-10-19 21:11:47

Note that the `com.sun.` package could become sealed, the class might be reintroduced without the relevant method, or some other reason why it might break again at any moment.

Tom Hawtin - tackline 2009-10-19 22:01:06

Is there a copy in OpenJDK? If not the top hit on google has a Sun copyright at the top so it might be trustworthy. Either way you'd have to evaluate the code, whether it's worth using and the legalities of doing so.http://www.javaresearch.org/source/jdk150/com/sun/java/swing/SwingUtilities2.java.html

Spyder 2009-10-21 12:37:30

+1 A:

Just a though, I don't know if this would work.

Try pulling out the SwingUtilities2 class and put it in a patch jar, include this jar in your classpath. Hopefully this works until you can change the source.

reccles 2009-10-19 20:45:16

Unfortunately it doesn't quite work. There's a line ((Boolean)c.getClientProperty(AA_TEXT_PROPERTY_KEY)); that always returns null and therefore throws a nullpointerexception.

Stephane Grenier 2009-10-19 20:56:48

Edit the references inside the copied class to refer locally. I think the NP is because it is using the real 6 variables. Although it would be best to get the vender to rebuid a 6 . Some companies do this for quick fixes

reccles 2009-10-19 22:32:03

+1 A:

The only correct way (out of hacking) is to ask vendor to fix and rebuild this component to Java 6. The possible working way is copy sun.swing.SU2 to com.sun...SU2 and package it into separate jar (e.g. java6fix.jar) and try to run your application. It will be fine if you add this patch jar into jvm bootclasspath. The best patch should be to create own com.sun..SU2 and delegate all calls to sun.swing.SU2. And take a look for different version of component which support Java6 maybe also from different vendor. Also if the problem is only in the mentioned line ((Boolean)c.getClientProperty(AA_TEXT_PROPERTY_KEY)); then you may put your own client property for this component to prevent NPE. When you take this path you can just simply create your own com.sun...SU2.AA_TEXT_PROPERTY_KEY and call c.setClientProperty(AA_TEXT_PROPERTY_KEY, true) on this component. Also try to disable anti aliasing check on component if possible.

Rastislav Komara 2009-10-21 09:11:37

Although it's nice to say, I'm afraid this is an expensive route. The component was built in the JDK 5 error, so I can't fault them for not supporting JDK 6.

Stephane Grenier 2009-10-21 14:34:24

If not, take another path from my suggestions.

Rastislav Komara 2009-10-21 20:01:03

ansaurus

tags:

views:

answers:

Java 6 and SwingUtilities2

related questions