Override a class in rt.jar

[Micha]

Hi,

I have developed an application that uses the Apache Xalan classes.
Everything works fine when running java 1.2. But when I run it using
java 1.4.1_02 things are very slow. The reason: the rt.jar from
1.4.1_02 include the Xalan classes, but an old version of them. Is
there a way I can make java load the classes from the Xalan.jar (which
I specify on the commandline with the -cp option) in stead of the
classes from the rt.jar?

Thanks,
Micha

 

[Michael Borgwardt]

I have developed an application that uses the Apache Xalan classes.
Everything works fine when running java 1.2. But when I run it using
java 1.4.1_02 things are very slow. The reason: the rt.jar from
1.4.1_02 include the Xalan classes, but an old version of them. Is
there a way I can make java load the classes from the Xalan.jar (which
I specify on the commandline with the -cp option) in stead of the
classes from the rt.jar?

You'll have to use the -Xbootclasspath option to achieve that. Theoretically,
that violates the JRE license, but I doubt anyone cares in that case.

 

[Jeffrey Palm]

You'll have to use the -Xbootclasspath option to achieve that.
Theoretically,
that violates the JRE license, but I doubt anyone cares in that case.

What part of the license does it violate -- just out of curiosity. If
that's a problem you could define your own classloader if this doesn't
violate it in the same way (hack).

Jeff

 

[Michael Borgwardt]

What part of the license does it violate -- just out of curiosity. If
that's a problem you could define your own classloader if this doesn't
violate it in the same way (hack).

-----
Binary Code License Agreement, SUPPLEMENTAL LICENSE TERMS,
D. Java Technology Restrictions:

You may not modify the Java Platform Interface ("JPI", identified as classes contained
within the "java" package or any subpackages of the "java" package), by creating
additional classes within the JPI or otherwise causing the addition to or modification of
the classes in the JPI. In the event that you create an additional class and associated
API(s) which (i) extends the functionality of the Java platform, and (ii) is exposed to
third party software developers for the purpose of developing additional software which
invokes such additional API, you must promptly publish broadly an accurate specification
for such API for free use by all developers. You may not create, or authorize your
licensees to create, additional classes, interfaces, or subpackages that are in any way
identified as "java", "javax", "sun" or similar convention as specified by Sun in any
naming convention designation.
-----

The point is that Sun wants the funactionality and behaviour of the core Java platform
to be fixed, to avoid compatibility issues.

Now that I read it again, it probably doesn't even apply in this particular case.

 

[Matt Humphrey]

-----
Binary Code License Agreement, SUPPLEMENTAL LICENSE TERMS,
D. Java Technology Restrictions:

You may not modify the Java Platform Interface ("JPI", identified as classes contained
within the "java" package or any subpackages of the "java" package), by creating
additional classes within the JPI or otherwise causing the addition to or modification of
the classes in the JPI. In the event that you create an additional class and associated
API(s) which (i) extends the functionality of the Java platform, and (ii) is exposed to
third party software developers for the purpose of developing additional software which
invokes such additional API, you must promptly publish broadly an accurate specification
for such API for free use by all developers. You may not create, or authorize your
licensees to create, additional classes, interfaces, or subpackages that are in any way
identified as "java", "javax", "sun" or similar convention as specified by Sun in any
naming convention designation.
-----

The point is that Sun wants the funactionality and behaviour of the core Java platform
to be fixed, to avoid compatibility issues.

Now that I read it again, it probably doesn't even apply in this particular case.

In the early days of Java 2, we commonly had to unpack the rt.jar, remove
the (broken) Corba classes and replace them.

Cheers,
Matt Humphrey (e-mail address removed) http://www.iviz.com/

 

[Jezuch]

U¿ytkownik Micha napisa³:

I have developed an application that uses the Apache Xalan classes.
Everything works fine when running java 1.2. But when I run it using
java 1.4.1_02 things are very slow. The reason: the rt.jar from
1.4.1_02 include the Xalan classes, but an old version of them. Is
there a way I can make java load the classes from the Xalan.jar (which
I specify on the commandline with the -cp option) in stead of the
classes from the rt.jar?

Not sure if this can help, but anyway:
http://java.sun.com/j2se/1.4.2/docs/guide/standards/
I think this does apply to Xalan in rt.jar.