Community
Participate
Working Groups
OS: RHEL 3.0WS U2, SLES 9 Beta 5 Language: Japanese Build level: M9 JDK version: IBM JDK 1.4.2 Beta cxia32dev-20040524 Test case #: Steps to recreate problem: 1-on Eclipse RHEL (default encoding EUC-JP), make connection for a SLES9 cvs server made by Eclipse Linux-gtk (default encoding UTF-8) 2-change the cvs server encoding to UTF-8, and check out a project 3-change the project encoding to UTF-8 4-Build the project manualy (set off Build AUtomatically, Clean..., Build Project. Please see comment #8 at a bug 59899) 5-select a java program, and Run > Java Application form the context menu Error: Launch Failed "The selection does not contain a main type" error dialog pop up. This occurrs when the cvs server and the project encoding is MS932. Expected Result: no error pop up and run successfully.
Created attachment 11313 [details] .log file additional steps, no error was thrown in above steps, but I got some errors in .log when re-started the Eclipse and did manual build.
Created attachment 11314 [details] zipped UTF-8 encoded project on cvs server
*** This bug has been marked as a duplicate of 64724 ***
It looks like the charset used to decode the file is incorrect. at sun.io.ByteToCharEUC.convert(ByteToCharEUC.java(Compiled Code)) at sun.nio.cs.StreamDecoder$ConverterSD.convertInto(StreamDecoder.java:287) at sun.nio.cs.StreamDecoder$ConverterSD.implRead(StreamDecoder.java:337) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:223) So the file is not read using the UTF-8 encoding.
I've found that this problem didn't occur with Sun JVM 1.4.2_04-b05. But the bug 64724 still occurred with the JVM. Please separate 64724.
Masayuki, are you saying that this problem is fixed/no longer a problem (i.e. did not occurr on the Sun VM)?
We have to use IBM's JVM. Could you find what's wrong with? If it's a fault of IBM JVM, please report it. Thanks.
I was able to launch on both Sun and IBM VMs. IBM VM Version (Eclipse I20040608-0800) java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2) Classic VM (build 1.4.2, J2RE 1.4.2 IBM Windows 32 build cndev-20040524 (JIT ena bled: jitc)) * I create a project "Test" * Set the encoding to UTF8 * imported the attached example * edited the source to remove CVS prefix/postfix on the files * Used the context menu to launch
I've confirmed the scenario in comment #8 worked on M9 that I reported this pr on. As the latest build looks like not function cvs, we should check the original scenario when the cvs feature is available.
CVS is in the latest build. To "enable" CVS you must turn on the "CVS Support" capability (for some reason, it is off by default). See "Windows > Prefernces > Workbench > Capabilities". Ensure "CVS Support" is checked.
Thanks for the info. I didn't know that.. In I200406082000, I can reproduce this error. I will e-mail you about our cvs access information, please try to reproduce.
I have just tried this using Red Hat 9.0 and it is working for me. I assume by RHEL 3.0 you mean the Enterprise version? I'll see if I can dig it up here.
I'm going to remove the RC2 tag, since there is likely nothing we can do for RC2. We'll keep investigating.
I've confirmed on RedHat Enterprise Linux 3.0 WS Update2 and SuSe Linux Enterprise Server 9.0 Beta5.
(Sorry, what have you "confirmed"? That things do or do *not* work on these platforms/OS's).
things did *not* work on these platforms. Today I tried RC2 on the RHEL 3.0 with IBM JVM 1.4.2 20040605, it had the same thing.
Are there any build errors in the project?
No, I didn't see build errors except "invalid Character" error in Test4.java that i put in deliberately in the project.
This looks like a VM issue. Could you please let us know what VM arguments you are using? What is your command line? Also for bug 64724, I was never able to reproduce it. If this is a VM issue, it should be reported to the VM vendor.
Moving to JCORE (although it looks like a VM issue). The error message indicates a main method could not be found in the selected compilation unit. However, we use Java Model API for this search (see org.eclipse.jdt.internal.debug.ui.launcher.JavaElementPropertyTester): private boolean hasMain(IJavaElement element) { try { IType mainType = null; if (element instanceof ICompilationUnit) { ICompilationUnit cu = (ICompilationUnit) element; mainType= cu.getType(Signature.getQualifier (cu.getElementName())); } else if (element instanceof IClassFile) { mainType = ((IClassFile)element).getType(); } else if (element instanceof IType) { mainType = (IType) element; } else if (element instanceof IMember) { mainType = ((IMember)element).getDeclaringType(); } if (mainType != null && mainType.exists() && JavaModelUtil.hasMainMethod(mainType)) { return true; } } catch (JavaModelException e) { } return false; } Another issue could be failing to retrive the "IJavaElement" adpater for the selection: if (receiver instanceof IAdaptable) { javaElement = (IJavaElement) ((IAdaptable)receiver).getAdapter (IJavaElement.class); }
Olivier - pls double check the possibility to retrieve the main method. What I find surprising is that we succeed to build it with no problem. If so, then we should be able to retrieve elements from it, if we use proper encoding.
It seems that it is failing only on certain VMs. So I'd like to get a list of these VMs on which this is failing. The one I tried works fine and therefore I cannot reproduce it. Darin, do you have one of the VMs that is failing? Tod, do we have such Linux box on which I could try it? Thanks.
The one in the lab has all language packs installed for RHEL 3.0.
Masayuki, could you please give me all the settings of the IBM VM that is failing? Did you try with the one that Darin used? Are you using the -Xj9 option? We need more details and I also need your CVS settings to connect to the CVS server. Thanks.
Removing milestone, since we cannot commit to addressing it until we have reproduced it at least once.
I reproduced the problem. The problem is during the indexing of the project. Because you change the encoding of the project after the project has been checked out from CVS, the indexes for that project are empty. The encoding used to retrieve the contents of the source file to index is the platform encoding. And this leads to this error: sun.io.MalformedInputException at sun.io.ByteToCharEUC.convert(ByteToCharEUC.java:193) at sun.nio.cs.StreamDecoder$ConverterSD.convertInto(StreamDecoder.java:287) at sun.nio.cs.StreamDecoder$ConverterSD.implRead(StreamDecoder.java:337) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:223) at java.io.InputStreamReader.read(InputStreamReader.java:208) at org.eclipse.jdt.internal.compiler.util.Util.getInputStreamAsCharArray(Util.java:354) at org.eclipse.jdt.internal.compiler.util.Util.getFileCharContent(Util.java:178) at org.eclipse.jdt.internal.core.search.JavaSearchDocument.getCharContents(JavaSearchDocument.java:58) at org.eclipse.jdt.internal.core.search.indexing.SourceIndexer.indexDocument(SourceIndexer.java:68) at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.indexDocument(JavaSearchParticipant.java:72) at org.eclipse.jdt.internal.core.search.indexing.IndexManager.indexDocument(IndexManager.java:269) at org.eclipse.jdt.internal.core.search.indexing.IndexManager$1.execute(IndexManager.java:581) at org.eclipse.jdt.internal.core.search.processing.JobManager.run(JobManager.java:361) at java.lang.Thread.run(Thread.java:567) After that the indexes are used to run the java application through the search request to find all types that have a main method. Because the indexes are empty, the search returns no result and then the java application launcher doesn't create the launching configuration. The rebuild after changing the encoding doesn't recompute the indexes. There is two workarounds for now: 1) Remove the .index files in the .metadata/.plugins/org.eclipse.jdt.core. This will force the indexes to be recomputed before the next search request. 2) Change the workspace encoding before checking out the project from CVS. If you set the workspace encoding to be MS932, before checking out the project, the problem is gone. The CVS server encoding doesn't affect the project's encoding when the project is created. Changing the encoding of the project seems to force a full build because the previous state was not found. Wed Jun 16 17:54:30 EDT 2004 - [Worker-0] Invoking (INCREMENTAL_BUILD) on builder: JavaBuilder(DBCSTest) Starting build of DBCSTest @ Wed Jun 16 17:54:30 EDT 2004 Saved state thinks last build failed for DBCSTest Performing full build since last saved state was not found FULL build About to compile ａｂｃ.java About to compile テスト.java About to compile SwingUIjp.java About to compile PerformanceExample.java About to compile MySample2/Test4.java About to compile MySample2/Test3.java About to compile MySample2/Test2.java About to compile MySample2/Test1.java About to compile MySample/Test4.java About to compile MySample/Test3.java About to compile MySample/Test2.java About to compile MySample/Test1.java Writing new class file ａｂｃ.class Writing new class file テスト.class Writing new class file SwingUIjp$1.class Writing new class file SwingUIjp.class Writing new class file PerformanceExample$3.class Writing new class file PerformanceExample.class Writing new class file PerformanceExample$2.class Writing new class file PerformanceExample$1.class Writing new class file Test4.class Writing new class file Test3.class Writing new class file Test2.class Writing new class file Test1.class Writing new class file Test4.class Writing new class file Test3.class Writing new class file Test2.class Writing new class file Test1.class Recording new state : State for DBCSTest (#0 @ Wed Jun 16 17:54:31 EDT 2004) Finished build of DBCSTest @ Wed Jun 16 17:54:39 EDT 2004 Wed Jun 16 17:54:39 EDT 2004 - [Worker-0] Builder finished: JavaBuilder(DBCSTest) time: 8621ms Changing the file and saving it triggers the indexer with the right encoding that time and then it works fine. We need to investigate how to trigger a reindexing of a project when its encoding is modified. Once the indexes are computed with the right encoding, it works fine.
The only way to really fix this would be to get a delta or something we could listen to find out that the project's encoding has been changed and recomputes the indexes. If the workspace's encoding is changed, it should trigger the reindexing of all projects that are using the workspace's encoding, but not the one that are using their own encoding. Right now an incremental build is triggered when the project's encoding is changed, because the preferences of the project is changed. But because there is no java source changes, nothing is done to change the indexes.
*** This bug has been marked as a duplicate of 59899 ***
