BillyMailman Posted October 30, 2015 Report Share Posted October 30, 2015 I've just updated to version 5.4.16.700 on a Windows 7 machine, and the embedded diff tool is now failing on .java files. It's configured to use the internal diff tool, but every time it tries to diff Java, the UI hangs for about 30s or so, then pops up with this error: It then displays the to versions of the file side-by-side, with syntax highlighting, but no actual diff highlighting. I definitely have a JVM installed and on the system path (JRE7, specifically). I could try adding the -vm option, but I don't even have a command to add it to; plastic is just configured to use the embedded diff viewer. Any idea what the problem could be? Does this require a particular version of Java? Does it require the JDK, and just not say so? Is there a way I can point the diff tool at the JVM? Link to comment Share on other sites More sharing options...
manu Posted November 4, 2015 Report Share Posted November 4, 2015 Hello! we saw this issue in the past and it was due to a corrupt java.exe tool at "c:\windows\system32\java.exe" System32 will be placed in the PATH before everything and that one is used. This java.exe is just like a symbolic link, an index, to the current java installation, sometimes it stops working and external tools get affected. If you have that tool you can try to temporally remove it, close plastic and try the diff operation again. Tell me if it helps. Link to comment Share on other sites More sharing options...
BillyMailman Posted November 5, 2015 Author Report Share Posted November 5, 2015 The copy of java in System32 is broken, yes, but I'm not ordinarily running into that, as System32 is later on my path than the correct location for java; I added it in at the start ages ago. Is something that Plastic does causing it to run into the System32 version anyway? Or is this just a general issue with symlinks? The correct copy is still via a link, albeit a working one, so I can swap between java versions when I need to for some really old code to compile correctly. Link to comment Share on other sites More sharing options...
manu Posted November 6, 2015 Report Share Posted November 6, 2015 Hello Billy, This is something I need to check why it behaves in this way but in execution time, without Plastic SCM changing the PATH environment variable the System32 is before your setting forcing "us" to find first the System32 java.exe. If you are not using the System32 link I do recomment you to remove it, or replace it with a valid java installation. We'll eventually provide a parameter to manually configure the JVM path. Link to comment Share on other sites More sharing options...
BillyMailman Posted November 9, 2015 Author Report Share Posted November 9, 2015 I got the time today to re-install .700 without the System32 links, and it's working perfectly now. Thanks for the help! Link to comment Share on other sites More sharing options...
manu Posted November 20, 2015 Report Share Posted November 20, 2015 Excellent. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.