Hi Jeff,
Sorry to join in on the discussions a little late, I've been away for
the past 2 weeks on holidays with my folks. I'm still catching up on
all of the traffic from the past couple of weeks - looks like
everyone's been busy! great to see everyone's opinions!
Hi Jeff,
Sorry to join in on the discussions a little late, I've been away for
the past 2 weeks on holidays with my folks. I'm still catching up on
all of the traffic from the past couple of weeks - looks like
everyone's been busy! great to see everyone's opinions!
On Wed, Sep 19, 2001 at 11:20:28PM +0200, Ola Lundqvist wrote:
> On Wed, Sep 19, 2001 at 10:44:30AM -0700, Bill Wohler wrote:
> > > Probably not. So the lib/ext dir should be empty, right?
> >
> > Disagree. There is a world of difference between jars you install
> > and jars you serendipitousl
On Thu, Sep 20, 2001 at 10:24:07AM +1000, Jeff Turner wrote:
> On Wed, Sep 19, 2001 at 09:21:15AM +0200, Ola Lundqvist wrote:
> > On Wed, Sep 19, 2001 at 09:59:09AM +1000, Jeff Turner wrote:
> > > On Tue, Sep 18, 2001 at 02:15:04PM -0700, Bill Wohler wrote:
> [..]
> > > Symlinking jars can be dange
On Wed, Sep 19, 2001 at 11:20:28PM +0200, Ola Lundqvist wrote:
> On Wed, Sep 19, 2001 at 10:44:30AM -0700, Bill Wohler wrote:
> > > Probably not. So the lib/ext dir should be empty, right?
> >
> > Disagree. There is a world of difference between jars you install
> > and jars you serendipitous
On Thu, Sep 20, 2001 at 10:24:07AM +1000, Jeff Turner wrote:
> On Wed, Sep 19, 2001 at 09:21:15AM +0200, Ola Lundqvist wrote:
> > On Wed, Sep 19, 2001 at 09:59:09AM +1000, Jeff Turner wrote:
> > > On Tue, Sep 18, 2001 at 02:15:04PM -0700, Bill Wohler wrote:
> [..]
> > > Symlinking jars can be dang
On Wed, Sep 19, 2001 at 09:21:15AM +0200, Ola Lundqvist wrote:
> On Wed, Sep 19, 2001 at 09:59:09AM +1000, Jeff Turner wrote:
> > On Tue, Sep 18, 2001 at 02:15:04PM -0700, Bill Wohler wrote:
[..]
> > Symlinking jars can be dangerous, because jars can contain a Class-path:
> > line in their manifest
On Wed, Sep 19, 2001 at 09:21:15AM +0200, Ola Lundqvist wrote:
> On Wed, Sep 19, 2001 at 09:59:09AM +1000, Jeff Turner wrote:
> > On Tue, Sep 18, 2001 at 02:15:04PM -0700, Bill Wohler wrote:
[..]
> > Symlinking jars can be dangerous, because jars can contain a Class-path:
> > line in their manifes
On Wed, Sep 19, 2001 at 10:44:30AM -0700, Bill Wohler wrote:
> Ola Lundqvist <[EMAIL PROTECTED]> writes:
> > > Another point about lib/ext. The JVM treats all jars in lib/ext as
> > > priveleged, like java.lang.*.
> > >
> > > "By default, installed extensions are granted all security permissions
On Wed, Sep 19, 2001 at 10:44:30AM -0700, Bill Wohler wrote:
> Ola Lundqvist <[EMAIL PROTECTED]> writes:
> > > Another point about lib/ext. The JVM treats all jars in lib/ext as
> > > priveleged, like java.lang.*.
> > >
> > > "By default, installed extensions are granted all security permission
Ben Burton <[EMAIL PROTECTED]> writes:
> Where does $JAVA_HOME/jre/lib/ext point to /usr/share/java? I have
> installed every JVM available for debian (I believe) and only j2sdk1.3
> comes with .../lib/ext, and that is a real directory that doesn't seem to
> point to /usr/share/java at all. I'm n
Ola Lundqvist <[EMAIL PROTECTED]> writes:
> > Another point about lib/ext. The JVM treats all jars in lib/ext as
> > priveleged, like java.lang.*.
> >
> > "By default, installed extensions are granted all security permissions
> > as if they were part of the core platform API"
> >
> >-- ht
Ben Burton <[EMAIL PROTECTED]> writes:
> Where does $JAVA_HOME/jre/lib/ext point to /usr/share/java? I have
> installed every JVM available for debian (I believe) and only j2sdk1.3
> comes with .../lib/ext, and that is a real directory that doesn't seem to
> point to /usr/share/java at all. I'm
Ola Lundqvist <[EMAIL PROTECTED]> writes:
> > Another point about lib/ext. The JVM treats all jars in lib/ext as
> > priveleged, like java.lang.*.
> >
> > "By default, installed extensions are granted all security permissions
> > as if they were part of the core platform API"
> >
> >-- h
On Wed, Sep 19, 2001 at 09:59:09AM +1000, Jeff Turner wrote:
> On Tue, Sep 18, 2001 at 02:15:04PM -0700, Bill Wohler wrote:
> > Ben Burton <[EMAIL PROTECTED]> writes:
> > > /usr/share/java/foo-version.jar
> > > /usr/share/java/foo.jar -> foo-version.jar
> >
> > Tread carefully. This could have u
On Wed, Sep 19, 2001 at 09:59:09AM +1000, Jeff Turner wrote:
> On Tue, Sep 18, 2001 at 02:15:04PM -0700, Bill Wohler wrote:
> > Ben Burton <[EMAIL PROTECTED]> writes:
> > > /usr/share/java/foo-version.jar
> > > /usr/share/java/foo.jar -> foo-version.jar
> >
> > Tread carefully. This could have
On Tue, Sep 18, 2001 at 05:45:14PM -0700, Joe Emenaker wrote:
>
> > I have half a gig of open source Java on my hdd, which amounts to a lot
> > of projects. With this scheme, I'd spend half my life twiddling the
> > JAVA_PROJ_LIB variable to point to whichever project I'm currently
> > interested
Jeff Turner <[EMAIL PROTECTED]> writes:
> On Wed, Sep 19, 2001 at 03:35:20AM +0200, Anders Jackson wrote:
> > Jeff Turner <[EMAIL PROTECTED]> writes:
> >
> > [...]
> >
> > > As long as it's not purely additive. I want to be able to remove stuff
> > > from the classpath, not just add my stuff. Th
On Wed, Sep 19, 2001 at 03:35:20AM +0200, Anders Jackson wrote:
> Jeff Turner <[EMAIL PROTECTED]> writes:
>
> [...]
>
> > As long as it's not purely additive. I want to be able to remove stuff
> > from the classpath, not just add my stuff. There are various subtle
> > problems that can occur othe
On Tue, Sep 18, 2001 at 12:40:01PM -0700, Joe Emenaker wrote:
>
> > > I would argue all classpath manipulation should be done in JVM/compiler
> > > startup scripts and Java application startup scripts.
> >
> > I think you're right.
>
> Me, too. And this has been what I've been pushing for from th
Jeff Turner <[EMAIL PROTECTED]> writes:
[...]
> As long as it's not purely additive. I want to be able to remove stuff
> from the classpath, not just add my stuff. There are various subtle
> problems that can occur otherwise:
Make /usr/bin/java a modified version of your proj.sh, wher you add
th
On Tue, Sep 18, 2001 at 07:13:49PM -0500, Ben Burton wrote:
>
> > Another point about lib/ext. The JVM treats all jars in lib/ext as
> > priveleged, like java.lang.*.
>
> It goes beyond this; policy should not say *anything* about lib/ext at all
> because our system has to support all available J
> I have half a gig of open source Java on my hdd, which amounts to a lot
> of projects. With this scheme, I'd spend half my life twiddling the
> JAVA_PROJ_LIB variable to point to whichever project I'm currently
> interested in.
Well, you can mitigate this by making JAVA_PROJ_LIB something like
> Another point about lib/ext. The JVM treats all jars in lib/ext as
> priveleged, like java.lang.*.
It goes beyond this; policy should not say *anything* about lib/ext at all
because our system has to support all available JVMs, not just sun ports.
Think kaffe, orp, etc.
Ben.
On Tue, Sep 18, 2001 at 05:45:14PM -0700, Joe Emenaker wrote:
>
> > I have half a gig of open source Java on my hdd, which amounts to a lot
> > of projects. With this scheme, I'd spend half my life twiddling the
> > JAVA_PROJ_LIB variable to point to whichever project I'm currently
> > interested
On Tue, Sep 18, 2001 at 02:15:04PM -0700, Bill Wohler wrote:
> Ben Burton <[EMAIL PROTECTED]> writes:
> > /usr/share/java/foo-version.jar
> > /usr/share/java/foo.jar -> foo-version.jar
>
> Tread carefully. This could have unpredictable results.
>
> The extension directory $JAVA_HOME/jre/lib/e
Jeff Turner <[EMAIL PROTECTED]> writes:
> On Wed, Sep 19, 2001 at 03:35:20AM +0200, Anders Jackson wrote:
> > Jeff Turner <[EMAIL PROTECTED]> writes:
> >
> > [...]
> >
> > > As long as it's not purely additive. I want to be able to remove stuff
> > > from the classpath, not just add my stuff. T
On Tue, Sep 18, 2001 at 12:40:01PM -0700, Joe Emenaker wrote:
>
> > > I would argue all classpath manipulation should be done in JVM/compiler
> > > startup scripts and Java application startup scripts.
> >
> > I think you're right.
>
> Me, too. And this has been what I've been pushing for from t
On Wed, Sep 19, 2001 at 03:35:20AM +0200, Anders Jackson wrote:
> Jeff Turner <[EMAIL PROTECTED]> writes:
>
> [...]
>
> > As long as it's not purely additive. I want to be able to remove stuff
> > from the classpath, not just add my stuff. There are various subtle
> > problems that can occur oth
Jeff Turner <[EMAIL PROTECTED]> writes:
[...]
> As long as it's not purely additive. I want to be able to remove stuff
> from the classpath, not just add my stuff. There are various subtle
> problems that can occur otherwise:
Make /usr/bin/java a modified version of your proj.sh, wher you add
t
On Tue, Sep 18, 2001 at 07:13:49PM -0500, Ben Burton wrote:
>
> > Another point about lib/ext. The JVM treats all jars in lib/ext as
> > priveleged, like java.lang.*.
>
> It goes beyond this; policy should not say *anything* about lib/ext at all
> because our system has to support all available
> I have half a gig of open source Java on my hdd, which amounts to a lot
> of projects. With this scheme, I'd spend half my life twiddling the
> JAVA_PROJ_LIB variable to point to whichever project I'm currently
> interested in.
Well, you can mitigate this by making JAVA_PROJ_LIB something like
> Another point about lib/ext. The JVM treats all jars in lib/ext as
> priveleged, like java.lang.*.
It goes beyond this; policy should not say *anything* about lib/ext at all
because our system has to support all available JVMs, not just sun ports.
Think kaffe, orp, etc.
Ben.
--
To UNSUBSCR
Ben Burton <[EMAIL PROTECTED]> writes:
> /usr/share/java/foo-version.jar
> /usr/share/java/foo.jar -> foo-version.jar
Tread carefully. This could have unpredictable results.
The extension directory $JAVA_HOME/jre/lib/ext currently points to
/usr/share/java, so /usr/share/java is serving as
> > /usr/share/java/foo-version.jar
> > /usr/share/java/foo.jar -> foo-version.jar
>
> Tread carefully. This could have unpredictable results.
>
> The extension directory $JAVA_HOME/jre/lib/ext currently points to
> /usr/share/java, so /usr/share/java is serving as the extension
> director
On Tue, Sep 18, 2001 at 02:15:04PM -0700, Bill Wohler wrote:
> Ben Burton <[EMAIL PROTECTED]> writes:
> > /usr/share/java/foo-version.jar
> > /usr/share/java/foo.jar -> foo-version.jar
>
> Tread carefully. This could have unpredictable results.
>
> The extension directory $JAVA_HOME/jre/lib/
> > I would argue all classpath manipulation should be done in JVM/compiler
> > startup scripts and Java application startup scripts.
>
> I think you're right.
Me, too. And this has been what I've been pushing for from the get-go.
> 1) What happens when classpath conflicts arise? Say I've insta
> > /usr/share/java/foo-version.jar
> > /usr/share/java/foo.jar -> foo-version.jar
>
> Tread carefully. This could have unpredictable results.
>
> The extension directory $JAVA_HOME/jre/lib/ext currently points to
> /usr/share/java, so /usr/share/java is serving as the extension
> directo
Ben Burton <[EMAIL PROTECTED]> writes:
> /usr/share/java/foo-version.jar
> /usr/share/java/foo.jar -> foo-version.jar
Tread carefully. This could have unpredictable results.
The extension directory $JAVA_HOME/jre/lib/ext currently points to
/usr/share/java, so /usr/share/java is serving as
Just to chime in, as an occasional java user (ie. "oh, this program
is in java, what do I have to figure out to run it -- oh, I can just
apt-get install these java libs") I agree - installed java packages
*should* be no less usable than installed C or Perl libraries.
Perhaps that implies that the
> > I would argue all classpath manipulation should be done in JVM/compiler
> > startup scripts and Java application startup scripts.
>
> I think you're right.
Me, too. And this has been what I've been pushing for from the get-go.
> 1) What happens when classpath conflicts arise? Say I've inst
Just to chime in, as an occasional java user (ie. "oh, this program
is in java, what do I have to figure out to run it -- oh, I can just
apt-get install these java libs") I agree - installed java packages
*should* be no less usable than installed C or Perl libraries.
Perhaps that implies that th
On Sat, Sep 15, 2001 at 08:54:19PM -0400, Andrew Pimlott wrote:
> On Thu, Sep 13, 2001 at 08:55:04PM +1000, jeff wrote:
> > But I'll spare you that ranting; let's just say I think it's a
> > horrifically bad idea to have a free-for-all in one's classpath.
>
> I tend to agree, though I should point
Joe,
On Mon, Sep 17, 2001 at 07:13:46PM -0700, Joe Emenaker wrote:
>
> > On Mon, Sep 17, 2001 at 01:40:16PM -0700, Joe Emenaker wrote:
> > My solution to the above problem is at:
> >
> > http://newgate.socialchange.net.au/~jeff/jpe/
[snip]
> The lynchpin to what I'm proposing is that narrower-s
On Mon, Sep 17, 2001 at 01:40:16PM -0700, Joe Emenaker wrote:
> > Why not just put the jars in /usr/share/java, keep the system classpath
> > completely clean, and let the startup scripts for individual apps choose
> which
> > to include?
>
> Well, keep in mind that the original e-mail that starte
On Sat, Sep 15, 2001 at 08:54:19PM -0400, Andrew Pimlott wrote:
> On Thu, Sep 13, 2001 at 08:55:04PM +1000, jeff wrote:
> > But I'll spare you that ranting; let's just say I think it's a
> > horrifically bad idea to have a free-for-all in one's classpath.
>
> I tend to agree, though I should poin
Joe,
On Mon, Sep 17, 2001 at 07:13:46PM -0700, Joe Emenaker wrote:
>
> > On Mon, Sep 17, 2001 at 01:40:16PM -0700, Joe Emenaker wrote:
> > My solution to the above problem is at:
> >
> > http://newgate.socialchange.net.au/~jeff/jpe/
[snip]
> The lynchpin to what I'm proposing is that narrower-
On Mon, Sep 17, 2001 at 01:40:16PM -0700, Joe Emenaker wrote:
> > Why not just put the jars in /usr/share/java, keep the system classpath
> > completely clean, and let the startup scripts for individual apps choose
> which
> > to include?
>
> Well, keep in mind that the original e-mail that start
On Mon, Sep 17, 2001 at 08:44:11AM -0500, Ben Burton wrote:
>
> > My mistake; only java.* works. If you want other jars to be considered
> > "standard", put them in $JAVA_HOME/jre/lib/ext/. This is a
> > platform-independent equivalent of what you're proposing.
>
> But not JVM-independent. Bear
> On Mon, Sep 17, 2001 at 01:40:16PM -0700, Joe Emenaker wrote:
> My solution to the above problem is at:
>
> http://newgate.socialchange.net.au/~jeff/jpe/
Well, I guess what I'm hoping for is to make the learning curve less steep.
I envision being able to download some java source onto a fresh D
On Mon, Sep 17, 2001 at 08:44:11AM -0500, Ben Burton wrote:
>
> > My mistake; only java.* works. If you want other jars to be considered
> > "standard", put them in $JAVA_HOME/jre/lib/ext/. This is a
> > platform-independent equivalent of what you're proposing.
>
> But not JVM-independent. Bear
> On Mon, Sep 17, 2001 at 01:40:16PM -0700, Joe Emenaker wrote:
> My solution to the above problem is at:
>
> http://newgate.socialchange.net.au/~jeff/jpe/
Well, I guess what I'm hoping for is to make the learning curve less steep.
I envision being able to download some java source onto a fresh
On Mon, Sep 17, 2001 at 12:15:59AM -0700, Per Bothner wrote:
> Jeff Turner <[EMAIL PROTECTED]> writes:
>
> > If you want other jars to be considered "standard", put them in
> > $JAVA_HOME/jre/lib/ext/. This is a platform-independent equivalent
> > of what you're proposing.
>
> I'm proposing that
jeff wrote:
Why not just put the jars in /usr/share/java, keep the system classpath
completely clean, and let the startup scripts for individual apps choose which
to include?
IMHO that's the best thing to do. Each packaged application knows which classes
it depends on and can include them into th
> Jeff Turner <[EMAIL PROTECTED]> writes:
>
> > If you want other jars to be considered "standard", put them in
> > $JAVA_HOME/jre/lib/ext/. This is a platform-independent equivalent
> > of what you're proposing.
>
> I'm proposing that the policy is that jars should be installed in
> $JAVA_HOME/jre
> Why not just put the jars in /usr/share/java, keep the system classpath
> completely clean, and let the startup scripts for individual apps choose
which
> to include?
Well, keep in mind that the original e-mail that started this thread argued
that Debian was a *developer*-unfriendly system.
Whe
On Mon, Sep 17, 2001 at 12:15:59AM -0700, Per Bothner wrote:
> Jeff Turner <[EMAIL PROTECTED]> writes:
>
> > If you want other jars to be considered "standard", put them in
> > $JAVA_HOME/jre/lib/ext/. This is a platform-independent equivalent
> > of what you're proposing.
>
> I'm proposing that
jeff wrote:
> Why not just put the jars in /usr/share/java, keep the system classpath
> completely clean, and let the startup scripts for individual apps choose which
> to include?
IMHO that's the best thing to do. Each packaged application knows which classes
it depends on and can include the
> Jeff Turner <[EMAIL PROTECTED]> writes:
>
> > If you want other jars to be considered "standard", put them in
> > $JAVA_HOME/jre/lib/ext/. This is a platform-independent equivalent
> > of what you're proposing.
>
> I'm proposing that the policy is that jars should be installed in
> $JAVA_HOME/jr
On Mon, Sep 17, 2001 at 09:10:52AM -0700, Per Bothner wrote:
> Ola Lundqvist wrote:
>
> >On Mon, Sep 17, 2001 at 12:15:59AM -0700, Per Bothner wrote:
> >
> >>My proposal does not say anything about /usr/bin/java, except that
> >>the default classpath should include jars of installed packages.
> >>
> Why not just put the jars in /usr/share/java, keep the system classpath
> completely clean, and let the startup scripts for individual apps choose
which
> to include?
Well, keep in mind that the original e-mail that started this thread argued
that Debian was a *developer*-unfriendly system.
Wh
On Mon, Sep 17, 2001 at 09:10:52AM -0700, Per Bothner wrote:
> Ola Lundqvist wrote:
>
> >On Mon, Sep 17, 2001 at 12:15:59AM -0700, Per Bothner wrote:
> >
> >>My proposal does not say anything about /usr/bin/java, except that
> >>the default classpath should include jars of installed packages.
> >
Ola Lundqvist wrote:
On Mon, Sep 17, 2001 at 12:15:59AM -0700, Per Bothner wrote:
My proposal does not say anything about /usr/bin/java, except that
the default classpath should include jars of installed packages.
I am agnostic about the specifics of how that is done.
Note that there are no default
> My mistake; only java.* works. If you want other jars to be considered
> "standard", put them in $JAVA_HOME/jre/lib/ext/. This is a
> platform-independent equivalent of what you're proposing.
But not JVM-independent. Bear in mind that we need a solution that works
for all JVMs out there, inclu
On Mon, Sep 17, 2001 at 12:21:41AM -0700, Per Bothner wrote:
> Ola Lundqvist <[EMAIL PROTECTED]> writes:
>
> > Well this is not a simple HelloWorld program, it is a servlet. And
> > the classes is in servlet2.2.jar right now.
>
> I'm sorry but I don't see your point. I'm not particularly
> conce
On Mon, Sep 17, 2001 at 12:15:59AM -0700, Per Bothner wrote:
> My proposal does not say anything about /usr/bin/java, except that
> the default classpath should include jars of installed packages.
> I am agnostic about the specifics of how that is done.
Note that there are no default CLASSPATH. As
Ola Lundqvist wrote:
>On Mon, Sep 17, 2001 at 12:15:59AM -0700, Per Bothner wrote:
>
>>My proposal does not say anything about /usr/bin/java, except that
>>the default classpath should include jars of installed packages.
>>I am agnostic about the specifics of how that is done.
>>
>Note that there
> My mistake; only java.* works. If you want other jars to be considered
> "standard", put them in $JAVA_HOME/jre/lib/ext/. This is a
> platform-independent equivalent of what you're proposing.
But not JVM-independent. Bear in mind that we need a solution that works
for all JVMs out there, incl
On Mon, Sep 17, 2001 at 12:21:41AM -0700, Per Bothner wrote:
> Ola Lundqvist <[EMAIL PROTECTED]> writes:
>
> > Well this is not a simple HelloWorld program, it is a servlet. And
> > the classes is in servlet2.2.jar right now.
>
> I'm sorry but I don't see your point. I'm not particularly
> conc
On Mon, Sep 17, 2001 at 12:15:59AM -0700, Per Bothner wrote:
> My proposal does not say anything about /usr/bin/java, except that
> the default classpath should include jars of installed packages.
> I am agnostic about the specifics of how that is done.
Note that there are no default CLASSPATH. A
On Sun, Sep 16, 2001 at 04:21:09PM -0700, Per Bothner wrote:
> Jeff Turner wrote:
>
> >I can write a Hello World program just fine with a completely blank
> >classpath [1]. In fact, I can write any program that uses java.* and
> >javax.* with nothing in the classpath except the package root.
> >
>
On Sun, Sep 16, 2001 at 04:21:09PM -0700, Per Bothner wrote:
> Jeff Turner wrote:
>
> >I can write a Hello World program just fine with a completely blank
> >classpath [1]. In fact, I can write any program that uses java.* and
> >javax.* with nothing in the classpath except the package root.
> >
On Sun, Sep 16, 2001 at 02:05:20PM -0700, Per Bothner wrote:
> Andrew Pimlott wrote:
>
> >On Thu, Sep 13, 2001 at 08:55:04PM +1000, jeff wrote:
> >
> >>But I'll spare you that ranting; let's just say I think it's a
> >>horrifically bad idea to have a free-for-all in one's classpath.
> >>
> >
> >I
Ola Lundqvist <[EMAIL PROTECTED]> writes:
> Well this is not a simple HelloWorld program, it is a servlet. And
> the classes is in servlet2.2.jar right now.
I'm sorry but I don't see your point. I'm not particularly
concerned about simple HelloWorld programs.
--
--Per Bothner
[EMAIL PRO
Jeff Turner <[EMAIL PROTECTED]> writes:
> If you want other jars to be considered "standard", put them in
> $JAVA_HOME/jre/lib/ext/. This is a platform-independent equivalent
> of what you're proposing.
I'm proposing that the policy is that jars should be installed in
$JAVA_HOME/jre/lib/ext/, exc
On Sun, Sep 16, 2001 at 04:21:09PM -0700, Per Bothner wrote:
> Jeff Turner wrote:
>
> >I can write a Hello World program just fine with a completely blank
> >classpath [1]. In fact, I can write any program that uses java.* and
> >javax.* with nothing in the classpath except the package root.
> >
>
On Sun, Sep 16, 2001 at 02:05:20PM -0700, Per Bothner wrote:
> Andrew Pimlott wrote:
>
> >On Thu, Sep 13, 2001 at 08:55:04PM +1000, jeff wrote:
> >
> >>But I'll spare you that ranting; let's just say I think it's a
> >>horrifically bad idea to have a free-for-all in one's classpath.
> >>
> >
> >I
Ola Lundqvist <[EMAIL PROTECTED]> writes:
> Well this is not a simple HelloWorld program, it is a servlet. And
> the classes is in servlet2.2.jar right now.
I'm sorry but I don't see your point. I'm not particularly
concerned about simple HelloWorld programs.
--
--Per Bothner
[EMAIL PR
Jeff Turner <[EMAIL PROTECTED]> writes:
> If you want other jars to be considered "standard", put them in
> $JAVA_HOME/jre/lib/ext/. This is a platform-independent equivalent
> of what you're proposing.
I'm proposing that the policy is that jars should be installed in
$JAVA_HOME/jre/lib/ext/, ex
On Sun, Sep 16, 2001 at 04:21:09PM -0700, Per Bothner wrote:
> Jeff Turner wrote:
>
> >I can write a Hello World program just fine with a completely blank
> >classpath [1]. In fact, I can write any program that uses java.* and
> >javax.* with nothing in the classpath except the package root.
> >
Jeff Turner wrote:
I can write a Hello World program just fine with a completely blank
classpath [1]. In fact, I can write any program that uses java.* and
javax.* with nothing in the classpath except the package root.
$ javac foo.java
foo.java:1: cannot resolve symbol
symbol : class Servlet
loca
On Sun, Sep 16, 2001 at 02:16:58PM -0700, Per Bothner wrote:
> jeff wrote:
>
> >Why not just put the jars in /usr/share/java, keep the system classpath
> >completely clean, and let the startup scripts for individual apps choose
> >which
> >to include?
> >
> Because you're causing a big hassle for
jeff wrote:
Why not just put the jars in /usr/share/java, keep the system classpath
completely clean, and let the startup scripts for individual apps choose which
to include?
Because you're causing a big hassle for anybody writing a Java program,
even "hello world".
It is one thing to ask packager
Andrew Pimlott wrote:
On Thu, Sep 13, 2001 at 08:55:04PM +1000, jeff wrote:
But I'll spare you that ranting; let's just say I think it's a
horrifically bad idea to have a free-for-all in one's classpath.
I tend to agree, though I should point out that the opposite view
has support. For example, Pe
Jeff Turner wrote:
>I can write a Hello World program just fine with a completely blank
>classpath [1]. In fact, I can write any program that uses java.* and
>javax.* with nothing in the classpath except the package root.
>
$ javac foo.java
foo.java:1: cannot resolve symbol
symbol : class Servle
On Sun, Sep 16, 2001 at 02:16:58PM -0700, Per Bothner wrote:
> jeff wrote:
>
> >Why not just put the jars in /usr/share/java, keep the system classpath
> >completely clean, and let the startup scripts for individual apps choose
> >which
> >to include?
> >
> Because you're causing a big hassle fo
jeff wrote:
>Why not just put the jars in /usr/share/java, keep the system classpath
>completely clean, and let the startup scripts for individual apps choose which
>to include?
>
Because you're causing a big hassle for anybody writing a Java program,
even "hello world".
It is one thing to ask p
Andrew Pimlott wrote:
>On Thu, Sep 13, 2001 at 08:55:04PM +1000, jeff wrote:
>
>>But I'll spare you that ranting; let's just say I think it's a
>>horrifically bad idea to have a free-for-all in one's classpath.
>>
>
>I tend to agree, though I should point out that the opposite view
>has support.
On Thu, Sep 13, 2001 at 08:55:04PM +1000, jeff wrote:
> But I'll spare you that ranting; let's just say I think it's a
> horrifically bad idea to have a free-for-all in one's classpath.
I tend to agree, though I should point out that the opposite view
has support. For example, Per Bothner said in
On Thu, Sep 13, 2001 at 08:55:04PM +1000, jeff wrote:
> But I'll spare you that ranting; let's just say I think it's a
> horrifically bad idea to have a free-for-all in one's classpath.
I tend to agree, though I should point out that the opposite view
has support. For example, Per Bothner said i
Hi Joe,
The suggestions here are all good and sensible, but are based on one big
assumption: that the classpath should be set to *anything* in the first place.
Why not just put the jars in /usr/share/java, keep the system classpath
completely clean, and let the startup scripts for individual apps
On Sat, Sep 15, 2001 at 09:34:45AM -0500, Ben Burton wrote:
>
> > > Does anyone have reasons why /usr/share/java/repository should remain?
> >
> > No do do not like that repository. Can we have some consensus about this?
> >
> > Should I remove it from the policy?
>
> Can we also remove the bulle
Hi Joe,
The suggestions here are all good and sensible, but are based on one big
assumption: that the classpath should be set to *anything* in the first place.
Why not just put the jars in /usr/share/java, keep the system classpath
completely clean, and let the startup scripts for individual app
On Sat, Sep 15, 2001 at 09:34:45AM -0500, Ben Burton wrote:
>
> > > Does anyone have reasons why /usr/share/java/repository should remain?
> >
> > No do do not like that repository. Can we have some consensus about this?
> >
> > Should I remove it from the policy?
>
> Can we also remove the bull
On Sat, 15 Sep 2001, Ola Lundqvist wrote:
> On Fri, Sep 14, 2001 at 04:23:47PM -0500, Ben Burton wrote:
> >
> > Seeing as java policy is getting a work through right now, I personally
> > have no problems with removing /usr/share/java/repository in favour of
> > versioned jars.
> >
> > Does anyone
On Sat, 15 Sep 2001, Ola Lundqvist wrote:
> On Fri, Sep 14, 2001 at 04:23:47PM -0500, Ben Burton wrote:
> >
> > Seeing as java policy is getting a work through right now, I personally
> > have no problems with removing /usr/share/java/repository in favour of
> > versioned jars.
> >
> > Does anyon
On Fri, Sep 14, 2001 at 04:23:47PM -0500, Ben Burton wrote:
>
> Seeing as java policy is getting a work through right now, I personally
> have no problems with removing /usr/share/java/repository in favour of
> versioned jars.
>
> Does anyone have reasons why /usr/share/java/repository should rem
> > Does anyone have reasons why /usr/share/java/repository should remain?
>
> No do do not like that repository. Can we have some consensus about this?
>
> Should I remove it from the policy?
Can we also remove the bullet point under "Advice to Java Packagers" that
*recommends* using the reposit
On Fri, Sep 14, 2001 at 04:23:47PM -0500, Ben Burton wrote:
>
> Seeing as java policy is getting a work through right now, I personally
> have no problems with removing /usr/share/java/repository in favour of
> versioned jars.
>
> Does anyone have reasons why /usr/share/java/repository should re
> > Does anyone have reasons why /usr/share/java/repository should remain?
>
> No do do not like that repository. Can we have some consensus about this?
>
> Should I remove it from the policy?
Can we also remove the bullet point under "Advice to Java Packagers" that
*recommends* using the reposi
1 - 100 of 112 matches
Mail list logo
