| Osgi class loader bug? [message #466475] |
Thu, 19 April 2007 17:27  |
Eclipse User |
|
|
|
Originally posted by: valere.fedronic.ext.streamezzo.com
Hi,
I discovered this while trying to load an obfuscated lib.
If you create a java file with a field name *new.super* the osgi class
loader fails to load it (class format error) *BUT* the java class loader
does it fine...
Step to reproduce :
Create this class:
public class CLTest
{
String new_super;
}
--> modifie the generated .class file by replacing *new_super* with
*new.super*
--> In an another java class try to instanciate the CLTest (new CLTest()).
1°) if you launch as a java program it works.
2°) If you try to instantiate CLTest in your plugin's Activator you will
get this:
java.lang.ClassFormatError: Illegal field name "new.super" in class
com/*****/****/core/CLTest
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
[............]
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.load BundleActivator(AbstractBundle.java:136)
How is wrong ?
valere.
|
|
|
|
| Re: Osgi class loader bug? [message #466490 is a reply to message #466476] |
Fri, 20 April 2007 07:24  |
| Eclipse User |
|
|
|
Originally posted by: valere.fedronic.ext.streamezzo.com
>>VMs are not required to accept this as a valid name; therefore, nor
are classloaders.
I know that it is not a valid indentifier but the sun classLoader loads
the class!
I can inspect it with my debugger and see the field *new.super*.
So i just ask why the osgi class loader fails.
> Why would you hand-edit the class file like this?
It is just to show how to reproduce it. But in fact i have a third-party
library that is obfuscated (with a field renamed *new.super*), and i
cannot use it with osgi.
I just say that, if the sun classloader can load this class, the osgi
classloader should load it too.
valere.
Alex Blewitt wrote:
> Why would you hand-edit the class file like this? . is not a valid identifier in a simple name, so it's not a valid name for a field anyway. VMs are not required to accept this as a valid name; therefore, nor are classloaders.
>
> Alex.
|
|
|
|
| Re: Osgi class loader bug? [message #466507 is a reply to message #466503] |
Fri, 20 April 2007 09:13 |
| Eclipse User |
|
|
|
Originally posted by: valere.fedronic.ext.streamezzo.com
For those interested:
The lib is obfuscated with yGuard using this option :
<obfuscate ...>
<property name="language-conformity" value="illegal"/>
And the doc specifies that :
*illegal* will produce names, that will crash some tools but usually not
the jvm, but JBuilder7 in many occasions for example.
--> will crash some tools but *usually not* the jvm.
It crashes osgi..
valere.
Stefan Langer wrote:
> valere fedronic schrieb:
>> >>VMs are not required to accept this as a valid name; therefore, nor
>> are classloaders.
>>
>> I know that it is not a valid indentifier but the sun classLoader
>> loads the class!
>> I can inspect it with my debugger and see the field *new.super*.
>> So i just ask why the osgi class loader fails.
>>
>> > Why would you hand-edit the class file like this?
>>
>> It is just to show how to reproduce it. But in fact i have a
>> third-party library that is obfuscated (with a field renamed
>> *new.super*), and i cannot use it with osgi.
>>
>> I just say that, if the sun classloader can load this class, the osgi
>> classloader should load it too.
>>
> Actually no! This is a bug in the obfuscated code and should be reported
> against the third class lib.
> I would go as far as say that loading this class in the vm is a bug
> since new.super clearly violates the java spec.
>
> Regards
> Stefan
|
|
|
|
|
| Re: Osgi class loader bug? [message #466519 is a reply to message #466515] |
Fri, 20 April 2007 11:33 |
| Eclipse User |
|
|
|
Originally posted by: valere.fedronic.ext.streamezzo.com
Hi Bartlett,
I never suggest that it was an osgi problem (i put a question mark).
And my last post was to say that it was an yguard problem!
Propose to transform your code into an invalid code.... this is
obfuscating ;) !
I didn't want to upset anybody, and i am sorry if it is the case.
Thanks all for your responses.
valere.
Neil Bartlett wrote:
> Valere,
>
> I hope you're not still suggesting that this is an OSGi problem. The documentation for yGuard clearly states that the option you have used generates illegal bytecode. The fact that it works in the some of Sun's classloaders is pure chance - it might not work in older or newer versions of those same classloaders.
>
> This is a highly non-portable feature which should be avoided at all costs. Garbage in, garbage out.
>
> Neil
|
|
|
Powered by
FUDForum. Page generated in 0.04149 seconds
] 
Search
Help
Register
Login
Home
