#1 visual java pathfinder broken on windows

[willam boyd]

What steps will reproduce the problem?

1. Install Visual JavaPathFinder

a. Help -> Software Updates -> Find and Install -> Find New Features -> Next
b. Select 'New Remote Site...'
* Name: Visual JavaPathFinder
* Url: http://visualjpf.sourceforge.net/update
c. Select Finish
d. Select 'Visual JavaPathFinder'
e. Read and Accept the terms of agreement
f. Select Finish, one last time
g. Disregard the warnings and select 'Install all'
h. Select 'Yes' to restart Eclipse

2. create a java project

3. create a new java class ("com.javafreelancer.example.DeadLock").

4. right-click on the java source file created in step 4; select "Verify" from the menu.

What is the expected output? What do you see instead?

i expected visualjpf to create a jpf file that contains the correct fully qualified name of the target class created in step 4 ("com.javafreelancer.example.DeadLock"); instead, the plugin truncated the name of the target class to "com.DeadLock" in the auto-generated jpf file.

i corrected the fully qualified name of the target class in the jpf file. then, i right-clicked on the corrected jpf file, then selected "Run Verify" to launch visualjpf. i expected visualjpf to display the results of it's processing the "com.javafreelancer.example.DeadLock" class. instead, the following error message was written to the eclipse standard error console:

[SEVERE] can't find startup class: com.javafreelancer.example.DeadLock
[SEVERE] error initializing startup classes (check vm.[boot]classpath)

What version of the product are you using? On what operating system?

visual jpf version 1.0.14; Eclipse 3.3.1.1 Build id: M20071023-1652 on a windows xp machine; with the ibm sdk 6.0 jvm.

Please provide any additional information below.

the "vm.classpath" property in the "Default Properties" tab does contain the output directory ("C:\development\projects\tutorials\threads\intel\build") in which the "com.javafreelancer.example.DeadLock" class is compiled by the eclipse build mechanism. i double checked that that class file does exist there in that output directory. in addition to the output directory being included in the "vm.classpath", so is all of the jar files that are configured for the project's build path.

the actual value that is generated by visualjpf for the "vm.classpath" property in the jpf file contains *nix-style colon separators (":") between the classpath entries. i'm convinced that visualjpf is appending hardcoded ":" characters when it constructs the value for "vm.classpath"; a more portable alternative would be to use java's System.getProperty("path.separator") instead of hardcoded ":" characters.

thanks in advance for looking into this.

[willam boyd]

seeing that a significant majority of eclipse's installed base (in the commercial sector at least) is on the window's platform - plus, this issue is a showstopper - i believe this issue warrants a priority higher than "medium". thanks again for looking into this.

[Sandro Badame]

I think that this is fixed now. Can you confirm this for me before I close this.

Thank you,
--Sandro

[willam boyd]

thanks for looking into this.

i updated from 10.0.14 to 1.0.15. visual jpf plugin version 1.0.15 is doing the exact same thing as before (truncating the full pathname from "com.javafreelancer.example.DeadLock" to "com.DeadLock").

the exact same defect presents itself also on my solaris 9 sparc eclipse installation (Eclipse SDK Version: 3.3.2/Build id: M20080221-1800; java version "1.5.0_06") AND my mac os x 10.4.11 eclipse installation (Eclipse Platform Version: 3.4.1/Build id: M20080911-1700; VJP Plug-in 1.0.15; java.runtime.version=1.5.0_16-b06-275). for what its worth, the same thing also happens on my updated windows xp eclipse installation (ganymede/v 3.4).

the workaround is to manually edit the truncated package name, after vjpf generates the defective .jpf file.

thanks again for looking into it.

[willam boyd]

apologies if my last comment wasn't 100% clear. although the package name is still getting mangled, after the target value is manually edited to be the correct package name, vjpf does seem to work from that point onward. that is, it looks like the "[SEVERE] can't find startup class: com.javafreelancer.example.DeadLock" error that i reported previously has been resolved. but the truncated target value is still unresolved.