Why cant CLASSPATH be set on the fly

[Joseph Dionne]

I know that the java.class.path can be changed on-the-fly, but I ask why
not? Is it part of the security of Java, or a definition of the
sandbox, by setting the jvm classpath externally?

My questions is inspired by an application I am working on, and
admittedly I am a newbie to Java, but old timer at software development.
I am attempting to make a pure Java inet daemon, that takes Java
classes as the application to start. I want it to work like inetd, and
not have to restart the jvm. To do this, the "new" service's
"CLASSPATH", or at least the .jar file, needs to be added to the running
JVM.

I know, I need to make a custom classloader, and I am working to the
end, but I want to understand why this is a restriction in Java.

 

[Tony Morris]

I know that the java.class.path can be changed on-the-fly, but I ask why
not? Is it part of the security of Java, or a definition of the
sandbox, by setting the jvm classpath externally?

My questions is inspired by an application I am working on, and
admittedly I am a newbie to Java, but old timer at software development.
I am attempting to make a pure Java inet daemon, that takes Java
classes as the application to start. I want it to work like inetd, and
not have to restart the jvm. To do this, the "new" service's
"CLASSPATH", or at least the .jar file, needs to be added to the running
JVM.

I know, I need to make a custom classloader, and I am working to the
end, but I want to understand why this is a restriction in Java.

Sure, you can set it if you like. It won't have any effect on the system
class loader. If you in an unsigned applet, you'll be violating security
restrictions by attempting to set a system property.

I've heard this question before, and when I first heard it, I thought it was
a joke. Funnily (pun intended), I hear it all the time now (and so the joke
has worn off). I strongly suggest you read about creating your own class
loader.

Good luck.

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform

 

[Joseph Dionne]

Sure, you can set it if you like. It won't have any effect on the system
class loader. If you in an unsigned applet, you'll be violating security
restrictions by attempting to set a system property.

I've heard this question before, and when I first heard it, I thought it was
a joke. Funnily (pun intended), I hear it all the time now (and so the joke
has worn off). I strongly suggest you read about creating your own class
loader.

Good luck.

Thank you, you answered my question "why cant classpath be altered on
the fly" -- because it violates Java security. That point is very
important in web applets, however for pure Java applications, where the
security must be explicitly limited, this one restriction, the setting
of "CLASSPATH" is a hindrance. That is probably why you "hear" this
question more frequently -- Java is evolving into the language of choice
for many application programmers.

 

[Carl Howells]

Thank you, you answered my question "why cant classpath be altered on
the fly" -- because it violates Java security. That point is very
important in web applets, however for pure Java applications, where the
security must be explicitly limited, this one restriction, the setting
of "CLASSPATH" is a hindrance. That is probably why you "hear" this
question more frequently -- Java is evolving into the language of choice
for many application programmers.

Except that's almost entirely wrong...

First, security isn't the primary reason you're not allowed to change
the classpath. The primary reason is that changing the classpath
wouldn't do what people expect, most of the time.

Second, *anything* you might think you want to do by changing the
classpath at runtime can be done by creating a new ClassLoader at
runtime. Read up on classloaders, and URLClassLoader in particular.

 

[Joseph Dionne]

Except that's almost entirely wrong...

First, security isn't the primary reason you're not allowed to change
the classpath. The primary reason is that changing the classpath
wouldn't do what people expect, most of the time.

Second, *anything* you might think you want to do by changing the
classpath at runtime can be done by creating a new ClassLoader at
runtime. Read up on classloaders, and URLClassLoader in particular.

Thank you. But as the original op stated, I am creating a ClassLoader,
but my classes will be loaded from the local filesystem, and could be
from a directory tree of .class files or a .jar file with a built in
tree. With effort, I will accomplish this task, however it does seem
such a small thing to allow resetting java.class.path, with security
permission validation too, and letting the native classloader use the
new class path. One restriction would be that one could only "append"
to the original java.class.path, not completely replace it. However, I
can make an argument for completely replacing the initial
java.class.path as well.

The use I am suggesting allows for a single jvm to "add" new
applications on the fly, adopting the CLASSPATH setting that a new
application requires. I have found that multiple JVMs on a single
server can be self defeating, especially during garbage collection.
Reducing the number of JVMs, to one lets say, displays marks performance
increases.

Again, I am creating a ClassLoader to suit my needs. My post was meant
to understand why, and to perhaps get others to consider changing the
limitation might improve the language.

 

[Tony Morris]

