Skip to main content

Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Platform » Separation of Java and Eclipse Worlds(Frustrations with class loading differences in Java and Eclipse)
Separation of Java and Eclipse Worlds [message #512716] Sat, 06 February 2010 18:01 Go to next message
Jared is currently offline JaredFriend
Messages: 3
Registered: July 2009
Junior Member
I know the answers to all my questions deal with the lazy loading of plugins, but am wondering if there is something I am overlooking that addresses these issues:

Is there a way to use a plain java library/jar without exposing it through a plugin? Or an easier way to expose a jar without rebuilding the plain java library (which is also used outside the eclipse world) for those projects and then also rebuilding the Eclipse plugin?

Is there a method of making Java SPI work? In the past I've worked around this by using Eclipse extension points - but it feels more difficult than it should be.

In general I feel I've been burned many times by the way Eclipse class loading works - maybe I'm missing some fundamental details. Are there any good articles that address the differences between OSGI/Eclipse loading and regular java class loaders, or explain how eclipse loading works in detail?

Re: Separation of Java and Eclipse Worlds [message #513001 is a reply to message #512716] Mon, 08 February 2010 14:36 Go to previous message
Paul Webster is currently offline Paul WebsterFriend
Messages: 6859
Registered: July 2009
Location: Ottawa
Senior Member

There are a number of articles talking about OSGi classloading, and
there are probably another set that deal specifically with Eclipse and
classloading (extension points, etc).

The fundamental statement for OSGi is "bundles can only see other
bundles". You either have to require another bundle (promoted mostly be
eclipse) or import the other bundles packages (which it exports,
favoured in the OSGi world).

How to manage them depends on your scenario: Are you developing the 3rd
party jar and the eclipse plugin together? Are you simply consuming a
3rd party jar (org.apache.commons.lang-2.4.0.jar)?

If you want to work on a java project that should also be consumed as an
OSGi bundle, that's easy to set up in eclipse (SWT is like that, and is
usable from within eclipse both for a java app and as a plugin library).

If you want to consume a generic java project that doesn't use
reflection, then you have 2 choices ... either turn the jar into a
bundle (by adding the appropriate OSGi MANIFEST.MF entries) or create a
bundle that includes the jar in question and exports it appropriately.
Option 1 changes the 3rd party jar (although not much) and option 2 you
aren't modifying the 3rd party jar.

If you want to consume a java library that uses reflection, that's
harder ... it depends on a flat classpath, but OSGi provides modularity
imposed on the classpath. Then you have to pick the appropriate
workaround for the type of java library that it is (and it really
depends on what the java library is trying to do).

Extension points allow contributors to extend a bundles basic
functionality (and handle the classloading for you). In the OSGi world
I would imagine you get the same effect from implementing a common
interface and having contributors register their contributions as a
service (the whiteboard pattern is the common example I can think of).

I know this is more of a rambling description rather than a clear answer
to your question, but it really does depend on which OSGi vs Java
library problem you are trying to solve.


Paul Webster .platform.doc.isv/guide/workbench.htm

Previous Topic:FormEditor and dirty/commit protocol
Next Topic:perform URL resource loading inside IElementUpdater.updateElement(UIElement, Map)
Goto Forum:

Current Time: Wed Aug 10 21:37:24 GMT 2022

Powered by FUDForum. Page generated in 0.02390 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top