«

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

--
I am the best at what i do.

On 28/01/2011 17:23, Tom Anderson allegedly wrote:
> 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.

On Fri, 28 Jan 2011, Daniele Futtorovic wrote:

> On 28/01/2011 17:23, Tom Anderson allegedly wrote:
>
>> We're developing using Eclipse. Eclipse has no idea about plugin.jar.
>>
>> What's the right way to teach it?
>
> 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

--
If god did exist, we would have to abolish him. -- Mikhail Bakunin

On 28-01-2011 11:23, Tom Anderson wrote:
> 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