Thank you, you answered my question "why cant classpath be altered on
the fly" -- because it violates Java security. That point is very
important in web applets, however for pure Java applications, where the
security must be explicitly limited, this one restriction, the setting
of "CLASSPATH" is a hindrance. That is probably why you "hear" this
question more frequently -- Java is evolving into the language of choice
for many application programmers.

You aren't able to "set the CLASSPATH on the fly" because that is
fundamentally broken with regard to how a class loader works.
You aren't allowed to set a system property within an unsigned applet
sandbox.

So, even if you could change the java.class.path system property, the
solution would be fundamentally broken.

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform

 

[Tony Morris]

Thank you. But as the original op stated, I am creating a ClassLoader,

I didn't say that at all.

but my classes will be loaded from the local filesystem, and could be
from a directory tree of .class files or a .jar file with a built in
tree. With effort, I will accomplish this task,

Yes, with a custom class loader.

however it does seem
such a small thing to allow resetting java.class.path, with security
permission validation too, and letting the native classloader use the
new class path.

This is fundamentally broken, it just won't work.
You'll understand why when you read up on how a class loader works,
especially with regard to its caching system.

One restriction would be that one could only "append"
to the original java.class.path, not completely replace it.

This restriction is trivial compared to the restriction that it just plain
and simply "won't work."

However, I
can make an argument for completely replacing the initial
java.class.path as well.

I doubt it the argument will be considered
If for whatever silly reason, the argument is considered, I (and I'm sure a
lot of others) will be protesting against such a flawed idea.

The use I am suggesting allows for a single jvm to "add" new
applications on the fly, adopting the CLASSPATH setting that a new
application requires. I have found that multiple JVMs on a single
server can be self defeating, especially during garbage collection.
Reducing the number of JVMs, to one lets say, displays marks performance
increases.

This problem has been addressed with some recent innovations.
For contractual reasons, I can't suggest any of these innovations; I'm sure
you can use google.

Again, I am creating a ClassLoader to suit my needs.

No you aren't. You REALLY need to understand what a class loader is.

My post was meant
to understand why, and to perhaps get others to consider changing the
limitation might improve the language.

