Community
Participate
Working Groups
According to the path I inherited, the VM on the windows box is "u2" c:\java\jdk7u2\jre\bin\java I think that's about a year old and now they are up to "u7"? (at oracle site) or "u10" from openjdk site. Not sure which you use, or even what I'd recommend (I've not kept up with non IBM JREs). I can research more if you don't know or have an established pattern. I'm hoping this might help eliminate the exact VM in use as a source of some of our "out of memory" errors (bug 390243)
Ok, I've installed the latest JDK(7u7) in c:\java\jdk1.7.0_07 . -M.
I can run this version of Java, but ... it might be the cause of a problem related to "XSL transforms". See bug 390494. So, let me double check ... you used a "JDK" right (fuller version of JRE) ... not sure it does, but sometimes does. Is the old one on the "PATH" or is any "CLASSPATH" defined for the machine? (Either literally in it system environment variables, or in its "hudson slave" configuration?)
Hmm, did find some info on web, such as http://stackoverflow.com/questions/10760798/securitymanager-and-xslt-extensions-in-java7-update4-broken Not sure I want to suggest to install xalan 2.7.1 into endorsed libs ... but would be surprised the issue is still there (from u4 to u7). I may just revert to old VM, but would like to hear confirmation there's nothing about Java on PATH and no system-wide CLASSPATH defined. Thanks,
I was able to reproduce the problem described in bug 390494 using a "u7" version of the Java VM, and I was able to test overcoming that problem by copying the 5 jars from Xalan 2.7.1 to the ...\jre\lib\endorsed directory. (The "endorsed" part of the directory path had to be created first). But, not sure that's something "we" want to do on build.eclipse.org?
Oh, meant to say, I'll drop back to u2 version we were using before, for now.
Upon further reading, I think the xalan jars could go in the lib\ext directory ... the place for "extensions" to VM (as opposed to "replacements, which is what "endorsed" is for). I tried that on my local machine (instead of "endorsed" directory) and it worked fine. We should check if they happened to have been installed in the u2 version's lib\ext directory? If so, their names would be serializer.jar xalan.jar xercesImpl.jar xml-apis.jar xsltc.jar [Though, don't think we need that last one.].
As I mentioned in bug 390494, I've not been able to "work around" this issue in any simple fashion (i.e. without changing out code). We will stay on older VMs, or, you can add xalan jars to lib/ext directory. Since this is a reported VM bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7167657 that seems to effect both 1.6 and 1.7 releases, the "ext" approach seems reasonable to me. I can not imagine it would "break" anything else or any other uses ... just restores a missing function. You can download xalan 2.7.1 from http://xml.apache.org/xalan-j/downloads.html site. I think some of their links are messed up or in transition, though, and I got my copy from their "archives" site: http://archive.apache.org/dist/xml/xalan-j/ I got http://archive.apache.org/dist/xml/xalan-j/xalan-j_2_7_1-bin.zip unzipped into its own directory (there's a ton of docs and samples), and then copied the five jars mentioned above to the u7 ...lib/ext directory.
(In reply to comment #7) > As I mentioned in bug 390494, I've not been able to "work around" this issue > in any simple fashion (i.e. without changing out code). > I think I have worked around this problem now, so no need to change ext dirs on systems. Just to close this off. Thanks.
