>> Hi folks, I have (once again) a problem with jai:
>>
>> java.lang.ClassCastException:
>> com.sun.media.jai.imageioimpl.ImageReadWriteSpi
>>     at
>> javax.media.jai.OperationRegistry.registerServices(OperationRegistry.java:2047)
>>
>>     at
>> javax.media.jai.ThreadSafeOperationRegistry.registerServices(ThreadSafeOperationRegistry.java:612)
>>
>>     at
>> javax.media.jai.OperationRegistry.initializeRegistry(OperationRegistry.java:365)
>>
>>     at javax.media.jai.JAI.<clinit>(JAI.java:560)
>>
>>
>> So what is the best practice?
> 
> The best practice is the harder to attain. You should have the JAI jars
> installed directly into your JDK, and don't have them anywhere in the
> classpath. Otherwise you're bound to issues as soon as a damned
> classloader does not play exactly by the Sun rules. Sigh...

Yes, but that gives me big troubles when I have to export a product. I
usually somehow have some reference in it and when not it fails because
there is some dependency. I agree with the fact that this is a problem
of mine and that I should know a bit better how exactly to do a clean
and proper export of an eclipse product, but things would be much easier
if the lars could be put in the classpath and the .so in the library path :)

> The issue is that JAI is packaged as an extension, and it's sealed.
> We still haven't tried hacking the official jars and remove the sealing
> markers, but that would be an interesting test too (that is, to check if
> this way JAI can be handled both in the JDK/JRE and in the classpath).

Oh, that is something I didn't know, the sealing thing I mean. I
remember there was also a download version for classpath use. Hmmm...
I'll have to check.

Thanks for the informations,
Ciao
Andrea





_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel

Reply via email to