This will break the language considerably.
From my dealings with the language authors, I'm sure they are competent
enough to deduce that this is a severely flawed suggestion,
and its implementation would not benefit anybody, except those who don't
(and won't) learn how a class loader works.

Good luck.

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform

 

[Joseph Dionne]

I didn't say that at all.




Yes, with a custom class loader.




This is fundamentally broken, it just won't work.
You'll understand why when you read up on how a class loader works,
especially with regard to its caching system.




This restriction is trivial compared to the restriction that it just plain
and simply "won't work."




I doubt it the argument will be considered
If for whatever silly reason, the argument is considered, I (and I'm sure a
lot of others) will be protesting against such a flawed idea.




This problem has been addressed with some recent innovations.
For contractual reasons, I can't suggest any of these innovations; I'm sure
you can use google.




No you aren't. You REALLY need to understand what a class loader is.




This will break the language considerably.
From my dealings with the language authors, I'm sure they are competent
enough to deduce that this is a severely flawed suggestion,
and its implementation would not benefit anybody, except those who don't
(and won't) learn how a class loader works.

Good luck.

Thank you Mr. Moris. As I said in the op, I am a newbie to Java, and my
learning curve continues. I will follow your advice and learn about the
classloader. However, after thirty years, and having seen things done
that were considered trivial and not needed implemented years, even
decades later, implemented because the concept was thought of
differently, I still believe a way can be found.

Case in point: I remember BBS discussions wanting a platform independent
language, and the majority saying "it wont work" for very valid reasons.
I remember conversations with peers saying that the OS should be free,
and a minor part of computers, with most peers claiming "it will never
happen." I remember twenty five years ago desiring that the community
of fine developers sharing their ideas, not holding snips of technology
as proprietary secrets (contractual agreements not with standing). Some
how all of things have come to pass.

My major complaint with M$ is the attitude of "my or the highway." My
hopes remain that developers of Java will come to the conclusion that
the "hard work" should be on them, allowing the users of the language
the freedom to focus on their application needs.

With all respect sir,
Joseph Dionne.

 

[Tony Morris]

Case in point: I remember BBS discussions wanting a platform independent

language, and the majority saying "it wont work" for very valid reasons.
I remember conversations with peers saying that the OS should be free,
and a minor part of computers, with most peers claiming "it will never
happen." I remember twenty five years ago desiring that the community
of fine developers sharing their ideas, not holding snips of technology
as proprietary secrets (contractual agreements not with standing). Some
how all of things have come to pass.

I rememebr some of those times as well.
You'll quickly realise that your analogy falls over when you learn about
class loaders.

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform

 

[Roedy Green]

Again, I am creating a ClassLoader to suit my needs. My post was meant
to understand why, and to perhaps get others to consider changing the
limitation might improve the language.

It is a similar problem to why you can't change the Current Working
Directory in Java. If one thread changed it, how do you co-ordinate
that with the other threads? They would be likely screwed by having
it changed out from under them at any point in the execution. Each
thread would then want its own CWD. Arggh. -- so you track your own
cwd.

In a similar way for classpath. Creating a new classloader with a
different classpath is much easier than you would imagine. This way
you can keep going with the old classpath and the new classpath
simultaneously. You don't change the classpath of some other thread
unpredictably.

It is a basic rule in multithreading. If you possibly can, make
objects immutable. Create a new one rather than modify an old one, and
you will have far fewer synchronisation problems.

See http://mindprod.com/jgloss/classforname.html

 

[Chris Uppal]

You aren't able to "set the CLASSPATH on the fly" because that is
fundamentally broken with regard to how a class loader works.

You've said that several times in this thread, but I haven't seen you explain
in what *way* it is fundamentally flawed.

In fact Roedy's point about the difficulty of co-ordinating such global changes
in a threaded language is the only concrete point against it that I've seen so
far.

I can launch my application with a minimal CLASSPATH that picks up only the
system classes and a tiny stub that knows how to start my application with its
own custom set of classloaders (so that hardly any of my code is ever loaded by
a system-provided classloader). Given that *I* can do that, and that once I've
done it I can change the "classpath" every millisecond if I wish, it's less
than clear in what way allowing changes to the real CLASSPATH is different.

-- chris

 

[Chris Smith]

Case in point: I remember BBS discussions wanting a platform independent
language, and the majority saying "it wont work" for very valid reasons.
I remember conversations with peers saying that the OS should be free,
and a minor part of computers, with most peers claiming "it will never
happen." I remember twenty five years ago desiring that the community
of fine developers sharing their ideas, not holding snips of technology
as proprietary secrets (contractual agreements not with standing). Some
how all of things have come to pass.

There's a rather large difference between these things and what you're
proposing. The ideas mentioned above are mostly sociological in nature,
leaveing a wide range of options for accomplishing large-scale goals.
Such problems frequently have solutions. What you're asking for is a
specific and focused (and unworkable) approach to solving a very
technical problem. You've been given other ways of accomplishing the
goal, but changing the classpath after classes have been loaded is
fundamentally broken. Not only that, but it doesn't provide substantial
advantages even if it could be made to work.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Tony Morris]

You've said that several times in this thread, but I haven't seen you
explain

in what *way* it is fundamentally flawed.

I have no ambition on writing a book describing resolution and caching
algorithms of class loader implementations.
Apologies for the lack of detail.

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform

 

[Chris Uppal]

I have no ambition on writing a book describing resolution and caching
algorithms of class loader implementations.
Apologies for the lack of detail.

I /know/ how classloaders work, and I can't see how changing the classpath
could be "fundamentally flawed".

I'll agree that it probably wouldn't have the effect that a naive programmer
would expect, and even that forcing the naive programmer to use classloaders
will (statistically) tend to stop them /being/ naive. I'll happily concede
that not allowing changes to the classpath is the better design decision.
*But*, none of that amounts to, or justifies, a claim that the idea of changing
the classpath is fundamentally flawed.

-- chris

 

[Joseph Dionne]

It is a similar problem to why you can't change the Current Working
Directory in Java. If one thread changed it, how do you co-ordinate
that with the other threads? They would be likely screwed by having
it changed out from under them at any point in the execution. Each
thread would then want its own CWD. Arggh. -- so you track your own
cwd.

[snip]

Thank you Mr. Green, but I also believe threaded programs should retain
certain "environment" parameters, regardless of what the parent thread
does, i.e. changing current working directory. Recent changes in Linux
pthread, like handling errno (formally a static in) becoming unique to
each thread, h_errno, and some others, are moving in a direction that
threads are retaining information typically associated to the process at
large.

I have finished my classloader, and yes, it was much easier than I
anticipated (actually the lack of clarity in the docs threw me, and the
missing reflect methods, which I believe should be part of ClassLoader,
somewhat added to my trepidation.

My design need a slight change, but in truth my initial design concept
was flawed (is that not always the case!). I thank you for you input. I
always find it useful.

 

[chris]

I have no ambition on writing a book describing resolution and caching
algorithms of class loader implementations.

That's a pity, because it seems you've seen something I've missed. On the
basis of everything I've read, the application class loader is an instance
of URLClassLoader, and therefore in theory it should be possible for the
system to call addURL() on it. If there are good reasons to block this
mechanism in the application class loader, I'd like to know what they are
(and the chapter and verse that allows me to do so without violating the
spec).

 

[Mark Thornton]

I /know/ how classloaders work, and I can't see how changing the classpath
could be "fundamentally flawed".

I'll agree that it probably wouldn't have the effect that a naive programmer
would expect, and even that forcing the naive programmer to use classloaders
will (statistically) tend to stop them /being/ naive. I'll happily concede
that not allowing changes to the classpath is the better design decision.
*But*, none of that amounts to, or justifies, a claim that the idea of changing
the classpath is fundamentally flawed.

-- chris

Suppose we have two classloaders A and B where A is the parent of B.
This means that B should ask A for classes before checking for classes
in its own classpath. Now load a class X which extends Y where both
classes are currently found in B (and not A).
Next add to the classpath of A so that there is now a class Y on A's
classpath.
Finally in B, load another class W which extends Y. But which Y.
The classes loaded now depend on the sequence in which these operations
were performed. Omitting the load of X will (probably) change the
version of Y which W gets as its superclass.

This is at least highly unsatisfactory if not "fundamentally flawed".

Mark Thornton

 

[Joseph Dionne]

Tony Morris wrote:




That's a pity, because it seems you've seen something I've missed. On the
basis of everything I've read, the application class loader is an instance
of URLClassLoader, and therefore in theory it should be possible for the
system to call addURL() on it. If there are good reasons to block this
mechanism in the application class loader, I'd like to know what they are
(and the chapter and verse that allows me to do so without violating the
spec).

I don't believe Mr. Morris needs to be assaulted because of my simple
question. Me research has hinted at why my idea was flawed, mostly
because it is too easy to do what I want with a custom classloader, or
just URLClassLoader itself. Perhaps the best response is "if it aint
broke, dont fix it."

My thought in asking this question was driving by my current application
need, which actually, now that I have "created" my classloader, required
two things, 1) an insertURL() method, and 2) flush any cached class,
forcing it to be reloaded.

