Kitchen-sink language problems on mac

Jonathan Gibbons Jonathan.Gibbons at Sun.COM
Thu Jun 14 20:52:12 PDT 2007


Christian,

I investigated this some more. The solution is to make sure the  
argument to
-Xbootclasspath is an absolute file. I did it by creating a new  
property using
	<property name="..." location="..."/>
as in the following:

         <property name="abs.dist.javac" location="${dist.javac}"/>
         <jtreg dir="test" samevm="true" verbose="summary"
                 jdk="${test.jdk.home}"
                 workDir="${build.jtreg}/work"
                 reportDir="${build.jtreg}/report">
             <arg value="-noshell"/>
             <arg value="-Xbootclasspath/p:${abs.dist.javac}/lib/ 
javac.jar"/>
             <include name="tools/javac/"/>
         </jtreg>


-- Jon


On Jun 14, 2007, at 11:12 AM, Christian Plesner Hansen wrote:

> Jon,
> Yes, that seems to be it: if I create a link to dist in / I don't get
> the class loading problems.  However there is still a few test
> failures (failed: 8; error: 6).
>
>
> -- Christian
>
> On 6/14/07, Jonathan Gibbons <Jonathan.Gibbons at sun.com> wrote:
>> Christian,
>>
>> I've done some investigating, using KSL, and jtreg 3.2.2_02 from
>> openJDK, on a Mac.
>>
>> I'm using NetBeans 6.0M9 to run the Ant file.
>>
>> I'm new to using NetBeans and jtreg on a Mac, so I'm finding my way
>> around a bit. Looks like we could do with better support for jtreg on
>> a Mac, but that is a separate issue. :-)
>>
>> jtreg likes to see a JDK with a JAVA_HOME that contains a bin/javac
>> and a bin/java command. So I used the trick of a "wrapper" JDK than
>> contains shell scripts called bin/javac and bin/java that call the
>> system commands (in /usr/bin).  In addition, for debugging, these
>> shell scripts echo their args.
>>
>> The anomaly I noticed is that Ant is not expanding the -
>> Xbootclasspath as expected.  It was being set to  -Xbootclasspath/p:/
>> dist/lib/javac.jar. I need investigate more why this is happening,
>> but this would explain the effect you are seeing, that the tests are
>> being executed by test.jdk.home, and not javac.jar, since jtreg is
>> not being given a valid path for javac.jar.
>>
>> -- Jon
>>
>>
>>
>>
>>
>>
>> On Jun 14, 2007, at 4:28 AM, Christian Plesner Hansen wrote:
>>
>> > I've tried it on linux, it behaves exactly the same.  It looks like
>> > it's running the compiler at test.jdk.home instead of the one in
>> > javac.jar.
>> >
>> > On 6/14/07, Christian Plesner Hansen <plesner at quenta.org> wrote:
>> >> Yes, that does indeed fix that problem.
>> >>
>> >> On 6/14/07, Jonathan Gibbons <Jonathan.Gibbons at sun.com> wrote:
>> >> > Christian,
>> >> >
>> >> > I believe I've identified the issue which you fixed by adding
>> >> the line
>> >> >        <arg value="tools/javac"/>
>> >> >
>> >> > There is a minor change in behaviour for jtreg 3.2.2_02, to fix
>> >> a problem
>> >> > with the way that jtreg executes tests specified in an Ant task.
>> >> (Ant
>> >> > support
>> >> > in jtreg is a relatively new feature.)
>> >> >
>> >> > The problem is caused by competing behaviors in jtreg and Ant,
>> >> as to who
>> >> > should expand directories.  On the command line, jtreg will
>> >> expand any
>> >> > directories you give it into a list of the tests in that  
>> directory.
>> >> > Depending
>> >> > on what exactly you write, Ant can also expand a directory into
>> >> a list
>> >> > of files
>> >> > and subdirectories. We need to make sure that jtreg does not  
>> expand
>> >> > any directories that have also been expanded by Ant.
>> >> >
>> >> > The solution we decided on was that if you use an Ant fileset to
>> >> specify
>> >> > the set of tests to be run, jtreg will just look at the files in
>> >> the
>> >> > fileset,
>> >> > and not any directories implicit in the fileset.
>> >> >
>> >> > This means that instead of specifying the directory
>> >> >        <include name="tools/javac"/>
>> >> >
>> >> > you should specify the set of files, by
>> >> >        <include name="tools/javac/**"/>
>> >> >
>> >> > or even just
>> >> >        <include name="tools/javac/"/>
>> >> >
>> >> > which means the same thing. (Note the trailing slash after  
>> javac.)
>> >> >
>> >> > Or, you can do as you did, and specify a directory as an arg for
>> >> jtreg,
>> >> > in which case jtreg will itself expand the directory.
>> >> >
>> >> > -- Jon
>> >> >
>> >> >
>> >> > Christian Plesner Hansen wrote:
>> >> > > The version I'm using is 3.2.2_02.  I'm running it on mac, I
>> >> can try
>> >> > > windows and/or linux tomorrow.
>> >> > >
>> >> > > I've been running it with ant (the build.xml that comes  
>> with ksl)
>> >> > > through netbeans.  Here's the ant target:
>> >> > >
>> >> > > <target name="xtest" depends="build">
>> >> > >    <fail unless="jtreg.home" message="Property 'jtreg.home'
>> >> needs to
>> >> > > be set to the jtreg installation directory."/>
>> >> > >    <taskdef name="jtreg" classpath="${jtreg.home}/lib/ 
>> jtreg.jar"
>> >> > > classname="com.sun.javatest.regtest.Main$$Ant"/>
>> >> > >    <fail unless="test.jdk.home" message="Property  
>> 'test.jdk.home'
>> >> > > needs to be set to the baseline JDK to be used to run the
>> >> tests"/>
>> >> > >    <jtreg dir="test" samevm="false" verbose="summary"
>> >> > >            jdk="${test.jdk.home}"
>> >> > >            workDir="${build.jtreg}/work"
>> >> > >            reportDir="${build.jtreg}/report">
>> >> > >        <arg value="-noshell"/>
>> >> > >        <arg value="-Xbootclasspath/p:${dist.javac}/lib/
>> >> javac.jar"/>
>> >> > >        <arg value="tools/javac"/>
>> >> > >        <include name="tools/javac"/>
>> >> > >    </jtreg>
>> >> > > </target>
>> >> > >
>> >> > > test.jdk.home is set to point to apple's most recent version
>> >> of java
>> >> > > 1.6.  I've attached the summary output.  If I don't add the  
>> <arg
>> >> > > value="tools/javac"/> line I get this:
>> >> > >
>> >> > > /Users/plesner/Documents/compiler/build.xml:157: No test  
>> suite or
>> >> > > tests specified.
>> >> > >
>> >> > >
>> >> > > -- Christian
>> >> > >
>> >> > > On 6/13/07, Jonathan Gibbons <Jonathan.Gibbons at sun.com> wrote:
>> >> > >> Christian,
>> >> > >>
>> >> > >> I'm sorry to hear of your problems with jtreg.  Which version
>> >> are you
>> >> > >> using?
>> >> > >> The latest version on the OpenJDK website is 3.2.2_02 (forget
>> >> the
>> >> > >> build numbers
>> >> > >> in this case, they're irrelevant.
>> >> > >>
>> >> > >> If you can send us the details of how you invoke jtreg
>> >> (either Ant or
>> >> > >> command line)
>> >> > >> and any error messages, I'll see if I can identify what is  
>> going
>> >> > >> wrong for you.
>> >> > >> I presume this is still on a Mac, that you're having
>> >> problems? Do you
>> >> > >> see the same
>> >> > >> problems on any other system, such as Linux, Solaris, or
>> >> Windows?
>> >> > >>
>> >> > >> On a related note, if anyone else is reading, we mortals can
>> >> now edit
>> >> > >> pages
>> >> > >> on the OpenJDK website again (well, actually, only Sun
>> >> mortals at
>> >> > >> this point.)
>> >> > >> So we'll be looking to generally update the info on the
>> >> OpenJDK pages
>> >> > >> in the
>> >> > >> next few days.
>> >> > >>
>> >> > >> -- Jon
>> >> > >>
>> >> > >> On Jun 13, 2007, at 8:02 AM, Christian Plesner Hansen wrote:
>> >> > >>
>> >> > >> > I've been running jtreg in netbeans using the ant script
>> >> that comes
>> >> > >> > with ksl.  When I run it the way it says on the website it
>> >> fails and
>> >> > >> > says that it can't find any tests to run.
>> >> > >> >
>> >> > >> > I've tried adding an argument that specifies the javac
>> >> tests and
>> >> > >> > disabled sameVM mode.  That makes it runs the tests but it
>> >> still gives
>> >> > >> > a bunch of failures, many of them NoClassDefFoundError.
>> >> > >> >
>> >> > >> >
>> >> > >> > -- Christian
>> >> > >> >
>> >> > >> > On 6/12/07, Jonathan Gibbons <Jonathan.Gibbons at sun.com>  
>> wrote:
>> >> > >> >> Christian,
>> >> > >> >>
>> >> > >> >> Peter brought the issue of the compiled property files  
>> to my
>> >> > >> >> attention
>> >> > >> >> last week.
>> >> > >> >> I've filed Bug 6568290 to track the issue.
>> >> > >> >>
>> >> > >> >> The short term workaround is to take and use a copy of the
>> >> > >> >> property compiler
>> >> > >> >> from OpenJDK: make/tools/CompileProperties/
>> >> CompileProperties.java
>> >> > >> >> or to write your own class that you can use which will
>> >> read and
>> >> > >> >> use the
>> >> > >> >> .properties files directly.
>> >> > >> >>
>> >> > >> >> As for the jtreg compiler tests, there are two issues that
>> >> I know of.
>> >> > >> >> The shell tests do not work in the mode where you put
>> >> javac.jar on
>> >> > >> >> the
>> >> > >> >> bootclasspath. The workaround for this is to use the - 
>> noshell
>> >> > >> >> argument
>> >> > >> >> to jtreg to (temporarily) exclude those tests.  The other
>> >> issue
>> >> > >> >> that came up
>> >> > >> >> a couple of weeks ago is that there were some problems
>> >> running the
>> >> > >> >> tests
>> >> > >> >> in sameVM mode (the -s option.)  The workaround is not to
>> >> use -s.
>> >> > >> >> I have a fix for that latter problem, and we will be
>> >> posting a new
>> >> > >> >> version of
>> >> > >> >> jttreg soon, I hope.
>> >> > >> >>
>> >> > >> >> -- Jon
>> >> > >> >>
>> >> > >> >>
>> >> > >> >>
>> >> > >> >> Christian Plesner Hansen wrote:
>> >> > >> >> > Hi
>> >> > >> >> > I've been trying to build the kitchen-sink language
>> >> project on
>> >> > >> >> my mac
>> >> > >> >> > and have run into some trouble.  I thought you might
>> >> want to
>> >> > >> >> know this
>> >> > >> >> > so you can either fix it or at least warn about it on
>> >> the project
>> >> > >> >> > website.
>> >> > >> >> >
>> >> > >> >> > On mac the bootclasspath contains the class files for
>> >> the default
>> >> > >> >> > installed version of javac.  This means that when you  
>> run
>> >> > >> >> > dist/bin/javac, it doesn't run the javac you just built
>> >> but the
>> >> > >> >> > standard one from the installed j2se.  If you specify
>> >> javac.jar
>> >> > >> >> with
>> >> > >> >> > -Xbootclasspath/p your javac will be run, but will not
>> >> use its own
>> >> > >> >> > property files because the compiled property files  
>> from the
>> >> > >> >> installed
>> >> > >> >> > javac takes precedence over the property files from your
>> >> own
>> >> > >> >> > javac.jar.
>> >> > >> >> >
>> >> > >> >> > Also, a bunch of the jtreg compiler tests fail seemingly
>> >> also
>> >> > >> >> because
>> >> > >> >> > of classpath/bootclasspath problems.
>> >> > >> >> >
>> >> > >> >> >
>> >> > >> >> > -- Christian
>> >> > >> >>
>> >> > >> >>
>> >> > >>
>> >> > >>
>> >> >
>> >> >
>> >>
>>
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20070614/3c03f987/attachment.html 


More information about the compiler-dev mailing list