Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [udig-devel] parentClassloader parameter
On 29/04/2010, at 6:43 PM, Ugo Taddei wrote:

Hi,

first things first, the http://udig.refractions.net/tutorials/SDKQuickstart.pdf has a typo on page 15. It says:

-Dosgi.parentClassload=ext

but it should read

-Dosgi.parentClassloader=ext

As shown on the screenshot.

Eeek! 

now to the question :-)

Why do I need this? I suspect it's to do with the way geotools loads JAI (or at least I vaguely remember something like that).

Sort of; the actual setting asks Eclipse to include the "boot classpath" in its parent classloader. So for each classloader it creates; the classloader includes JRE classes; and JRE extensions.  There are some more options described here:

osgi.frameworkParentClassloader
the classloader type to use as the parent classloader for the the Framework. The valid types are the following:
  • app - the application classloader.
  • boot - the boot classloader.
  • ext - the extension classloader.
  • current - the classloader used to load the equinox launcher.

Is there a way to avoid this? For example, if I define my own plugin and include the jai jars?

An excellent question (sigh!). We need this to use the JAI - as baked into the JRE.
This is require to get hardware acceleration as I understand it. If using the pure java JAI jars from your own plugin are not going to be able to reach out and use the DLLs or SO files.
- We tried including the files in a platform specific plugin (similar to how SWT is shipped) but you will need to search the archive or ask Jesse to find how that worked out.
- to try in pure java mode
-- you could remove the "excludes" in the refresh.xml script and add them to net.refractions.udig.libs - just to see if it works
-- you can try bundling them up in your own plugin; and asking net.refractions.udig.libs to depend on that plugin and see if it will run in pure java mode

But I would not expect native implementation to work with out more effort.

Ideas: One thing to do is to check how the Eclipse JOGL or Eclipse Java3D integration is done by other projects and see if we can learn from there experience.



Otherwise one is forced to release a complete JRE along with the product, which may be an advantage on some occasions, but not always.

Agreed. One alternative is to ask users to install JAI / ImageIO (and ImageIO-ext) into their system Java; or indeed have your installer download + install for them only if neeeded

Thoughts? Hints? Tips?

Thanks in advance,

Please report back; I would love to here your experience.

There is one added complication (or tip?). I see a number of JAI plugins already included in uDig; and it looks like it is willing to install a pure Java form of JAI into the JRE itself? We would need to talk to Jesse for details.

Jody

Back to the top