Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #25886 > unrolled thread
| Started by | Daniele Futtorovic <da.futt.news@laposte.net.invalid> |
|---|---|
| First post | 2011-01-28 18:41 +0100 |
| Last post | 2011-01-28 18:10 +0000 |
| Articles | 2 — 2 participants |
Back to article view | Back to comp.lang.java.programmer
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Eclipse vs plugin.jar Daniele Futtorovic <da.futt.news@laposte.net.invalid> - 2011-01-28 18:41 +0100
Re: Eclipse vs plugin.jar Tom Anderson <twic@urchin.earth.li> - 2011-01-28 18:10 +0000
| From | Daniele Futtorovic <da.futt.news@laposte.net.invalid> |
|---|---|
| Date | 2011-01-28 18:41 +0100 |
| Subject | Re: Eclipse vs plugin.jar |
| Message-ID | <ihuv37$3r7$1@news.eternal-september.org> |
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.
[toc] | [next] | [standalone]
| From | Tom Anderson <twic@urchin.earth.li> |
|---|---|
| Date | 2011-01-28 18:10 +0000 |
| Message-ID | <alpine.DEB.1.10.1101281804530.24197@urchin.earth.li> |
| In reply to | #25886 |
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
[toc] | [prev] | [standalone]
Back to top | Article view | comp.lang.java.programmer
csiph-web