java 1.4 endorsed standards

[Al...@lodestarcorp.com]

According to several of the posts I've seen here, a generally accepted
method of overriding the version of xalan/xerces in JDK1.4 is to use the
-Xbootclasspath/p: jvm setting.  However,
http://java.sun.com/j2se/1.4.1/docs/tooldocs/windows/java.html appears to
say that doing so may violate the JVM license agreement.  An alternative
would be to use the endorsed standard override mechanism,
-Djava.endorsed.dirs=....  As a side issue, I would have thought that the
classes in rt.jar would have still loaded first since they're in the
bootclasspath, but they didn't seem to in our testing.

Anyway, we found one article that recommended not overriding APIs within
Sun's JVM because Sun was far more thorough with testing and would have a
very good idea of how the classes interact with the rest of the platform.
Does this argument hold water with the xerces/xalan APIs?  I guess I'm just
curious what other developers are doing.  Is it better to be conservative
and keep to whatever's been endorsed by Sun, or do the new features/better
performance/bug fixes necessitate using newer versions?

Thanks,
Alex
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
This e-mail message and any attachments are confidential and may be
privileged.  If you are not the intended recipient, please notify LODESTAR
Corporation immediately -- by replying to this message or by sending an
e-mail to postmaster@LODESTARcorp.com -- and destroy all copies of this
message and any attachments. Thank you.

For more information about LODESTAR Corporation, please visit us at
http://www.Lodestarcorp.com.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Re: java 1.4 endorsed standards

[Cyril Bouteille <cb...@hotwire.com>]

Alex,

The one advantage of the -Xbootclasspath solution is that when you 
change JDK, you don't have to do anything since it's all in your release 
scripts. It's like dynamically adding JCE provider instead of editing 
the java.security file. Copying files in the lib directory and/or 
modifying java configuration files requires you to document everything 
you did on a release to make sure you don't forget anything on the next.

I understand your concern about non-endorsed APIs. If you run into a 
Java/XML problem, Sun will most likely blame it on the unsupported 
version of Xalan, but in my experience, we've been using Xalan 2.4.1 
with J2SE 1.4.1 for a while and it works well.

Alex_Fuller@lodestarcorp.com wrote:

>According to several of the posts I've seen here, a generally accepted
>method of overriding the version of xalan/xerces in JDK1.4 is to use the
>-Xbootclasspath/p: jvm setting.  However,
>http://java.sun.com/j2se/1.4.1/docs/tooldocs/windows/java.html appears to
>say that doing so may violate the JVM license agreement.  An alternative
>would be to use the endorsed standard override mechanism,
>-Djava.endorsed.dirs=....  As a side issue, I would have thought that the
>classes in rt.jar would have still loaded first since they're in the
>bootclasspath, but they didn't seem to in our testing.
>
>Anyway, we found one article that recommended not overriding APIs within
>Sun's JVM because Sun was far more thorough with testing and would have a
>very good idea of how the classes interact with the rest of the platform.
>Does this argument hold water with the xerces/xalan APIs?  I guess I'm just
>curious what other developers are doing.  Is it better to be conservative
>and keep to whatever's been endorsed by Sun, or do the new features/better
>performance/bug fixes necessitate using newer versions?
>
>Thanks,
>Alex
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>This e-mail message and any attachments are confidential and may be
>privileged.  If you are not the intended recipient, please notify LODESTAR
>Corporation immediately -- by replying to this message or by sending an
>e-mail to postmaster@LODESTARcorp.com -- and destroy all copies of this
>message and any attachments. Thank you.
>
>For more information about LODESTAR Corporation, please visit us at
>http://www.Lodestarcorp.com.
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>  
>

-- 
Cyril Bouteille
Enterprise Java Architect
Hotwire.com <http://www.hotwire.com>
333 Market Street Suite 100
San Francisco, CA 94105

Hotwire - Fly. Sleep. Drive. Cheap. <http://www.hotwire.com>

------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and 
may contain confidential information. Any unauthorized review, use, 
disclosure or distribution of this message is prohibited. If you are not 
intended recipient of this message please contact the sender by reply 
email and destroy all copies of the original message.