🚀 go-pugleaf

You're right on why that would be necessary - as far as I'm concerned
java.util is not a package anyone should use at all for there own classes.
My biggest
complaint here is with the library not JBuilder.  But I don't understand
your comment with respect to runtime.  The Java 2 Class loader
architecture is hierarchical.  All class loaders call into their parent
first so that the bootstrap class loader always tries to load each
referenced class first.  The bootstrap class loader loads from the Standard
API only.  The standard API is not specified in a classpath; it's
location is known from the install.  If I compile my project from a command
line javac, there are no complaints and the runtime is correct.
Even though this Netscape library contains java.util classes, the javac/java
processes go to the standard API first.  After the bootstrap
class loader there are user defined loaders for the standard extensions and
classpath.  This is also true with VisualCafe.  The whole point
is that you can't spoof standard API classes with bogus versions - the true
API version will always be loaded.  Even if you create your
own class loader to load, say, a java.util.Vector, the user defined class
loader has to call up into the hierarchy and ultimately the bootstrap
class loader will be the first to actually try and load java.util.Vector
which it will find in the standard API so your bogus version won't be
loaded.  I'm going to investigate why the Netscape LiveConnect library has
all these classes in it but I can tell you that this is not a problem
with VisualCafe, javac/java, or Forte.  I haven't tried VisualAge yet.

I get really concerned when I hear that a feature that is fundamentally
inconsistent with Java technology is added to a product and not
configurable because of user request.  If users requested that their classes
go first instead of the standard API, that implies to me that
they are trying to spoof the standard API which a) should not work at
runtime anyway and b) implies some fundamental misunderstanding
as to how Java technology works.  I see this all the time with newer
developers who don't understand that Java is more than a language and
standard library (the C mind-set).  The technology encompasses the language,
the standard API, the VM and the class/class loader architecture.  They all
work together and, in my opinion, you have to have some understanding of all
of them in order to begin to use
Java effectively.

Anyway, thanks for the reply and off the soap box - I'll play around with
this a little more today and see if I can't strip stuff out of the
Netscape library.

BTW, does anyone know what javax pacakges are included by default in
JBuilder projects and which have to added manually?

Scott



"Tor Iver Wilhelmsen" <tor.wilhelmsen@sds.no> wrote in message
news:upuawkqzn.fsf@sds.no...
> Rich Wilkman <richw@formlessvoid.com> writes:
>
> >   The JDK classes go to the end of the classpath in JBuilder (on
> > purpose and by user request),
>
> Well, have a nice time explaining the resulting runtime errors because
> they go on the "front" when the Java2 runtime is invoked... :-)
>
> Why a 3rd party library should need to include any java.* classes is
> another question.