Eclipse vs plugin.jar

[Tom Anderson]

Good day!

We're writing an applet. It does uses LiveConnect to talk to JavaScript on
the page. The classes for that - JSObject and friends - are in plugin.jar,
which can be found in the JRE lib directory.

We're developing using Eclipse. Eclipse has no idea about plugin.jar.

What's the right way to teach it?

We could put a copy of plugin.jar in our project. That's easy, but means
we're not using the installed version, which leaves us vulnerable to
version mismatch if Sun decides to make changes to this decade-old piece
of code.

We could add an external jar reference. That's also easy, and uses the
installed jar, but involves hardcoding the path to the JRE in the
metadata.

We could use a classpath variable for the JRE's location, and add an
external JAR reference relative to that, which uses the installed jar and
doesn't hardcode the location, but it means everyone has to add a new
variable to their workspace (there isn't a predefined one for JAVA_HOME
or JRE_HOME, annoyingly).

We could define a 'library', which is some sort of bundle of jars, which
has the disadvantages of all the above approaches, and none of the
advantages.

Any thoughts?

tom

 

[Daniele Futtorovic]

Good day!

We're writing an applet. It does uses LiveConnect to talk to JavaScript
on the page. The classes for that - JSObject and friends - are in
plugin.jar, which can be found in the JRE lib directory.

We're developing using Eclipse. Eclipse has no idea about plugin.jar.

What's the right way to teach it?

We could put a copy of plugin.jar in our project. That's easy, but means
we're not using the installed version, which leaves us vulnerable to
version mismatch if Sun decides to make changes to this decade-old piece
of code.

We could add an external jar reference. That's also easy, and uses the
installed jar, but involves hardcoding the path to the JRE in the metadata.

We could use a classpath variable for the JRE's location, and add an
external JAR reference relative to that, which uses the installed jar
and doesn't hardcode the location, but it means everyone has to add a
new variable to their workspace (there isn't a predefined one for
JAVA_HOME or JRE_HOME, annoyingly).

We could define a 'library', which is some sort of bundle of jars, which
has the disadvantages of all the above approaches, and none of the
advantages.

Any thoughts?

tom

Firstly, I assume the problem is it doesn't compile, isn't it? Because
it should run fine.

I'm not using Eclipse anymore these days, so I don't know exactly, but
isn't there some point where you define your "platform", viz. the JDK
you're using? Wouldn't including the lib in question belong in that step?

df.

 

[Tom Anderson]

Firstly, I assume the problem is it doesn't compile, isn't it?

Yes, absolutely.

Because it should run fine.

I would hope so.

I'm not using Eclipse anymore these days, so I don't know exactly, but
isn't there some point where you define your "platform", viz. the JDK
you're using?

They come pre-packaged (you tell Eclipse where the JDK home directory is,
and it searches out jars in it). It pulls jars from the JDK but not the
JRE, so it doesn't include plugin.jar by default.

Wouldn't including the lib in question belong in that step?

It is possible to edit the list, so yes, we could add plugin.jar there.
That has roughly the same disadvantages as adding a new 'library', in that
it has to be done individually on each machine, but it is rather neater.
Definitely an option to consider.

tom

 

[Arne Vajhøj]

We're writing an applet. It does uses LiveConnect to talk to JavaScript
on the page. The classes for that - JSObject and friends - are in
plugin.jar, which can be found in the JRE lib directory.

We're developing using Eclipse. Eclipse has no idea about plugin.jar.

What's the right way to teach it?

We could put a copy of plugin.jar in our project. That's easy, but means
we're not using the installed version, which leaves us vulnerable to
version mismatch if Sun decides to make changes to this decade-old piece
of code.

We could add an external jar reference. That's also easy, and uses the
installed jar, but involves hardcoding the path to the JRE in the metadata.

We could use a classpath variable for the JRE's location, and add an
external JAR reference relative to that, which uses the installed jar
and doesn't hardcode the location, but it means everyone has to add a
new variable to their workspace (there isn't a predefined one for
JAVA_HOME or JRE_HOME, annoyingly).

We could define a 'library', which is some sort of bundle of jars, which
has the disadvantages of all the above approaches, and none of the
advantages.

I would add it as external jar.

If that jar disappears due to a Java upgrade, then Eclipse
will give you an error and you just fix it.

The real build should be done via ant or maven anyway.

Arne