EclipseZone - Eclipse - a tale of two VMs (and many ...

The Rich Engineering Heritage Behind Dependency Injection

Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.

Java, the OLPC, and community responsibility

The "One Laptop Per Child" project has a great device ready to ship, but there's no Java on there. Let's think about working together to put Java on OLPC!

Replies: 51 - Pages: 4 [ 1 2 3 4 | Next ]

Reply 1. At 4:10 PM on May 2, 2006, Fred Grott wrote:: Re: Eclipse - a tale of two VMs (and many classloaders)
Excellent work, it got bookmarked to use a s a refernce..

You really should repurpose this article for inclusion at eclipse.org as it covers all the questions from beginner to advance..; Fred Grott, ShareMe jabber:fg82183@conference.javalobby.org(shareme) Official contributor to EclipseZone.com and supporter of JavaLobby.org.
Reply 2. At 6:09 PM on May 2, 2006, Genady Beryozkin wrote:: Re: Eclipse - a tale of two VMs (and many classloaders)
Regarding "why they use an exe and not a script for startup", I think another answer can be "because they can". Since the distribution is platform dependant anyway (unlike pure 100% Java programs) they are sure the exec will run on the target platform. As a bonus we get something to click on in the Explorer.
Also in the days of late 2001 when Eclipse 1.0 was released, it was the fastest way to display a splashscreen, because it took ages (compared to now) for a JVM to load and initialize.; Genady Beryozkin
Get the RMI Plugin for Eclipse
Reply 3. At 3:02 AM on May 3, 2006, Charles Martin wrote:: Re: Eclipse - a tale of two VMs (and many classloaders)
Maybe you can help me with a problem since you seem to be an expert here

I am trying to develop an RCP using Java 1.5 source but I need to deploy it to be compatable with java 1.4 (and with java web start)

I have been trying to use the Eclipse 3.2RC to do this and just can not seem to get it to do what I want.

Do you think this is possible without too much trouble or am I just wasting time here?

It's not critical...I just wanted to see if I can do it since I like the 1.5 generics so much.

Thanks

Charles
Reply 4. At 3:57 PM on May 3, 2006, Alex Blewitt wrote:: Re: Eclipse - a tale of two VMs (and many classloaders)
Actually, only the SWT component is platform dependent, and that's dynamically brought on board by the OSGi bundle loading mechanism (which is platform agnostic). The Java WebStartMain performs this loading using a Java launcher, for example.

Of course, getting the SWT up and initialised prior to the start of being able to display a splash screen may be one of the reasons that it's not done in Java. There are other reasons -- for a while, the icon showing up on the taskbar is something that's controlled by the name of the executable, and the WinXP style used to be controlled by a manifest file. Also, for looking for the process in ps or taskmgr is easier if it's not just 'java' as the process name.

That said, it doesn't always work well. I've repackaged Maclipse to work as a better (more Mac-like) launcher for Mac, since the current bundling doesn't work too well in that department.

But you're right; it's always been that way, and it's unlikely to change without good reason

Alex.
Reply 5. At 3:59 PM on May 3, 2006, Alex Blewitt wrote:: Re: Eclipse - a tale of two VMs (and many classloaders)
I had the same comments from the previous article on IAdaptable too

I'm happy for it to go up there, but right now don't have the time to do the conversion. I'll either get around to it one day, or someone else will ...

Alex.
Reply 6. At 4:01 PM on May 3, 2006, Alex Blewitt wrote:: Re: Eclipse - a tale of two VMs (and many classloaders)
Not sure. There are options in the compiler to generate source code compatible with 1.4 VMs. I think you can set this on a per-project preference or the global preferences. On the command line, they'd look like -source 1.5 -target 1.4.

Not sure if it's related to the article though

Alex.
Reply 7. At 10:46 PM on May 3, 2006, Charles Martin wrote:: Re: Eclipse - a tale of two VMs (and many classloaders)
thanks
Reply 8. At 3:59 PM on May 4, 2006, Charles Martin wrote:: Re: Eclipse - a tale of two VMs (and many classloaders)
Can you explain a little more about the boot up properties "osgi.instance.area" and "osgi.configuration.area" with regard to RCPs and the Java Web Start docs you mentioned

(1) What do these properties do and are they always necessary? Should they be found in the product config.ini file?

Some context...
I tried generating a simple Eclipse RCP (Hello World) using the Eclipse RCP wizard , and then I created a project and exported it. The project config.ini file looks like:

osgi.splashPath=platform:/base/plugins/newsRCP
eclipse.product=newsRCP.product
osgi.bundles=org.eclipse.equinox.common@2:start,org.eclipse.core.runtime@start,com.ibm.icu,newsRCP,org.eclipse.core.commands,org.eclipse.core.contenttype,org.eclipse.core.expressions,org.eclipse.core.jobs,org.eclipse.core.runtime.compatibility.auth,org.eclipse.core.runtime.compatibility.registry,org.eclipse.equinox.preferences,org.eclipse.equinox.registry,org.eclipse.help,org.eclipse.jface,org.eclipse.swt,org.eclipse.swt.win32.win32.x86,org.eclipse.ui,org.eclipse.ui.workbench
osgi.bundles.defaultStartLevel=4

(2) I tried following the examples referenced to deploy an RCP to java web start , and I could not get this to work at all. Any help here would be greatly appreciated
Reply 9. At 7:05 AM on May 6, 2006, Genady Beryozkin wrote:: Re: Eclipse - a tale of two VMs (and many classloaders)
There are other components that are platform dependant - see the number of fragments in the plugins directory (resources, OLE support in UI, update), but that's not the point.

I'm not sure that SWT is initialized before java is launched, but my point is just that once you have platform dependant distribution, you can use native APIs more freely.

Regarding task manager - I see a "java" process as running eclipse. Do you see anything different? What is your platform? (Mac?); Genady Beryozkin
Get the RMI Plugin for Eclipse
Reply 10. At 9:38 PM on May 13, 2006, Mark Crocker wrote:: Re: Eclipse - a tale of two VMs (and many classloaders)
> Actually, only the SWT component is platform
> dependent, and that's dynamically brought on board by
> the OSGi bundle loading mechanism (which is platform
> agnostic). The Java WebStartMain performs this
> loading using a Java launcher, for example.

> Alex.

So does that mean that my quest to dual boot Eclipse is not entirely in vain?

I have a bual boot, Windows 2000 / Ubuntu GNU/Linux system. All my data and cross-platform programs are on a common drive that both boots can see and modify. For something like jEdit, it works just fine. I can run the exact same installation from both Windows and Linux. Since drive space is limited on this machine having two, almost identical, but otherwise platform dependant installations of Eclipse is not really the way I want to go.

I tried simply running the startup.jar from the eclipse directory that was created by the Windows install and it didn't work. In your article, I noticed that there were -os and -ws switches, but I couldn't figure out how to use them. I tried all sorts of things like java -Dosgi.os=linux -Dosgi.ws=gnome -jar startup.jar , but had no luck.

Any suggestions on how to get Eclipse to run in both OS's of a dual boot system?

Now, if I could just figure out how to get my Windows JavaWebStart stuff to work in Ubuntu's JWS
Reply 11. At 5:31 AM on May 15, 2006, Alex Blewitt wrote:: Re: Eclipse - a tale of two VMs (and many classloaders)
How are you starting Eclipse? Are you just doing java -jar startup.jar? That probably won'twork. There are a bunch of other command line parameters (see the Eclipse runtime options) such as -application that allow you to set up which application is run (an Eclipse install can host multiple). Furthermore, as time progresses, there's more interaction with the startup.jar and shared memory (in particular, they support the splash screen and the list of plugins that are loaded). Running without the splash screen (using -noSplash) can disable that behaviour.

You can also merge the contents of the two installs; if you have both an 'eclipse' (for Linux) and 'eclipse.exe' (for Windows) in the Eclipse directory, you can use either of those to launch the Eclipse, without having to revert to the Java command line options. Note that if you don't have this, and you want to run via Java, you need to use -noSplash otherwise you'll probably get some kind of weird behaviour.

Alex.
Reply 12. At 5:35 AM on May 15, 2006, Alex Blewitt wrote:: Re: Eclipse - a tale of two VMs (and many classloaders)
The osgi.instance.area is the workspace location, and the osgi.configuration.area is the configuration location (the configuration/ directory under the application install area). There are a variety of combinations taht you can specify for these, but the default is ~/workspace and ECLIPSE_HOME/configuration respectively. The runtime options says whether they're mandatory or not, and in what combination; but in practice, you'll probably find you'll have both.

You can populate these manually (with -D) or using the config.ini file, or by specifying the workspace location with -data. They will default to the above values if they're not present.

You've got a lot of osgi.bundles there; more than you need. If you have the eclipse update configurator, you only need specify the one at the top of the chain as it resolves/installs the remaining plugins in the plugins directory.

Alex.
Reply 13. At 3:59 PM on May 19, 2006, Amber Beerends wrote:: Re: Eclipse - a tale of two VMs (and many classloaders)
I've been reading up on classloading and am still a bit confused as to the order in which the various resources are searched for a class. I believe that the parent classloader (which contains java.* classes) is first and after that is the Bundle-Classpath from the manifest.

But what's next? Fragments? Imported packages (specified in the Import-Package manifest header? Or dependent plug-ins (specified in the Require-Bundle manifest header)?

Thanks!

- amber
Reply 14. At 1:49 PM on May 22, 2006, Alex Blewitt wrote:: Re: Eclipse - a tale of two VMs (and many classloaders)
Have a look at the AbstractClassLoader in org.eclipse.osgi.framework.adapter.core and its children. You'll see the findResource() and findClass() are defined, and search through the classpath entries and fragment entries.

The classpath/fragment entries get built up via the buildClasspath() method, via the bundle classloader's initialize() method.

Hope that helps,

Alex.