On my system, the JRE java.exe is the 1st in the path.
There is a [JDK_HOME]/jre/lib/ext directory containing 3rd party JARs.
One of these was the v1.4.3 xerces.jar. When this file was in the ext dir, NB
failed to startup with the following exception...
Once I figured out that the xerces.jar was causing the problem, I thought it
might be a version issue. I copied the NB xerces.jar from [NB_HOME]/lib/ext
into the jre/ext dir and restarted. No luck - same exception.
Given the convenience of the Java extensions mechanism and the prevalence of
the Apache XML tools, I think this is a potential configuration issue.
Ideally, NB should work with whatever version of xerces.jar is in the user's
ext directory (w/in reason of course - I don't expect an NB expecting a version
1.x.x to work with a version 2.y.y). Barring that, I do not know if there is
some way to prevent the JVM from loading a JAR in the extensions directory (so
that the user can preserve their settings but NB can suppress it in favor of
its own) but that would be a good solution (if the user could unload classes
already loaded so that NB doesn't get hung-up).
*** Issue 17278 has been marked as a duplicate of this issue. ***
Sorry, if you place any JAR in jre/lib/ext/ it affects every Java
program you run, in this case detrimentally. (Extensions take
precedence over items in the user classpath.) NB is not designed to
run with an arbitrary version of any of its libraries, this would make
it impossible to test. Please delete the extension if you want to run
I don't know why it would fail if you *copy* xerces.jar (maybe someone
knowledgeable about the XML parser system could answer) but apparently
It has been suggested that NB explicitly exclude JRE extensions from
its classpath when starting, which would also improve startup
performance a bit. Unfortunately doing so, while possible, requires
making small VM-specific hacks (i.e. you have to know something about
the JDK implementation). We might do it anyway in the future.
Some investigation (trial & error as well as examining sources)
reveals that the error is due to a bug in Xerces fixed in 1.4.4 (and
2.x). With 1.4.4 and later, the IDE will generally work even if there
is some extra copy in jre/lib/ext/ (though if in doubt try removing
it). 1.4.3 and earlier have a serious problem in their JAXP
implementation: if the parser is specified by class name in a system
property, only the classloader used for JAXP is searched for the
parser. When you place JAXP (part of Xerces 1.x) in the JRE extension
classloader, it does not look in the application classloader, where NB
has its own parser factory.
So no change in NB seems necessary or desirable. If you do not put an
old and broken JAXP implementation in your boot classpath so as to
override the working impl in NB's classpath, there will be no problem.
*** Issue 18693 has been marked as a duplicate of this issue. ***
*** Issue 19395 has been marked as a duplicate of this issue. ***
*** Issue 18966 has been marked as a duplicate of this issue. ***
*** Issue 18786 has been marked as a duplicate of this issue. ***
*** Issue 18627 has been marked as a duplicate of this issue. ***
*** Issue 17727 has been marked as a duplicate of this issue. ***
*** Issue 25349 has been marked as a duplicate of this issue. ***
*** Issue 19663 has been marked as a duplicate of this issue. ***
Note: *not* a duplicate of issue #11020.
*** Issue 14237 has been marked as a duplicate of this issue. ***
Target milestone was changed from not determined to TBD
proposed release note:
Description: If you have version 1.4.3 or earlier of xerxes.jar in
your [JDK_HOME]/jre/lib/ext directory, the IDE does not start up.
Workaround: Remove the copy of xerxes.jar in your
[JDK_HOME]/jre/lib/ext directory or replace it with a later version.
1. The note should recommend that the user delete the JAR entirely,
not upgrade it.
2. "xerces" is the name used by the Apache project, though "xerxes" is
the conventional spelling for the historical king. :-)
relnote changes done and done
*** Issue 29396 has been marked as a duplicate of this issue. ***
*** Issue 29776 has been marked as a duplicate of this issue. ***
removing RELNOTE keyword as this does not seem to afflict people anymore
I haven't tried, but AFAIK this bug should not surface in NB 3.6
anyway since we rely on JDK 1.4 and no longer use the special JAXP
factory in core nor have Xerces on the main IDE classpath. Also the
Xerces 1.4.3- versions that seemed to have caused the bug are long