Community
Participate
Working Groups
Created attachment 79305 [details] correcte file against the v_772a_R33x version Build ID: v_772a_R33x Steps To Reproduce: I am running the RunJDTCoreTests in Eclipse 3.3 using the build cited above. On my platform a get a dozen test failures in tests within BatchCompilerTest.java . These were fixed for me with no harm on a Linux platform by editing the tests to be sure that every directory path given as a command-line argument for a -bootclasspath or -cp option is fully quoted. Whether these tests fail may depend on the environment variables loperative when Eclipse is started - in my case they have C: and ; in them which often confuses command-line parsers. I have attached the working edited test file.
IMO, not all the quotes you added in BatchCompilerTest are necessary. I think that adding quotes around the library classes in getLibraryClasses() method would be enough. Maxime, what do you think?
(In reply to comment #1) > IMO, not all the quotes you added in BatchCompilerTest are necessary. I think > that adding quotes around the library classes in getLibraryClasses() method > would be enough. > Maxime, what do you think? > It is possible they are not all necessary. When I started editing I went for some consistency. However, I do know that at least some of the arguments to -cp were necessary along with some of the arguments to -bootclasspath.
I'll dig into this later, but here are my first thoughts. The rationale behind the existing quoting scheme was: whatever enough to get the tests to run on Windows and Linux (plus all platforms tested by nightly builds), which must leave considerable room for improvement and consistency. A question though: can you please tell us more about your configuration? I'd rather reproduce the problems before taking action (more exactly, depending how much effort this demands, I'd try to mirror your configuration here to avoid getting this bug showing up every once in a while - the experience we have is that BatchCompilerTest needs to be tested on all platforms more often than other suites, and if your configuration is odd enough to break it, we will get it broken often if we cannot test).
(In reply to comment #3) > I'll dig into this later, but here are my first thoughts. The rationale behind > the existing quoting scheme was: whatever enough to get the tests to run on > Windows and Linux (plus all platforms tested by nightly builds), which must > leave considerable room for improvement and consistency. > A question though: can you please tell us more about your configuration? I'd > rather reproduce the problems before taking action (more exactly, depending how > much effort this demands, I'd try to mirror your configuration here to avoid > getting this bug showing up every once in a while - the experience we have is > that BatchCompilerTest needs to be tested on all platforms more often than > other suites, and if your configuration is odd enough to break it, we will get > it broken often if we cannot test). I'm running Eclipse 3.3, launching it from within Cygwin (rather than directly from Windows). An example of a failing test was test 008 in BatchCompilerTest. I can make it fail again by taking away the quotes I added around the argument to -cp. In my environment that argument turns out to be C:\Program Files\Java\jre1.5.0_02\lib\jce.jar\r\n The error message I get as actual output is. Unrecognized option : Files\Java\jre1.5.0_02\lib\jce.jar\r\n Thus the relevant piece of information, I think, is that the classpath (and in my case the bootclasspath) contain directories with spaces in their names. A colleague of mine also using Cygwin, complete with C: and ; characters but no spaces did not see these errors. My JAVA_HOME and the return from System.getProperty("java.home") do not have "Program Files" in the path. However, the installed JRE (in the Java Preferences pages) is C:\Program Files\Java\jre1.5.0_02 . I presume this is where the space is coming from.
Thanks for the details. I'll need to dig deeper, since I do the same as you do (at least at the surface level: I launch eclipse from a Cygwin terminal since I switched machines a few months ago). I'll comment here as soon as I reach conclusions.
The key here is that the runtime JRE path contains one or more white spaces, and this fails both on Windows and Linux (that consistency is expected, since this is our compiler that analyzes the command line the tests pass, not the shell). Following the suggestion of Frederique, modifying getLibraryClasses and getJCEJar so that they return quoted strings cures the issue. The attached patch also renames them to getLibraryClassesAsQuotedString and getJCEJarAsQuotedString respectively to make clear what they do.
Created attachment 80119 [details] Fix of test cases The option suggested by Frederique minimizes the changes and makes writing additional tests easier than explicit quoting throughout BatchCompilerTest.java. It also has better chances to protect us from future failures, as long as no test run of nightly builds uses a runtime JRE with a path including white spaces.
Released for 3.4M3.
Released for 3.3.2.
Verified for 3.4M3 using I20071029-0010 build.
Verified for 3.3.2 using build M20080123-0800.
