Community
Participate
Working Groups
!MESSAGE Invalid path: java/lang/k:/re/midp/MIDP1/0/3/src/share/classes/java/lang/Class.java The bug is related to #12966 Steps to reproduce: Unzip the attached ManyBalls.zip into your workspace directory. "Import existing project into Workspace" Adjust the Java Build Path for the project to include <wtk home>\lib\midpapi.zip Get the stampysoftanttasks.jar from www.stampysoft.com, put it in the plugin\org.apache.ant directory and add the following lines to the plugin.xml <library name="stampysoftanttasks.jar"> <export name="*"/> </library> Edit the build.xml to match the 2jmewtk.home property your WTK path Edit the two .cmd files to point to the correct WTK path/Eclipse installation Run the build task Verify the build by running the runjad.cmd Set a breakpoint in ManyBalls.startApp() Run the rundbg.cmd batch file Attach to the Emulator (port 5000) The emulator should show a blank screen In the debugger select the System Thread[KVM_main] and suspend it The Debugger Source Lookup should pop up, asking for the source of java.lang.Class. At this point the entry gets written to the .log
Created attachment 1691 [details] workspace to reproduce problem
Can you provide a test case that doesn't require stampysoftanttasks? I expect it would be a real hassle (legal red tape) for me to acquire a copy of it.
You can do w/out the stampysoft ant tasks: - In the project root directory, execute the following command: \<wtkhome>\bin\preverify -classpath bin;<wtkhome>\lib\midpapi.zip bin - Add the .class files from the output folder to the ManyBalls.jar Regarding your concerns about the license: quote from the stampysoft site: "This code is released under the MIT license, which means you can do just about anything other than sue me." I should add that the midpapi.zip file that ships with the WTK contain class files with fully qualified paths for the SourceFile entries that cause this error to appear.
I just found the description of SourceFile Attribute in the VM Spec like below: The value of the sourcefile_index item must be a valid index into the constant_pool table. The constant pool entry at that index must be a CONSTANT_Utf8_info structure representing the string giving the name of the source file from which this class file was compiled. Only the name of the source file is given by the SourceFile attribute. It never represents the name of a directory containing the file or an absolute path name for the file. For instance, the SourceFile attribute might contain the file name foo.java but not the UNIX pathname /home/lindholm/foo.java. However, the sourefile name of the class in midpapi.zip of WTK contained an absolute path name, such as k:/re/midp/MIDP1/0/3/src/share/classes/java/lang/Class.java. I really don't know how to get such class file using javac.
There is code in the Java source locator to handle this, but perhaps it is failing on Linux: // @see bug# 12966 - remove absolute path prefix int index = sourceName.lastIndexOf(File.pathSeparatorChar); if (index >= 0) { sourceName = sourceName.substring(index + 1); } Jared, what is "File.pathSeparatorChar" on Linux? Perhaps it does not match the class files (which could have been compiled on a different platform). In this case, I suppose we need to look for any valid path seperator.
I don't think "File.pathSeparatorChar" would be the cause, since it depends on JDK of different platforms.
I guess Darin meant this: If the .class file was build under linux, it would contain "/". Checking under Windows against File.pathSeparatorChar, which is "\" would never yield a match. However, the files in question contain a strange mixture of drive letters ("k:") and unix style separators. Chris
Christian, can you cite a specific classfile in the midpapi.zip that contains a fully qualified path? I unzipped the zip file and opened a few of the classfiles and I don't see a problem. For example, the "SourceFile" attribute in com.sun.cldc.i18n.StreamReader.class is "StreamReader.java"
Jared, java.io.DataInput.class A binary dump of the file looks like this (removed unprintable chars by hand) readFully([B)VExceptions([BII)VskipBytes(I)IreadBoolean()ZreadByte()BreadUnsigne dByte()IreadShort()SreadUnsignedShort readChar()CreadInt readLong ()J readUTF ()Ljava/lang/String; SourceFile :k:/ws/toolkit/1.0.3-fcs/kvm/api/src/java/io/DataInput.java java/io/DataInput java/lang/Object java/io/IOException Chris
We seem to have version 1.0.4 of the toolkit: [jburns@radiohead bin]$ ./emulator -version J2ME Wireless Toolkit 1.0.4 Profile: MIDP-1.0 Configuration: CLDC-1.0 My java.io.DataInput.class has a SourceFile of "DataInput.java" The path in your classfile seems to indicate that you're running version 1.0.3. Can you try upgrading to see if they fixed this bug in 1.0.4? If we want to workaround the bug, Darin's suggestion seems correct. We should check for '/' or '\'.
I checked against a real 1.04 version, same result. But you are running on linux, whereas I use windows. So there seem to be different midpapi.zip depending on the OS. Microsoft Windows 2000 [Version 5.00.2195] (C) Copyright 1985-2000 Microsoft Corp. d:\Programs\java\wtk104\bin>emulator -version J2ME Wireless Toolkit 1.0.4 Profile: MIDP-1.0 Configuration: CLDC-1.0 Verzeichnis von D:\Programs\java\wtk104\lib 09.07.2002 21:21 <DIR> . 09.07.2002 21:21 <DIR> .. 09.07.2002 19:25 64.604 emptyapi.zip 13.06.2002 10:27 1.513 internal.config 13.06.2002 10:20 526.598 midpapi.zip 13.06.2002 10:27 932 system.config
I suggest to create a patch looking for both "slashes", and provide to Chris for testing.
Created attachment 1781 [details] patch launching plug-in
Attached is a test replacement for "org.eclipse.jdt.launching".
Tried attachment, seems to fix the problem.
Released the fix to HEAD and 2.0.1 Branch
Marking as verified (via Chris)