I am creating a pure java inetd, where the applications will also be
other Java applications developed by other people. To ease the work on
those other developers, they would only define a WorkerThread class,
extending Thread, and the Inetd server would instantiate their class,
passing it the client socket, then call their WorkerThread.start() method.

The Inetd server application would have no knowledge of the Inetd client
application beyond the WorkerThread class. Having the ability to do the
above two steps would have made the Inetd.java server easier to read
than using a customer classloader, but the effect is the same.

I really wanted to restart JVM loaders in a new thread, with a new
CLASSPATH, letting then do their normal process and call Main(). This
would allow for application developers to do what they do best, write
applications, and not worry about the other stuff that Inetd is
managing, such as limiting number of connection, setting environment
variables/properties, etc. Also, like inetd, services become very easy
to plug in, start and stop, and I am adding monitoring features on top
of these typical inetd services.

 

[Richard Corfield]

I know that the java.class.path can be changed on-the-fly, but I ask why
not? Is it part of the security of Java, or a definition of the
sandbox, by setting the jvm classpath externally?

I know its already been answered that you create a ClassLoader, but more
to be said I think.

I have an application that finds plugin jars in the right directory. It
creates a ClassLoader to load the jar, and I think it uses JarFile to
look inside it for a description file (code is at work, not home).

Classes in the plugin jar file can see classes in the main application,
but classes in the application cannot see classes or resources in the
jar file. This is because your application was loaded with a ClassLoader
that is unaware of the jar file.

This is not normally a problem. The plugin class will implement an
interface which you have available in your main CLASSPATH, and your main
application will be written in terms of that interface, and not need to
know the details of the plugin's internal implementation.

The only gotcha I hit was that I had a hnady internationalisation helper
which made using MessageFormat a little more convenient. It was in the
main CLASSPATH, and had a static utility method to fetch resources. My
idea was that my company was liking the idea of placing resources in the
database rather than Java property files, perhaps to fit in with the
applications being developed in Oracle. Having one central load point
for resources would make that switchable easily, only that one central
load point couldn't see resources in the plugin jars.

- Richard

 

[Chris Uppal]

This is at least highly unsatisfactory if not "fundamentally flawed".

But (to reiterate, probably unecessarily ;-) it seems to me that I can create
that ambiguity by explicit classloader manipulation too. So, if that is the
reason for not allowing classpath manipulation, then the same reasoning should
ban classloader manipulation. Equally, if it is an acceptable (albeit
unwelcome) risk of classloader manipulation, then the same reasoning would seem
to suggest that classpath manipulation is not fundamentally flawed either.

-- chris