From digitalemil at yahoo.de  Fri Jan  2 11:33:37 2009
From: digitalemil at yahoo.de (Emil Siemes)
Date: Fri, 2 Jan 2009 19:33:37 +0000 (GMT)
Subject: AW: AW: 6502395: Is not a bug
References: <595590.65426.qm@web23001.mail.ird.yahoo.com>
	<5F9683E3-08C2-460D-A235-547706A6668C@sun.com>
	<713859.97509.qm@web23006.mail.ird.yahoo.com>
	<A922DDB0-D8D0-4C96-8907-0700BA8A24AB@sun.com>
	<1ccfd1c10812121021m551f31c3j4f77003d546dc72c@mail.gmail.com>
	<49441A27.2040505@sun.com>
	<1229201536.9823.13.camel@hermans.wildebeest.org>
	<519254.80241.qm@web23006.mail.ird.yahoo.com>
Message-ID: <694411.25732.qm@web23008.mail.ird.yahoo.com>

Seems I was a bit too fast. When I tried b18 (see last mail) the path to java was correct but I still used JDK6u11 javac.
After correcting the setup b18 also throws FileNotFoundException (which is the correct behavior). So the bug was fixed before b18.

But the method which throws the exception in the following code  
"FileObject fo = filer.getResource(location, "", "foo/" + location + ".unexisting");
Reader reader = fo.openReader(true);"
is openReader not getResource as the spec suggests:

java.io.FileNotFoundException: foo/SOURCE_OUTPUT.unexisting (No such file or directory)
    at java.io.FileInputStream.open(Native Method)
    at java.io.FileInputStream.<init>(FileInputStream.java:137)
    at com.sun.tools.javac.file.RegularFileObject.openInputStream(RegularFileObject.java:68)
    at com.sun.tools.javac.file.BaseFileObject.openReader(BaseFileObject.java:76)



getResource
FileObject getResource(JavaFileManager.Location location,
CharSequence pkg,
CharSequence relativeName)
                       throws IOException
Returns an object for reading an existing resource.  The locations CLASS_OUTPUT and SOURCE_OUTPUT must be supported. 
Parameters:
location - location of the file
pkg - package relative to which the file should be searched, or the empty string if none
relativeName - final pathname components of the file 
Returns:
an object to read the file 
Throws: 
FilerException - if the same pathname has already been opened for writing 
IOException - if the file cannot be opened I'm challenging the spec a bit. Why should getResource() open the file at all? I think the normal behavior is like in the bug report:
getResource and then try opening the resource and expecting an exception if it fails. And as we see this is how the implementation works: getResource() returns a FileObject but doesn't open it and doesn't test if the file could be openend.

Any thoughts?

 









________________________________
Von: Emil Siemes <digitalemil at yahoo.de>
An: Mark Wielaard <mark at klomp.org>
CC: compiler-dev at openjdk.java.net; Jonathan Gibbons <Jonathan.Gibbons at Sun.COM>
Gesendet: Dienstag, den 16. Dezember 2008, 14:01:24 Uhr
Betreff: AW: 6502395: Is not a bug


Hi Mark,

thanks for the links. I was able to test b18 and at least this build still throws UnsupportedOperationException.
I now wanted to follow-up the path but it seems that the fedoraproject has some database issues...
Will try again later. And yes a central repository with all old binary & source bundles would be helpful.

Thanks
  Emil




________________________________
Von: Mark Wielaard <mark at klomp.org>
An: Dalibor Topic <Dalibor.Topic at Sun.COM>
CC: Jonathan Gibbons <Jonathan.Gibbons at Sun.COM>; compiler-dev at openjdk.java.net
Gesendet: Samstag, den 13. Dezember 2008, 21:52:15 Uhr
Betreff: Re: 6502395: Is not a bug

On Sat, 2008-12-13 at 21:25 +0100, Dalibor Topic wrote:
> Martin Buchholz wrote:
> > On Fri, Dec 12, 2008 at 08:56, Jonathan Gibbons
> > <Jonathan.Gibbons at sun.com> wrote:
> > 
> >> Like you, I could not find public builds for JDK7 builds earlier than b36. I
> >> am sorry (and somewhat surprised) that they are not available.
> > 
> > I complained about this elsewhere.
> > Lack of hardware resources to hold the archives were cited.
> > 
> > I'd like to see every build remain available for download for at least 3 years.
> 
> Did I hear someone volunteering to build & maintain a mirror? ;)

We do keep a mirror of the old GPL sources (which came from the svn
repository) in mercurial at http://icedtea.classpath.org/hg/openjdk if
anybody needs anything early (b13 till b23). Although the changes
between the bxx drops are somewhat big, you can do some simple
investigations against it through mercurial.

Also various GNU/Linux distros still have old GPL binary icedtea/openjdk
1.7 packages (and source code of course) around (although most are
tracking jdk6 these days). Here are old builds of the 1.7.0 tree (b18
till b24) for Fedora 8/9 for example:
http://koji.fedoraproject.org/koji/packageinfo?packageID=4946

Cheers,

Mark


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20090102/282d3612/attachment.html 

From digitalemil at yahoo.de  Fri Jan  2 14:31:11 2009
From: digitalemil at yahoo.de (Emil Andreas Siemes)
Date: Fri, 2 Jan 2009 23:31:11 +0100
Subject: [Patch] 6502392 Invalid relative names for Filer.createResource and
	Filer.getResource
Message-ID: <5DF426C2-99DC-4E72-8C98-3933A034918E@yahoo.de>

com.sun.tools.javac.file.JavacFileManager checks if a name fulfills  
the requirements of relative names:
"A relative name is a non-null, non-empty sequence of path segments  
separated by '/'; '.' and '..' are invalid path segments. A valid  
relative name must match the "path-rootless" rule of RFC 3986, section  
3.3."

This is done via the isRelativeUri() method. Unfortunately this method  
doesn't currently really check for path-rootless compliance. A patch  
with an improved method is attached.
When java.net.Uri eventually supports RFC 3986 the need for  
isRelativeUri() goes away. I would also like to propose to rename  
isRelativeUri() to isRF3986PathRootless() which would more clearly  
describe what the method does.

There is a comment in JavacFileManager in a couple of lines:
//FIX ME 6419701
but I don't find bug 6419701 in the bug database. Any thoughts?

Thanks
     Emil




  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20090102/510acf8f/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JavacFileManager.diff
Type: application/octet-stream
Size: 3624 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20090102/510acf8f/JavacFileManager.diff 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20090102/510acf8f/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TestFor6502392.java
Type: application/octet-stream
Size: 1401 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20090102/510acf8f/TestFor6502392.java 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20090102/510acf8f/attachment-0002.html 

From Jonathan.Gibbons at Sun.COM  Mon Jan  5 15:07:16 2009
From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons)
Date: Mon, 05 Jan 2009 15:07:16 -0800
Subject: AW: AW: 6502395: Is not a bug
In-Reply-To: <694411.25732.qm@web23008.mail.ird.yahoo.com>
References: <595590.65426.qm@web23001.mail.ird.yahoo.com>
	<5F9683E3-08C2-460D-A235-547706A6668C@sun.com>
	<713859.97509.qm@web23006.mail.ird.yahoo.com>
	<A922DDB0-D8D0-4C96-8907-0700BA8A24AB@sun.com>
	<1ccfd1c10812121021m551f31c3j4f77003d546dc72c@mail.gmail.com>
	<49441A27.2040505@sun.com>
	<1229201536.9823.13.camel@hermans.wildebeest.org>
	<519254.80241.qm@web23006.mail.ird.yahoo.com>
	<694411.25732.qm@web23008.mail.ird.yahoo.com>
Message-ID: <496292A4.2070400@sun.com>

Emil,

The spec is what it is, and cannot easily be changed. And, being 
pedantic, the spec does not require the file
to be opened; it merely says that an exception must be thrown if the 
file cannot be opened. The implementation
may perform a number of checks to determine whether the file can be 
opened in principle without actually
opening it.

What is your current disposition regarding this bug?  Are you now saying 
the javac behavior and the test's
behavior are now both correct?

-- Jon



Emil Siemes wrote:
> Seems I was a bit too fast. When I tried b18 (see last mail) the path 
> to java was correct but I still used JDK6u11 javac.
> After correcting the setup b18 also throws FileNotFoundException 
> (which is the correct behavior). So the bug was fixed before b18.
>
> But the method which throws the exception in the following code 
> "FileObject fo = filer.getResource(location, "", "foo/" + location + 
> ".unexisting");
> Reader reader = fo.openReader(true);"
> is openReader not getResource as the spec suggests:
>
> java.io.FileNotFoundException: foo/SOURCE_OUTPUT.unexisting (No such 
> file or directory)
>     at java.io.FileInputStream.open(Native Method)
>     at java.io.FileInputStream.<init>(FileInputStream.java:137)
>     at 
> com.sun.tools.javac.file.RegularFileObject.openInputStream(RegularFileObject.java:68)
>     at 
> com.sun.tools.javac.file.BaseFileObject.openReader(BaseFileObject.java:76)
>
>
>       getResource
>
> FileObject <http://www.java.net/download/jdk6/docs/api/javax/tools/FileObject.html?is-external=true> *getResource*(JavaFileManager.Location <http://www.java.net/download/jdk6/docs/api/javax/tools/JavaFileManager.Location.html?is-external=true> location,
>                        CharSequence <http://www.java.net/download/jdk6/docs/api/java/lang/CharSequence.html?is-external=true> pkg,
>                        CharSequence <http://www.java.net/download/jdk6/docs/api/java/lang/CharSequence.html?is-external=true> relativeName)
>                        throws IOException <http://www.java.net/download/jdk6/docs/api/java/io/IOException.html?is-external=true>
>
>     Returns an object for reading an existing resource. The locations
>     |CLASS_OUTPUT|
>     <http://www.java.net/download/jdk6/docs/api/javax/tools/StandardLocation.html?is-external=true#CLASS_OUTPUT>
>     and |SOURCE_OUTPUT|
>     <http://www.java.net/download/jdk6/docs/api/javax/tools/StandardLocation..html?is-external=true#SOURCE_OUTPUT>
>     must be supported.
>
>     *Parameters:*
>         |location| - location of the file
>         |pkg| - package relative to which the file should be searched,
>         or the empty string if none
>         |relativeName| - final pathname components of the file 
>     *Returns:*
>         an object to read the file 
>     *Throws:*
>         |FilerException
>         <file:///home/emil/java/docs/jsr269/docs/javax/annotation/processing/FilerException.html>|
>         - if the same pathname has already been opened for writing 
>         |IOException
>         <http://www.java.net/download/jdk6/docs/api/java/io/IOException.html?is-external=true>|
>         - if the file cannot be opened 
>
> I'm challenging the spec a bit. Why should getResource() open the file 
> at all? I think the normal behavior is like in the bug report:
> getResource and then try opening the resource and expecting an 
> exception if it fails. And as we see this is how the implementation 
> works: getResource() returns a FileObject but doesn't open it and 
> doesn't test if the file could be openend.
>
> Any thoughts?
>
>  
>
>
>
>
>
>
> ------------------------------------------------------------------------
> *Von:* Emil Siemes <digitalemil at yahoo.de>
> *An:* Mark Wielaard <mark at klomp.org>
> *CC:* compiler-dev at openjdk.java.net; Jonathan Gibbons 
> <Jonathan.Gibbons at Sun.COM>
> *Gesendet:* Dienstag, den 16. Dezember 2008, 14:01:24 Uhr
> *Betreff:* AW: 6502395: Is not a bug
>
> Hi Mark,
>
> thanks for the links. I was able to test b18 and at least this build 
> still throws UnsupportedOperationException.
> I now wanted to follow-up the path but it seems that the fedoraproject 
> has some database issues...
> Will try again later. And yes a central repository with all old binary 
> & source bundles would be helpful.
>
> Thanks
>   Emil
>
> ------------------------------------------------------------------------
> *Von:* Mark Wielaard <mark at klomp.org>
> *An:* Dalibor Topic <Dalibor.Topic at Sun.COM>
> *CC:* Jonathan Gibbons <Jonathan.Gibbons at Sun.COM>; 
> compiler-dev at openjdk.java.net
> *Gesendet:* Samstag, den 13. Dezember 2008, 21:52:15 Uhr
> *Betreff:* Re: 6502395: Is not a bug
>
> On Sat, 2008-12-13 at 21:25 +0100, Dalibor Topic wrote:
> > Martin Buchholz wrote:
> > > On Fri, Dec 12, 2008 at 08:56, Jonathan Gibbons
> > > <Jonathan.Gibbons at sun.com <mailto:Jonathan.Gibbons at sun.com>> wrote:
> > >
> > >> Like you, I could not find public builds for JDK7 builds earlier 
> than b36. I
> > >> am sorry (and somewhat surprised) that they are not available.
> > >
> > > I complained about this elsewhere.
> > > Lack of hardware resources to hold the archives were cited.
> > >
> > > I'd like to see every build remain available for download for at 
> least 3 years.
> >
> > Did I hear someone volunteering to build & maintain a mirror? ;)
>
> We do keep a mirror of the old GPL sources (which came from the svn
> repository) in mercurial at http://icedtea.classpath.org/hg/openjdk if
> anybody needs anything early (b13 till b23). Although the changes
> between the bxx drops are somewhat big, you can do some simple
> investigations against it through mercurial.
>
> Also various GNU/Linux distros still have old GPL binary icedtea/openjdk
> 1.7 packages (and source code of course) around (although most are
> tracking jdk6 these days). Here are old builds of the 1.7.0 tree (b18
> till b24) for Fedora 8/9 for example:
> http://koji.fedoraproject.org/koji/packageinfo?packageID=4946
>
> Cheers,
>
> Mark
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20090105/830f5952/attachment.html 

From Jonathan.Gibbons at Sun.COM  Mon Jan  5 17:11:22 2009
From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons)
Date: Mon, 05 Jan 2009 17:11:22 -0800
Subject: [Patch] 6502392 Invalid relative names for Filer.createResource
	and Filer.getResource
In-Reply-To: <5DF426C2-99DC-4E72-8C98-3933A034918E@yahoo.de>
References: <5DF426C2-99DC-4E72-8C98-3933A034918E@yahoo.de>
Message-ID: <4962AFBA.2090900@sun.com>

Emil,

Thank you for looking at this, and for your patch.

I do not understand why 6419701 is not public. I am trying to find out 
why it is not.
The bug itself is about the use of URI.create, not about the use of 
isRelativeURI.

I'm not sure that your patch is warranted (or arguably, the correct 
fix).  Your patch certainly
contains functionality that on the face of it would better belong in 
java.net.URI and not
JavacFileManager.

The way I read the code in JavacFileManager, isRelativeURI is not 
intended to be a full and
complete implementation of checking whether a URI is path-rootless. 
Instead, it is used in
exactly 3 places, and always in conjunction with URI.create.  
JavacFileManager is assuming
the full syntax checking is done by URI.create, and is just using a 
simple impl of
isRelativeURI to distinguish relative URIs from absolute URIs created by 
URI.create.

6419701 is about removing the use of URI.create -- presumably because it 
is mildly icky
to create the URI object just to check whether a path string is a valid 
URI.  So it seems
to me that there are two ways to take this issue: 
1) Rewrite isRelativeURI to take a String argument and thereby avoid the 
use of URI.create
2) Wait for URI to have some better method for checking the validity of 
a path without
actually constructing the URI object.

I guess that I dislike JavacFileManager having code for detailed parsing 
of URIs, and so
I think the current impl is better, of using URI.create to check the 
syntax of a URI, and
then apply a quick check as to whether it is absolute or relative is better.

Or am I misreading the situation or perhaps missing some subtlety in 
your proposed code?

-- Jon


Emil Andreas Siemes wrote:
> com.sun.tools.javac.file.JavacFileManager checks if a name fulfills 
> the requirements of relative names:
> "A relative name is a non-null, non-empty sequence of path segments 
> separated by |'/'|; |'.'| and |'..'| are invalid path segments. A 
> valid relative name must match the "path-rootless" rule of RFC 3986 
> <http://www.ietf.org/rfc/rfc3986.txt>, section 3.3."
>
> This is done via the isRelativeUri() method. Unfortunately this method 
> doesn't currently really check for path-rootless compliance. A patch 
> with an improved method is attached.
> When java.net.Uri eventually supports RFC 3986 the need for 
> isRelativeUri() goes away. I would also like to propose to rename 
> isRelativeUri() to isRF3986PathRootless() which would more clearly 
> describe what the method does.
>
> There is a comment in JavacFileManager in a couple of lines:
> //FIX ME 6419701
> but I don't find bug 6419701 in the bug database. Any thoughts?
>
> Thanks
>     Emil
>
>
>
>
>  
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20090105/0db5ce8a/attachment.html 

From digitalemil at yahoo.de  Tue Jan  6 08:21:16 2009
From: digitalemil at yahoo.de (Emil Siemes)
Date: Tue, 6 Jan 2009 16:21:16 +0000 (GMT)
Subject: AW: [Patch] 6502392 Invalid relative names for Filer.createResource
	and Filer.getResource
References: <5DF426C2-99DC-4E72-8C98-3933A034918E@yahoo.de>
	<4962AFBA.2090900@sun.com>
Message-ID: <813911.52511.qm@web23008.mail.ird.yahoo.com>

Hi Jon,

true, the code actually does things which would belong into java.net.URI. Reason for this is that JSR269 requires compliance with path-rootless rule of RFC3986 whereas java.net.URI supports the older and obsolete RFC 2396. Basically I was afraid of relying on the old implementation but that can be changed of course.
Given the limitation of the actual URI implementation it might be tricky to achieve compliance with the JSR269 requirements without parsing URI.getPath(). Dot-segments are not allowed as relative path names in JSR269 but are fine for the URI class. The current implementation calls URI.normalize().getPath() which actually removes dot-segments and therefore doesn't throw an exception. 

Given your feedback I propose I rewrite my code in a way that it relies on java.net.URI and does a quick check on the path. May be I can compare URI.getPath() and URI.normalize().getPath() to find out if any dot-segments are part of the path. I'll check and let you know.

Thanks
   Emil


 




________________________________
Von: Jonathan Gibbons <Jonathan.Gibbons at Sun.COM>
An: Emil Andreas Siemes <digitalemil at yahoo.de>
CC: compiler-dev at openjdk.java.net
Gesendet: Dienstag, den 6. Januar 2009, 02:11:22 Uhr
Betreff: Re: [Patch] 6502392 Invalid relative names for Filer.createResource and Filer.getResource

Emil,

Thank you for looking at this, and for your patch.

I do not understand why 6419701 is not public. I am trying to find out
why it is not.
The bug itself is about the use of URI.create, not about the use of
isRelativeURI.

I'm not sure that your patch is warranted (or arguably, the correct
fix).  Your patch certainly 
contains functionality that on the face of it would better belong in
java.net..URI and not 
JavacFileManager. 

The way I read the code in JavacFileManager, isRelativeURI is not
intended to be a full and 
complete implementation of checking whether a URI is path-rootless.
Instead, it is used in 
exactly 3 places, and always in conjunction with URI.create. 
JavacFileManager is assuming 
the full syntax checking is done by URI.create, and is just using a
simple impl of 
isRelativeURI to distinguish relative URIs from absolute URIs created
by URI.create.

6419701 is about removing the use of URI.create -- presumably because
it is mildly icky
to create the URI object just to check whether a path string is a valid
URI.  So it seems 
to me that there are two ways to take this issue:  
1) Rewrite isRelativeURI to take a String argument and thereby avoid
the use of URI.create
2) Wait for URI to have some better method for checking the validity of
a path without
actually constructing the URI object..

I guess that I dislike JavacFileManager having code for detailed
parsing of URIs, and so
I think the current impl is better, of using URI.create to check the
syntax of a URI, and
then apply a quick check as to whether it is absolute or relative is
better.

Or am I misreading the situation or perhaps missing some subtlety in
your proposed code?

-- Jon


Emil Andreas Siemes wrote: 
com.sun.tools.javac.file.JavacFileManager checks if a name
fulfills the requirements of relative names:

"A relative name is a
non-null, non-empty sequence of path segments separated by '/'; '.' and '..' are
invalid path segments. A valid relative name must match the
"path-rootless" rule of RFC 3986, section 3.3."

This is done via the isRelativeUri() method. Unfortunately this
method doesn't currently really check for path-rootless compliance. A
patch with an improved method is attached.
When java.net.Uri eventually supports RFC 3986 the need for
isRelativeUri() goes away. I would also like to propose to rename
isRelativeUri() to isRF3986PathRootless() which would more clearly
describe what the method does.

There is a comment in JavacFileManager in a couple of lines:
//FIX ME 6419701
but I don't find bug 6419701 in the bug database. Any thoughts?

Thanks
    Emil




 
________________________________


________________________________


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20090106/22126b1d/attachment.html 

From digitalemil at yahoo.de  Tue Jan  6 09:35:04 2009
From: digitalemil at yahoo.de (Emil Andreas Siemes)
Date: Tue, 6 Jan 2009 18:35:04 +0100
Subject: AW: AW: AW: 6502395: Is not a bug
Message-ID: <540A46B0-ABB5-47AB-911B-0249BDCA644E@yahoo.de>

Hi Jon,

regarding the bug as it is reported nothing changed:
"When we are trying to open nonexistent resource we should expect  
IOException thrown.
However getting nonexistent resource doesn't cause to IOException.  
Instead IllegalStateExceptionis thrown."
This is because the bug report uses createResource().openReader() and  
not getResource().openReader() and throwing IllegalStateException is  
expected in this case.
Nevertheless there is an issue with the current implementations:
JDK6u11:
getResource(... "unexisting-resource" ...) doesn't throw any  
exception. Ugly, spec is says IOException has to be thrown.
getResource(... "unexisting-resource" ...).openReader() throws  
UnsupportedOperationException. Ugly.

OpenJDK7 (b18, b24, 41 & 42):
getResource(... "unexisting-resource" ...) doesn't throw any  
exception. Ugly, spec is says IOException has to be thrown.
getResource(... "unexisting-resource" ...).openReader() throws  
FileNotFoundException. Better.

Let me investigate where we can insert a check for the existence of  
the file to be opened. Then we can throw FileNotFound in  
getResource()...
Thanks
Emil






Von: Jonathan Gibbons <Jonathan.Gibbons at Sun.COM>
An: Emil Siemes <digitalemil at yahoo.de>
CC: compiler-dev at openjdk.java.net
Gesendet: Dienstag, den 6. Januar 2009, 00:07:16 Uhr
Betreff: Re: AW: AW: 6502395: Is not a bug

Emil,

The spec is what it is, and cannot easily be changed. And, being  
pedantic, the spec does not require the file
to be opened; it merely says that an exception must be thrown if the  
file cannot be opened. The implementation
may perform a number of checks to determine whether the file can be  
opened in principle without actually
opening it.

What is your current disposition regarding this bug?  Are you now  
saying the javac behavior and the test's
behavior are now both correct?

-- Jon



Emil Siemes wrote:
>
> Seems I was a bit too fast. When I tried b18 (see last mail) the  
> path to java was correct but I still used JDK6u11 javac.
> After correcting the setup b18 also throws FileNotFoundException  
> (which is the correct behavior). So the bug was fixed before b18.
>
> But the method which throws the exception in the following code
> "FileObject fo = filer.getResource(location, "", "foo/" + location +  
> ".unexisting");
> Reader reader = fo.openReader(true);"
> is openReader not getResource as the spec suggests:
>
> java.io.FileNotFoundException: foo/SOURCE_OUTPUT.unexisting (No such  
> file or directory)
>     at java.io.FileInputStream.open(Native Method)
>     at java.io.FileInputStream.<init>(FileInputStream.java:137)
>     at  
> com 
> .sun 
> .tools 
> .javac.file.RegularFileObject.openInputStream(RegularFileObject.java: 
> 68)
>     at  
> com 
> .sun.tools.javac.file.BaseFileObject.openReader(BaseFileObject.java: 
> 76)
>
>
> getResource
>
> FileObject getResource(JavaFileManager.Location location,
>                        CharSequence pkg,
>                        CharSequence relativeName)
>                        throws IOException
> Returns an object for reading an existing resource. The locations  
> CLASS_OUTPUT andSOURCE_OUTPUT must be supported.
> Parameters:
> location - location of the file
> pkg - package relative to which the file should be searched, or the  
> empty string if none
> relativeName - final pathname components of the file
> Returns:
> an object to read the file
> Throws:
> FilerException - if the same pathname has already been opened for  
> writing
> IOException - if the file cannot be opened
> I'm challenging the spec a bit. Why should getResource() open the  
> file at all? I think the normal behavior is like in the bug report:
> getResource and then try opening the resource and expecting an  
> exception if it fails. And as we see this is how the implementation  
> works: getResource() returns a FileObject but doesn't open it and  
> doesn't test if the file could be openend.
>
> Any thoughts?
>
>
>
>
>
>
>
>
> Von: Emil Siemes <digitalemil at yahoo.de>
> An: Mark Wielaard <mark at klomp.org>
> CC: compiler-dev at openjdk.java.net; Jonathan Gibbons <Jonathan.Gibbons at Sun.COM 
> >
> Gesendet: Dienstag, den 16. Dezember 2008, 14:01:24 Uhr
> Betreff: AW: 6502395: Is not a bug
>
> Hi Mark,
>
> thanks for the links. I was able to test b18 and at least this build  
> still throws UnsupportedOperationException.
> I now wanted to follow-up the path but it seems that the  
> fedoraproject has some database issues...
> Will try again later. And yes a central repository with all old  
> binary & source bundles would be helpful.
>
> Thanks
>   Emil
>
> Von: Mark Wielaard <mark at klomp.org>
> An: Dalibor Topic <Dalibor.Topic at Sun.COM>
> CC: Jonathan Gibbons <Jonathan.Gibbons at Sun.COM>; compiler-dev at openjdk.java.net
> Gesendet: Samstag, den 13. Dezember 2008, 21:52:15 Uhr
> Betreff: Re: 6502395: Is not a bug
>
> On Sat, 2008-12-13 at 21:25 +0100, Dalibor Topic wrote:
> > Martin Buchholz wrote:
> > > On Fri, Dec 12, 2008 at 08:56, Jonathan Gibbons
> > > <Jonathan.Gibbons at sun.com> wrote:
> > >
> > >> Like you, I could not find public builds for JDK7 builds  
> earlier than b36. I
> > >> am sorry (and somewhat surprised) that they are not available.
> > >
> > > I complained about this elsewhere.
> > > Lack of hardware resources to hold the archives were cited.
> > >
> > > I'd like to see every build remain available for download for at  
> least 3 years.
> >
> > Did I hear someone volunteering to build & maintain a mirror? ;)
>
> We do keep a mirror of the old GPL sources (which came from the svn
> repository) in mercurial at http://icedtea.classpath.org/hg/openjdk if
> anybody needs anything early (b13 till b23). Although the changes
> between the bxx drops are somewhat big, you can do some simple
> investigations against it through mercurial.
>
> Also various GNU/Linux distros still have old GPL binary icedtea/ 
> openjdk
> 1.7 packages (and source code of course) around (although most are
> tracking jdk6 these days). Here are old builds of the 1.7.0 tree (b18
> till b24) for Fedora 8/9 for example:
> http://koji.fedoraproject.org/koji/packageinfo?packageID=4946
>
> Cheers,
>
> Mark
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20090106/f85e8dfd/attachment.html 

From digitalemil at yahoo.de  Tue Jan  6 09:35:04 2009
From: digitalemil at yahoo.de (Emil Andreas Siemes)
Date: Tue, 6 Jan 2009 18:35:04 +0100
Subject: AW: AW: AW: 6502395: Is not a bug
Message-ID: <540A46B0-ABB5-47AB-911B-0249BDCA644E@yahoo.de>

Hi Jon,

regarding the bug as it is reported nothing changed:
"When we are trying to open nonexistent resource we should expect  
IOException thrown.
However getting nonexistent resource doesn't cause to IOException.  
Instead IllegalStateExceptionis thrown."
This is because the bug report uses createResource().openReader() and  
not getResource().openReader() and throwing IllegalStateException is  
expected in this case.
Nevertheless there is an issue with the current implementations:
JDK6u11:
getResource(... "unexisting-resource" ...) doesn't throw any  
exception. Ugly, spec is says IOException has to be thrown.
getResource(... "unexisting-resource" ...).openReader() throws  
UnsupportedOperationException. Ugly.

OpenJDK7 (b18, b24, 41 & 42):
getResource(... "unexisting-resource" ...) doesn't throw any  
exception. Ugly, spec is says IOException has to be thrown.
getResource(... "unexisting-resource" ...).openReader() throws  
FileNotFoundException. Better.

Let me investigate where we can insert a check for the existence of  
the file to be opened. Then we can throw FileNotFound in  
getResource()...
Thanks
Emil






Von: Jonathan Gibbons <Jonathan.Gibbons at Sun.COM>
An: Emil Siemes <digitalemil at yahoo.de>
CC: compiler-dev at openjdk.java.net
Gesendet: Dienstag, den 6. Januar 2009, 00:07:16 Uhr
Betreff: Re: AW: AW: 6502395: Is not a bug

Emil,

The spec is what it is, and cannot easily be changed. And, being  
pedantic, the spec does not require the file
to be opened; it merely says that an exception must be thrown if the  
file cannot be opened. The implementation
may perform a number of checks to determine whether the file can be  
opened in principle without actually
opening it.

What is your current disposition regarding this bug?  Are you now  
saying the javac behavior and the test's
behavior are now both correct?

-- Jon



Emil Siemes wrote:
>
> Seems I was a bit too fast. When I tried b18 (see last mail) the  
> path to java was correct but I still used JDK6u11 javac.
> After correcting the setup b18 also throws FileNotFoundException  
> (which is the correct behavior). So the bug was fixed before b18.
>
> But the method which throws the exception in the following code
> "FileObject fo = filer.getResource(location, "", "foo/" + location +  
> ".unexisting");
> Reader reader = fo.openReader(true);"
> is openReader not getResource as the spec suggests:
>
> java.io.FileNotFoundException: foo/SOURCE_OUTPUT.unexisting (No such  
> file or directory)
>     at java.io.FileInputStream.open(Native Method)
>     at java.io.FileInputStream.<init>(FileInputStream.java:137)
>     at  
> com 
> .sun 
> .tools 
> .javac.file.RegularFileObject.openInputStream(RegularFileObject.java: 
> 68)
>     at  
> com 
> .sun.tools.javac.file.BaseFileObject.openReader(BaseFileObject.java: 
> 76)
>
>
> getResource
>
> FileObject getResource(JavaFileManager.Location location,
>                        CharSequence pkg,
>                        CharSequence relativeName)
>                        throws IOException
> Returns an object for reading an existing resource. The locations  
> CLASS_OUTPUT andSOURCE_OUTPUT must be supported.
> Parameters:
> location - location of the file
> pkg - package relative to which the file should be searched, or the  
> empty string if none
> relativeName - final pathname components of the file
> Returns:
> an object to read the file
> Throws:
> FilerException - if the same pathname has already been opened for  
> writing
> IOException - if the file cannot be opened
> I'm challenging the spec a bit. Why should getResource() open the  
> file at all? I think the normal behavior is like in the bug report:
> getResource and then try opening the resource and expecting an  
> exception if it fails. And as we see this is how the implementation  
> works: getResource() returns a FileObject but doesn't open it and  
> doesn't test if the file could be openend.
>
> Any thoughts?
>
>
>
>
>
>
>
>
> Von: Emil Siemes <digitalemil at yahoo.de>
> An: Mark Wielaard <mark at klomp.org>
> CC: compiler-dev at openjdk.java.net; Jonathan Gibbons <Jonathan.Gibbons at Sun.COM 
> >
> Gesendet: Dienstag, den 16. Dezember 2008, 14:01:24 Uhr
> Betreff: AW: 6502395: Is not a bug
>
> Hi Mark,
>
> thanks for the links. I was able to test b18 and at least this build  
> still throws UnsupportedOperationException.
> I now wanted to follow-up the path but it seems that the  
> fedoraproject has some database issues...
> Will try again later. And yes a central repository with all old  
> binary & source bundles would be helpful.
>
> Thanks
>   Emil
>
> Von: Mark Wielaard <mark at klomp.org>
> An: Dalibor Topic <Dalibor.Topic at Sun.COM>
> CC: Jonathan Gibbons <Jonathan.Gibbons at Sun.COM>; compiler-dev at openjdk.java.net
> Gesendet: Samstag, den 13. Dezember 2008, 21:52:15 Uhr
> Betreff: Re: 6502395: Is not a bug
>
> On Sat, 2008-12-13 at 21:25 +0100, Dalibor Topic wrote:
> > Martin Buchholz wrote:
> > > On Fri, Dec 12, 2008 at 08:56, Jonathan Gibbons
> > > <Jonathan.Gibbons at sun.com> wrote:
> > >
> > >> Like you, I could not find public builds for JDK7 builds  
> earlier than b36. I
> > >> am sorry (and somewhat surprised) that they are not available.
> > >
> > > I complained about this elsewhere.
> > > Lack of hardware resources to hold the archives were cited.
> > >
> > > I'd like to see every build remain available for download for at  
> least 3 years.
> >
> > Did I hear someone volunteering to build & maintain a mirror? ;)
>
> We do keep a mirror of the old GPL sources (which came from the svn
> repository) in mercurial at http://icedtea.classpath.org/hg/openjdk if
> anybody needs anything early (b13 till b23). Although the changes
> between the bxx drops are somewhat big, you can do some simple
> investigations against it through mercurial.
>
> Also various GNU/Linux distros still have old GPL binary icedtea/ 
> openjdk
> 1.7 packages (and source code of course) around (although most are
> tracking jdk6 these days). Here are old builds of the 1.7.0 tree (b18
> till b24) for Fedora 8/9 for example:
> http://koji.fedoraproject.org/koji/packageinfo?packageID=4946
>
> Cheers,
>
> Mark
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20090106/f85e8dfd/attachment-0001.html 

From tomas.hurka at sun.com  Wed Jan  7 05:10:18 2009
From: tomas.hurka at sun.com (tomas.hurka at sun.com)
Date: Wed, 07 Jan 2009 13:10:18 +0000
Subject: hg: jdk7/tl/jdk: 6790467: Add test for setInterval() for local
	MonitoredHost and local MonitoredVm
Message-ID: <20090107131032.CA69DD1AB@hg.openjdk.java.net>

Changeset: 0bd360988b3a
Author:    thurka
Date:      2009-01-07 14:06 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0bd360988b3a

6790467: Add test for setInterval() for local MonitoredHost and local MonitoredVm
Summary: test for MonitoredHost.setInterval() and MonitoredVm.setInterval() added
Reviewed-by: swamyv

+ test/sun/jvmstat/monitor/MonitoredVm/CR6672135.java



From Jonathan.Gibbons at Sun.COM  Wed Jan  7 09:07:35 2009
From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons)
Date: Wed, 07 Jan 2009 09:07:35 -0800
Subject: AW: [Patch] 6502392 Invalid relative names for
	Filer.createResource and Filer.getResource
In-Reply-To: <813911.52511.qm@web23008.mail.ird.yahoo.com>
References: <5DF426C2-99DC-4E72-8C98-3933A034918E@yahoo.de>
	<4962AFBA.2090900@sun.com>
	<813911.52511.qm@web23008.mail.ird.yahoo.com>
Message-ID: <61E948E5-BCD3-444B-BFE0-BBA50C8CBB37@Sun.COM>

Emil,

First, some updates.
1) 6791041 has come in, which reports a specific instance of a user  
encountering the issue you have been looking at. Specifically,
the submitter is affected by the "quick and dirty" check in  
isRelativeURI.
2) I have filed 6791060 against java.net.URI

It sounds like you are reasonably familiar with the RFCs involved  
here. If so, can you briefly summarize any relevant differences
between RFC 2396 (used by java.net.URI) and RFC 3986 (used by JSR 269  
and Filer.)

-- Jon

On Jan 6, 2009, at 8:21 AM, Emil Siemes wrote:

> Hi Jon,
>
> true, the code actually does things which would belong into  
> java.net.URI. Reason for this is that JSR269 requires compliance  
> with path-rootless rule of RFC3986 whereas java.net.URI supports the  
> older and obsolete RFC 2396. Basically I was afraid of relying on  
> the old implementation but that can be changed of course.
> Given the limitation of the actual URI implementation it might be  
> tricky to achieve compliance with the JSR269 requirements without  
> parsing URI.getPath(). Dot-segments are not allowed as relative path  
> names in JSR269 but are fine for the URI class. The current  
> implementation calls URI.normalize().getPath() which actually  
> removes dot-segments and therefore doesn't throw an exception.
>
> Given your feedback I propose I rewrite my code in a way that it  
> relies on java.net.URI and does a quick check on the path. May be I  
> can compare URI.getPath() and URI.normalize().getPath() to find out  
> if any dot-segments are part of the path. I'll check and let you know.
>
> Thanks
>    Emil
>
>
>
>
>
> Von: Jonathan Gibbons <Jonathan.Gibbons at Sun.COM>
> An: Emil Andreas Siemes <digitalemil at yahoo.de>
> CC: compiler-dev at openjdk.java.net
> Gesendet: Dienstag, den 6. Januar 2009, 02:11:22 Uhr
> Betreff: Re: [Patch] 6502392 Invalid relative names for  
> Filer.createResource and Filer.getResource
>
> Emil,
>
> Thank you for looking at this, and for your patch.
>
> I do not understand why 6419701 is not public. I am trying to find  
> out why it is not.
> The bug itself is about the use of URI.create, not about the use of  
> isRelativeURI..
>
> I'm not sure that your patch is warranted (or arguably, the correct  
> fix).  Your patch certainly
> contains functionality that on the face of it would better belong in  
> java.net.URI and not
> JavacFileManager.
>
> The way I read the code in JavacFileManager, isRelativeURI is not  
> intended to be a full and
> complete implementation of checking whether a URI is path-rootless.  
> Instead, it is used in
> exactly 3 places, and always in conjunction with URI.create.   
> JavacFileManager is assuming
> the full syntax checking is done by URI.create, and is just using a  
> simple impl of
> isRelativeURI to distinguish relative URIs from absolute URIs  
> created by URI.create.
>
> 6419701 is about removing the use of URI.create -- presumably  
> because it is mildly icky
> to create the URI object just to check whether a path string is a  
> valid URI.  So it seems
> to me that there are two ways to take this issue:
> 1) Rewrite isRelativeURI to take a String argument and thereby avoid  
> the use of URI.create
> 2) Wait for URI to have some better method for checking the validity  
> of a path without
> actually constructing the URI object.
>
> I guess that I dislike JavacFileManager having code for detailed  
> parsing of URIs, and so
> I think the current impl is better, of using URI.create to check the  
> syntax of a URI, and
> then apply a quick check as to whether it is absolute or relative is  
> better.
>
> Or am I misreading the situation or perhaps missing some subtlety in  
> your proposed code?
>
> -- Jon
>
>
> Emil Andreas Siemes wrote:
>>
>> com.sun.tools.javac.file.JavacFileManager checks if a name fulfills  
>> the requirements of relative names:
>> "A relative name is a non-null, non-empty sequence of path segments  
>> separated by '/'; '.' and '..' are invalid path segments. A valid  
>> relative name must match the "path-rootless" rule of RFC 3986,  
>> section 3.3."
>>
>> This is done via the isRelativeUri() method. Unfortunately this  
>> method doesn't currently really check for path-rootless compliance.  
>> A patch with an improved method is attached.
>> When java.net.Uri eventually supports RFC 3986 the need for  
>> isRelativeUri() goes away. I would also like to propose to rename  
>> isRelativeUri() to isRF3986PathRootless() which would more clearly  
>> describe what the method does.
>>
>> There is a comment in JavacFileManager in a couple of lines:
>> //FIX ME 6419701
>> but I don't find bug 6419701 in the bug database. Any thoughts?
>>
>> Thanks
>>     Emil
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20090107/238d7cf5/attachment.html 

From martinrb at google.com  Wed Jan  7 11:59:15 2009
From: martinrb at google.com (martinrb at google.com)
Date: Wed, 07 Jan 2009 19:59:15 +0000
Subject: hg: jdk7/tl/jdk: 6788196: (porting) Bounds checks in io_util.c rely
	on undefined behaviour
Message-ID: <20090107195932.6C8A1D264@hg.openjdk.java.net>

Changeset: ff572b4f1ca4
Author:    martin
Date:      2009-01-07 11:50 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ff572b4f1ca4

6788196: (porting) Bounds checks in io_util.c rely on undefined behaviour
Reviewed-by: alanb
Contributed-by: gbenson at redhat.com

! src/share/native/java/io/io_util.c
! test/java/io/readBytes/ReadBytesBounds.java



From Jonathan.Gibbons at Sun.COM  Wed Jan  7 12:36:16 2009
From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons)
Date: Wed, 07 Jan 2009 12:36:16 -0800
Subject: [PATCH] 6512707: "incompatible types" after (unrelated) annotation
	processing [SEC=UNCLASSIFIED]
In-Reply-To: <D3EDEECE9CFD7E49A23A075D287A710E019BD404@ACT01EXC01.internal.govt>
References: <D3EDEECE9CFD7E49A23A075D287A710E019BD3FE@ACT01EXC01.internal.govt>
	<D3EDEECE9CFD7E49A23A075D287A710E019BD404@ACT01EXC01.internal.govt>
Message-ID: <49651240.2080102@sun.com>

Nice patch; thanks.

Very minor quibbles, for the record:
-- all source files should end in a single newline
-- most test source files should have a copyright block; the only 
exception is when
the source file is used in a jtreg "golden file" test, so that the line 
numbers in the
source file are significant. In this case, the test description should 
contain the
magic string /nodynamiccopyright/ 
This should be explained in the OpenJDK developer's handbook.

I'll fix these issues in your patch.

-- Jon


Peter Runge wrote:
> Attached is the patch for the TreeScanner fix described previously.
> Test cases included.
>
> I only sent off the SCA yesterday via e-mail so it might be some time
> before it is processed.
>
> Regards,
>
> Peter
>
> If you have received this email in error, please notify the sender immediately and erase all copies of the email and any attachments to it. The information contained in this email and any attachments may be private, confidential and legally privileged or the subject of copyright. If you are not the addressee it may be illegal to review, disclose, use, forward, or distribute this email and/or its contents.
>  
> Unless otherwise specified, the information in the email and any attachments is intended as a guide only and should not be relied upon as legal or technical advice or regarded as a substitute for legal or technical advice in individual cases. Opinions contained in this email or any of its attachments do not necessarily reflect the opinions of ACMA.
>   



From jonathan.gibbons at sun.com  Wed Jan  7 14:50:36 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Wed, 07 Jan 2009 22:50:36 +0000
Subject: hg: jdk7/tl/langtools: 6512707: "incompatible types" after
	(unrelated) annotation processing
Message-ID: <20090107225038.5A5FAD281@hg.openjdk.java.net>

Changeset: 7a595d92e252
Author:    jjg
Date:      2009-01-07 14:48 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/7a595d92e252

6512707: "incompatible types" after (unrelated) annotation processing
Reviewed-by: darcy
Contributed-by: prunge at velocitynet.com.au

! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java
+ test/tools/javac/processing/6512707/T6512707.java
+ test/tools/javac/processing/6512707/TestAnnotation.java
+ test/tools/javac/processing/6512707/TestEnum.java



From Peter.Runge at acma.gov.au  Wed Jan  7 16:09:41 2009
From: Peter.Runge at acma.gov.au (Peter Runge)
Date: Thu, 8 Jan 2009 11:09:41 +1100
Subject: [PATCH] 6512707: "incompatible types" after (unrelated)
	annotation processing [SEC=UNCLASSIFIED]
In-Reply-To: <49651240.2080102@sun.com>
References: <D3EDEECE9CFD7E49A23A075D287A710E019BD3FE@ACT01EXC01.internal.govt>
	<D3EDEECE9CFD7E49A23A075D287A710E019BD404@ACT01EXC01.internal.govt>
	<49651240.2080102@sun.com>
Message-ID: <D3EDEECE9CFD7E49A23A075D287A710E019BD40A@ACT01EXC01.internal.govt>

Thanks Jon.  I'll remember those points for the next time.

Peter

-----Original Message-----
From: Jonathan.Gibbons at Sun.COM [mailto:Jonathan.Gibbons at Sun.COM]
Sent: Thursday, 8 January 2009 7:36 AM
To: Peter Runge
Cc: compiler-dev at openjdk.java.net
Subject: Re: [PATCH] 6512707: "incompatible types" after (unrelated)
annotation processing [SEC=UNCLASSIFIED]

Nice patch; thanks.

Very minor quibbles, for the record:
-- all source files should end in a single newline
-- most test source files should have a copyright block; the only
exception is when the source file is used in a jtreg "golden file" test,
so that the line numbers in the source file are significant. In this
case, the test description should contain the magic string
/nodynamiccopyright/ This should be explained in the OpenJDK developer's
handbook.

I'll fix these issues in your patch.

-- Jon


Peter Runge wrote:
> Attached is the patch for the TreeScanner fix described previously.
> Test cases included.
>
> I only sent off the SCA yesterday via e-mail so it might be some time 
> before it is processed.
>
> Regards,
>
> Peter
>
> If you have received this email in error, please notify the sender
immediately and erase all copies of the email and any attachments to it.
The information contained in this email and any attachments may be
private, confidential and legally privileged or the subject of
copyright. If you are not the addressee it may be illegal to review,
disclose, use, forward, or distribute this email and/or its contents.
>  
> Unless otherwise specified, the information in the email and any
attachments is intended as a guide only and should not be relied upon as
legal or technical advice or regarded as a substitute for legal or
technical advice in individual cases. Opinions contained in this email
or any of its attachments do not necessarily reflect the opinions of
ACMA.
>   


If you have received this email in error, please notify the sender immediately and erase all copies of the email and any attachments to it. The information contained in this email and any attachments may be private, confidential and legally privileged or the subject of copyright. If you are not the addressee it may be illegal to review, disclose, use, forward, or distribute this email and/or its contents.
 
Unless otherwise specified, the information in the email and any attachments is intended as a guide only and should not be relied upon as legal or technical advice or regarded as a substitute for legal or technical advice in individual cases. Opinions contained in this email or any of its attachments do not necessarily reflect the opinions of ACMA.


From Jonathan.Gibbons at Sun.COM  Wed Jan  7 16:46:02 2009
From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons)
Date: Wed, 07 Jan 2009 16:46:02 -0800
Subject: [PATCH] 6512707: "incompatible types" after (unrelated)	annotation
	processing [SEC=UNCLASSIFIED]
In-Reply-To: <D3EDEECE9CFD7E49A23A075D287A710E019BD40A@ACT01EXC01.internal.govt>
References: <D3EDEECE9CFD7E49A23A075D287A710E019BD3FE@ACT01EXC01.internal.govt>
	<D3EDEECE9CFD7E49A23A075D287A710E019BD404@ACT01EXC01.internal.govt>
	<49651240.2080102@sun.com>
	<D3EDEECE9CFD7E49A23A075D287A710E019BD40A@ACT01EXC01.internal.govt>
Message-ID: <49654CCA.1070005@sun.com>

And thanks again to you for the patch; it's already been pushed to the tl/
build area, and it looks like it will be in b44, according to the 
schedule at
http://openjdk.java.net/projects/jdk7/builds/

-- Jon


Peter Runge wrote:
> Thanks Jon.  I'll remember those points for the next time.
>
> Peter
>
> -----Original Message-----
> From: Jonathan.Gibbons at Sun.COM [mailto:Jonathan.Gibbons at Sun.COM]
> Sent: Thursday, 8 January 2009 7:36 AM
> To: Peter Runge
> Cc: compiler-dev at openjdk.java.net
> Subject: Re: [PATCH] 6512707: "incompatible types" after (unrelated)
> annotation processing [SEC=UNCLASSIFIED]
>
> Nice patch; thanks.
>
> Very minor quibbles, for the record:
> -- all source files should end in a single newline
> -- most test source files should have a copyright block; the only
> exception is when the source file is used in a jtreg "golden file" test,
> so that the line numbers in the source file are significant. In this
> case, the test description should contain the magic string
> /nodynamiccopyright/ This should be explained in the OpenJDK developer's
> handbook.
>
> I'll fix these issues in your patch.
>
> -- Jon
>
>
> Peter Runge wrote:
>   
>> Attached is the patch for the TreeScanner fix described previously.
>> Test cases included.
>>
>> I only sent off the SCA yesterday via e-mail so it might be some time 
>> before it is processed.
>>
>> Regards,
>>
>> Peter
>>
>> If you have received this email in error, please notify the sender
>>     
> immediately and erase all copies of the email and any attachments to it.
> The information contained in this email and any attachments may be
> private, confidential and legally privileged or the subject of
> copyright. If you are not the addressee it may be illegal to review,
> disclose, use, forward, or distribute this email and/or its contents.
>   
>>  
>> Unless otherwise specified, the information in the email and any
>>     
> attachments is intended as a guide only and should not be relied upon as
> legal or technical advice or regarded as a substitute for legal or
> technical advice in individual cases. Opinions contained in this email
> or any of its attachments do not necessarily reflect the opinions of
> ACMA.
>   
>>   
>>     
>
>
> If you have received this email in error, please notify the sender immediately and erase all copies of the email and any attachments to it. The information contained in this email and any attachments may be private, confidential and legally privileged or the subject of copyright. If you are not the addressee it may be illegal to review, disclose, use, forward, or distribute this email and/or its contents.
>  
> Unless otherwise specified, the information in the email and any attachments is intended as a guide only and should not be relied upon as legal or technical advice or regarded as a substitute for legal or technical advice in individual cases. Opinions contained in this email or any of its attachments do not necessarily reflect the opinions of ACMA.
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20090107/3626f2ff/attachment.html 

From digitalemil at yahoo.de  Thu Jan  8 13:20:51 2009
From: digitalemil at yahoo.de (Emil Siemes)
Date: Thu, 8 Jan 2009 21:20:51 +0000 (GMT)
Subject: AW: AW: [Patch] 6502392 Invalid relative names for
	Filer.createResource and Filer.getResource
References: <5DF426C2-99DC-4E72-8C98-3933A034918E@yahoo.de>
	<4962AFBA.2090900@sun.com>
	<813911.52511.qm@web23008.mail.ird.yahoo.com>
	<61E948E5-BCD3-444B-BFE0-BBA50C8CBB37@Sun.COM>
Message-ID: <418326.20769.qm@web23003.mail.ird.yahoo.com>

Hi Jon,

RFC 3986 Appendix D describes the additions and modifications vs. 2396.
Basically 3986 tries to make things clearer. They say there have been a lot of discussions and different interpretations of 2396. (Sounds like JME fragmentation to me ;-)
A new ABNF was used, IPV6 literals added.. URI normalization and comparison was rewritten.
Clarification of reserved and unreserved characters. Support for an empty path component were added.
6791041 & 6791060 seem to be non-public. Will this change soon? I were not able to find them on bugs.sun.com
If there is more information available on 6791041 I could look for potential interpretation issues in the java.net.URI implementation vs. 3986 spec.

I should have a new isRelativeURI Monday latest. Would be good to know what 6791041 is about by then.

For the missing FileNotFoundException in JavacFiler I think the clearest solution is to explicitly check for file existence in the method. 
Something like:

getResource(...

FileObject fileobject= ...

if(!new File(fileobject.toURI().exists())
     throw new FileNotFoundException();
}

Unfortunately this would include another creation of an URI object but FileObject.getName() only returns a "user friendly" file name which I understand is not necessarily useable for a File-Object creation.
The fileobject involved in getResource & createResource is actually a com.sun..tools.javac.file.RegularFileObject with a File object as field. So another solution would be to either expose this File object or add an exists() method to RegularFileObject which delegates the call to file Object and cast the FileObject to a RegularFileObject. (too ugly I believe).

Thanks
   Emil












________________________________
Von: Jonathan Gibbons <Jonathan.Gibbons at Sun.COM>
An: Emil Siemes <digitalemil at yahoo.de>
CC: compiler-dev at openjdk.java.net
Gesendet: Mittwoch, den 7. Januar 2009, 18:07:35 Uhr
Betreff: Re: AW: [Patch] 6502392 Invalid relative names for Filer.createResource and Filer.getResource

Emil,

First, some updates.
1) 6791041 has come in, which reports a specific instance of a user encountering the issue you have been looking at. Specifically,
the submitter is affected by the "quick and dirty" check in isRelativeURI.
2) I have filed 6791060 against java.net.URI

It sounds like you are reasonably familiar with the RFCs involved here. If so, can you briefly summarize any relevant differences
between RFC 2396 (used by java.net.URI) and RFC 3986 (used by JSR 269 and Filer.)

-- Jon


On Jan 6, 2009, at 8:21 AM, Emil Siemes wrote:

Hi Jon,

true, the code actually does things which would belong into java.net.URI. Reason for this is that JSR269 requires compliance with path-rootless rule of RFC3986 whereas java.net.URI supports the older and obsolete RFC 2396. Basically I was afraid of relying on the old implementation but that can be changed of course.
Given the limitation of the actual URI implementation it might be tricky to achieve compliance with the JSR269 requirements without parsing URI.getPath(). Dot-segments are not allowed as relative path names in JSR269 but are fine for the URI class. The current implementation calls URI.normalize().getPath() which actually removes dot-segments and therefore doesn't throw an exception. 

Given your feedback I propose I rewrite my code in a way that it relies on java.net.URI and does a quick check on the path. May be I can compare URI.getPath() and URI.normalize().getPath() to find out if any dot-segments are part of the path. I'll check and let you know.

Thanks
   Emil


 




________________________________
Von: Jonathan Gibbons <Jonathan.Gibbons at Sun.COM>
An: Emil Andreas Siemes <digitalemil at yahoo.de>
CC: compiler-dev at openjdk.java.net
Gesendet: Dienstag, den 6. Januar 2009, 02:11:22 Uhr
Betreff: Re: [Patch] 6502392 Invalid relative names for Filer.createResource and Filer.getResource

Emil,

Thank you for looking at this, and for your patch.

I do not understand why 6419701 is not public. I am trying to find out why it is not..
The bug itself is about the use of URI.create, not about the use of isRelativeURI..

I'm not sure that your patch is warranted (or arguably, the correct fix).  Your patch certainly 
contains functionality that on the face of it would better belong in java.net.URI and not 
JavacFileManager. 

The way I read the code in JavacFileManager, isRelativeURI is not intended to be a full and 
complete implementation of checking whether a URI is path-rootless. Instead, it is used in 
exactly 3 places, and always in conjunction with URI.create.  JavacFileManager is assuming 
the full syntax checking is done by URI.create, and is just using a simple impl of 
isRelativeURI to distinguish relative URIs from absolute URIs created by URI.create.

6419701 is about removing the use of URI.create -- presumably because it is mildly icky
to create the URI object just to check whether a path string is a valid URI.  So it seems 
to me that there are two ways to take this issue:  
1) Rewrite isRelativeURI to take a String argument and thereby avoid the use of URI.create
2) Wait for URI to have some better method for checking the validity of a path without
actually constructing the URI object.

I guess that I dislike JavacFileManager having code for detailed parsing of URIs, and so
I think the current impl is better, of using URI.create to check the syntax of a URI, and
then apply a quick check as to whether it is absolute or relative is better.

Or am I misreading the situation or perhaps missing some subtlety in your proposed code?

-- Jon


Emil Andreas Siemes wrote:
com.sun.tools.javac.file.JavacFileManager checks if a name fulfills the requirements of relative names:

"A relative name is a non-null, non-empty sequence of path segments separated by '/'; '.' and '..' are invalid path segments. A valid relative name must match the "path-rootless" rule of RFC 3986, section 3.3.."

This is done via the isRelativeUri() method. Unfortunately this method doesn't currently really check for path-rootless compliance. A patch with an improved method is attached.
When java.net.Uri eventually supports RFC 3986 the need for isRelativeUri() goes away. I would also like to propose to rename isRelativeUri() to isRF3986PathRootless() which would more clearly describe what the method does.

There is a comment in JavacFileManager in a couple of lines:
//FIX ME 6419701
but I don't find bug 6419701 in the bug database. Any thoughts?

Thanks
    Emil




 
________________________________


________________________________


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20090108/114064aa/attachment.html 

From martinrb at google.com  Thu Jan  8 14:34:16 2009
From: martinrb at google.com (martinrb at google.com)
Date: Thu, 08 Jan 2009 22:34:16 +0000
Subject: hg: jdk7/tl/jdk: 6791458: FileInputStream/RandomAccessFile.read leaks
	memory if invoked on closed stream with len > 8k
Message-ID: <20090108223441.3C59CD2C1@hg.openjdk.java.net>

Changeset: 0272e442cc5b
Author:    martin
Date:      2009-01-08 14:07 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0272e442cc5b

6791458: FileInputStream/RandomAccessFile.read leaks memory if invoked on closed stream with len > 8k
Reviewed-by: alanb
Contributed-by: jeremymanson at google.com

! src/share/native/java/io/io_util.c
+ test/java/io/readBytes/MemoryLeak.java



From kelly.ohair at sun.com  Thu Jan  8 15:14:11 2009
From: kelly.ohair at sun.com (kelly.ohair at sun.com)
Date: Thu, 08 Jan 2009 23:14:11 +0000
Subject: hg: jdk7/tl/jdk: 3 new changesets
Message-ID: <20090108231446.4BE31D2CE@hg.openjdk.java.net>

Changeset: f6c105e60186
Author:    bpatel
Date:      2009-01-07 16:39 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f6c105e60186

6790217: Javadoc HTML WCAG 2.0 accessibility issues in jdk docs makefile - Bold tags should be strong
Reviewed-by: jjg

! make/docs/Makefile

Changeset: 71a6cd33d365
Author:    bpatel
Date:      2009-01-08 14:17 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/71a6cd33d365

Merge


Changeset: f5062c0ae8d5
Author:    bpatel
Date:      2009-01-08 15:10 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f5062c0ae8d5

Merge




From Jonathan.Gibbons at Sun.COM  Thu Jan  8 15:33:37 2009
From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons)
Date: Thu, 08 Jan 2009 15:33:37 -0800
Subject: AW: AW: [Patch] 6502392 Invalid relative names for
	Filer.createResource and Filer.getResource
In-Reply-To: <418326.20769.qm@web23003.mail.ird.yahoo.com>
References: <5DF426C2-99DC-4E72-8C98-3933A034918E@yahoo.de>
	<4962AFBA.2090900@sun.com>
	<813911.52511.qm@web23008.mail.ird.yahoo.com>
	<61E948E5-BCD3-444B-BFE0-BBA50C8CBB37@Sun.COM>
	<418326.20769.qm@web23003.mail.ird.yahoo.com>
Message-ID: <49668D51.2050308@sun.com>

Emil,

Comments inline.

-- Jon


Emil Siemes wrote:
> Hi Jon,
>
> RFC 3986 Appendix D describes the additions and modifications vs. 2396.
> Basically 3986 tries to make things clearer. They say there have been 
> a lot of discussions and different interpretations of 2396. (Sounds 
> like JME fragmentation to me ;-)
> A new ABNF was used, IPV6 literals added. URI normalization and 
> comparison was rewritten.
> Clarification of reserved and unreserved characters. Support for an 
> empty path component were added.

OK, thanks for the summary.

> 6791041 & 6791060 seem to be non-public. Will this change soon? I were 
> not able to find them on bugs.sun.com
They should now be available on bugs.sun.com.  There is sometimes a 
short delay in propogating bugs
from the internal bug database to the external site.


> If there is more information available on 6791041 I could look for 
> potential interpretation issues in the java.net.URI implementation vs. 
> 3986 spec.
6791041 provided a case where someone actually tried to have a relative 
path beginning with ".", such as ".foo"
>
> I should have a new isRelativeURI Monday latest. Would be good to know 
> what 6791041 is about by then.
Apparently, there was an attempt in JDK 6 to update URI for 3986, and 
the work had to be reverted
for compatibility issues. This makes me less optimistic that we might 
see any evolution for JDK 7.
As such, I think we should leverage what is in URI as much as possible, 
and apply any necessary
extra work in JavacFileManager -- which is essentially where you are 
heading, I believe.

>
> For the missing FileNotFoundException in JavacFiler I think the 
> clearest solution is to explicitly check for file existence in the 
> method. 
> Something like:
>
> getResource(...
>
> FileObject fileobject= ...
>
> if(!new File(fileobject.toURI().exists())
>      throw new FileNotFoundException();
> }
>
> Unfortunately this would include another creation of an URI object but 
> FileObject..getName() only returns a "user friendly" file name which I 
> understand is not necessarily useable for a File-Object creation.
> The fileobject involved in getResource & createResource is actually a 
> com.sun.tools.javac.file.RegularFileObject with a File object as 
> field. So another solution would be to either expose this File object 
> or add an exists() method to RegularFileObject which delegates the 
> call to file Object and cast the FileObject to a RegularFileObject. 
> (too ugly I believe).

You cannot call "new File(...)" or more generally, use any of the File 
API outside of the javac.file package, except to some extent in the 
command line processing classes (Main and JavaCompiler.) This is because 
the compilation units might not be coming directly from files in the 
host file system.   In an IDE using JSR199, for example, the compilation 
units might come from a database or from string buffers, depending on 
the implementation of JavaFileManager in use. The only real solution 
would be to add a new exists() method to FileObject and use that, but 
that too would be problematic because that would be a 
binary-incompatible change. The best we can probably do in the short 
term is to test if the
fileObject is an instance of RegularFileObject or perhaps 
BaseFileObject, and only apply the check in that case. Which is somewhat 
uglier than your "too ugly I believe" but arguably the best we can do, 
for now. :-(

Longer term, I note as background that JavaFileManager was designed as a 
"virtual file system as defined by the needs of javac". Some wise person 
once made comments about "as simple as possible but no simpler".  I 
think JavaFileManager ended up a tad too simple.  Separately, JSR 203 
("Son of NIO") is providing a more general virtual file system API.  I 
think it would be interesting to see an impl of 
JavaFileManager/FileObject/JavaFileObject built on top of the JSR 203 
APIs. This would then allow applications that wanted to use JSR199 to 
drive the compiler using a "non-standard" file system to use the JSR 203 
API to describe that file system instead of the JavaFileManager API.  
Put another way, if JSR203 had been available in time for JDK 6, I don't 
think we would have bothered with JavaFileManager etc.  The point of all 
of which is to say that the way forward here is to (eventually) provide 
an adapter for JSR 203, and to encourage folk to use JSR 203 as a way to 
provide virtual file systems.

>
> Thanks
>    Emil
>
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------
> *Von:* Jonathan Gibbons <Jonathan.Gibbons at Sun.COM>
> *An:* Emil Siemes <digitalemil at yahoo.de>
> *CC:* compiler-dev at openjdk.java.net
> *Gesendet:* Mittwoch, den 7. Januar 2009, 18:07:35 Uhr
> *Betreff:* Re: AW: [Patch] 6502392 Invalid relative names for 
> Filer.createResource and Filer.getResource
>
> Emil,
>
> First, some updates.
> 1) 6791041 has come in, which reports a specific instance of a user 
> encountering the issue you have been looking at. Specifically,
> the submitter is affected by the "quick and dirty" check in isRelativeURI.
> 2) I have filed 6791060 against java.net.URI
>
> It sounds like you are reasonably familiar with the RFCs involved 
> here. If so, can you briefly summarize any relevant differences
> between RFC 2396 (used by java.net.URI) and RFC 3986 (used by JSR 269 
> and Filer.)
>
> -- Jon
>
> On Jan 6, 2009, at 8:21 AM, Emil Siemes wrote:
>
>> Hi Jon,
>>
>> true, the code actually does things which would belong into 
>> java.net.URI. Reason for this is that JSR269 requires compliance with 
>> path-rootless rule of RFC3986 whereas java.net.URI supports the older 
>> and obsolete RFC 2396. Basically I was afraid of relying on the old 
>> implementation but that can be changed of course.
>> Given the limitation of the actual URI implementation it might be 
>> tricky to achieve compliance with the JSR269 requirements without 
>> parsing URI..getPath(). Dot-segments are not allowed as relative path 
>> names in JSR269 but are fine for the URI class. The current 
>> implementation calls URI.normalize().getPath() which actually removes 
>> dot-segments and therefore doesn't throw an exception. 
>>
>> Given your feedback I propose I rewrite my code in a way that it 
>> relies on java.net.URI and does a quick check on the path. May be I 
>> can compare URI.getPath() and URI.normalize().getPath() to find out 
>> if any dot-segments are part of the path. I'll check and let you know.
>>
>> Thanks
>>    Emil
>>
>>
>>  
>>
>>
>> ------------------------------------------------------------------------
>> *Von:* Jonathan Gibbons <Jonathan.Gibbons at Sun.COM 
>> <mailto:Jonathan.Gibbons at Sun.COM>>
>> *An:* Emil Andreas Siemes <digitalemil at yahoo.de 
>> <mailto:digitalemil at yahoo.de>>
>> *CC:* compiler-dev at openjdk.java.net 
>> <mailto:compiler-dev at openjdk.java.net>
>> *Gesendet:* Dienstag, den 6. Januar 2009, 02:11:22 Uhr
>> *Betreff:* Re: [Patch] 6502392 Invalid relative names for 
>> Filer.createResource and Filer.getResource
>>
>> Emil,
>>
>> Thank you for looking at this, and for your patch.
>>
>> I do not understand why 6419701 is not public. I am trying to find 
>> out why it is not.
>> The bug itself is about the use of URI.create, not about the use of 
>> isRelativeURI..
>>
>> I'm not sure that your patch is warranted (or arguably, the correct 
>> fix).  Your patch certainly 
>> contains functionality that on the face of it would better belong in 
>> java.net.URI and not 
>> JavacFileManager. 
>>
>> The way I read the code in JavacFileManager, isRelativeURI is not 
>> intended to be a full and 
>> complete implementation of checking whether a URI is path-rootless. 
>> Instead, it is used in 
>> exactly 3 places, and always in conjunction with URI.create.  
>> JavacFileManager is assuming 
>> the full syntax checking is done by URI.create, and is just using a 
>> simple impl of 
>> isRelativeURI to distinguish relative URIs from absolute URIs created 
>> by URI.create.
>>
>> 6419701 is about removing the use of URI.create -- presumably because 
>> it is mildly icky
>> to create the URI object just to check whether a path string is a 
>> valid URI.  So it seems 
>> to me that there are two ways to take this issue:  
>> 1) Rewrite isRelativeURI to take a String argument and thereby avoid 
>> the use of URI.create
>> 2) Wait for URI to have some better method for checking the validity 
>> of a path without
>> actually constructing the URI object.
>>
>> I guess that I dislike JavacFileManager having code for detailed 
>> parsing of URIs, and so
>> I think the current impl is better, of using URI.create to check the 
>> syntax of a URI, and
>> then apply a quick check as to whether it is absolute or relative is 
>> better.
>>
>> Or am I misreading the situation or perhaps missing some subtlety in 
>> your proposed code?
>>
>> -- Jon
>>
>>
>> Emil Andreas Siemes wrote:
>>> com.sun.tools.javac.file.JavacFileManager checks if a name fulfills 
>>> the requirements of relative names:
>>> "A relative name is a non-null, non-empty sequence of path segments 
>>> separated by |'/'|; |'.'| and |'..'| are invalid path segments. A 
>>> valid relative name must match the "path-rootless" rule of RFC 3986 
>>> <http://www.ietf.org/rfc/rfc3986.txt>, section 3.3."
>>>
>>> This is done via the isRelativeUri() method. Unfortunately this 
>>> method doesn't currently really check for path-rootless compliance. 
>>> A patch with an improved method is attached.
>>> When java.net.Uri eventually supports RFC 3986 the need for 
>>> isRelativeUri() goes away.. I would also like to propose to rename 
>>> isRelativeUri() to isRF3986PathRootless() which would more clearly 
>>> describe what the method does.
>>>
>>> There is a comment in JavacFileManager in a couple of lines:
>>> //FIX ME 6419701
>>> but I don't find bug 6419701 in the bug database. Any thoughts?
>>>
>>> Thanks
>>>     Emil
>>>
>>>
>>>
>>>
>>>  
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20090108/12f40760/attachment.html 

From kelly.ohair at sun.com  Fri Jan  9 15:09:36 2009
From: kelly.ohair at sun.com (kelly.ohair at sun.com)
Date: Fri, 09 Jan 2009 23:09:36 +0000
Subject: hg: jdk7/tl/langtools: 2 new changesets
Message-ID: <20090109230939.B0221D33B@hg.openjdk.java.net>

Changeset: 47a62d8d98b4
Author:    bpatel
Date:      2009-01-08 16:26 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/47a62d8d98b4

6786028: Javadoc HTML WCAG 2.0 accessibility issues in standard doclet - Bold tags should be strong
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/LinkInfoImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkInfo.java
! test/com/sun/javadoc/AccessAsciiArt/AccessAsciiArt.java
! test/com/sun/javadoc/AuthorDD/AuthorDD.java
! test/com/sun/javadoc/testClassCrossReferences/TestClassCrossReferences.java
! test/com/sun/javadoc/testClassTree/TestClassTree.java
! test/com/sun/javadoc/testConstructorIndent/TestConstructorIndent.java
! test/com/sun/javadoc/testDeprecatedDocs/TestDeprecatedDocs.java
! test/com/sun/javadoc/testExternalOverridenMethod/TestExternalOverridenMethod.java
! test/com/sun/javadoc/testHeadings/TestHeadings.java
! test/com/sun/javadoc/testHelpOption/TestHelpOption.java
! test/com/sun/javadoc/testHref/TestHref.java
+ test/com/sun/javadoc/testHtmlStrongTag/TestHtmlStrongTag.java
+ test/com/sun/javadoc/testHtmlStrongTag/pkg1/C1.java
+ test/com/sun/javadoc/testHtmlStrongTag/pkg2/C2.java
! test/com/sun/javadoc/testIndex/TestIndex.java
! test/com/sun/javadoc/testInterface/TestInterface.java
! test/com/sun/javadoc/testJavascript/TestJavascript.java
! test/com/sun/javadoc/testLinkOption/TestLinkOption.java
! test/com/sun/javadoc/testLinkTaglet/TestLinkTaglet.java
! test/com/sun/javadoc/testMemberInheritence/TestMemberInheritence.java
! test/com/sun/javadoc/testMemberSummary/TestMemberSummary.java
! test/com/sun/javadoc/testNavagation/TestNavagation.java
! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java
! test/com/sun/javadoc/testOverridenMethods/TestOverridenMethodDocCopy.java
! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethods.java
! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPackageFlag.java
! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPrivateFlag.java
! test/com/sun/javadoc/testPackagePage/TestPackagePage.java
! test/com/sun/javadoc/testParamTaglet/TestParamTaglet.java
! test/com/sun/javadoc/testPrivateClasses/TestPrivateClasses.java
! test/com/sun/javadoc/testSerializedForm/TestSerializedForm.java
! test/com/sun/javadoc/testSimpleTag/TestSimpleTag.java
! test/com/sun/javadoc/testSummaryHeading/TestSummaryHeading.java
! test/com/sun/javadoc/testThrowsHead/TestThrowsHead.java
! test/com/sun/javadoc/testValueTag/TestValueTag.java

Changeset: dbe9e82f9d25
Author:    bpatel
Date:      2009-01-08 16:34 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/dbe9e82f9d25

Merge

! test/com/sun/javadoc/AuthorDD/AuthorDD.java



From martinrb at google.com  Fri Jan  9 17:09:02 2009
From: martinrb at google.com (martinrb at google.com)
Date: Sat, 10 Jan 2009 01:09:02 +0000
Subject: hg: jdk7/tl/jdk: 6792066: src/share/native/java/io/io_util.c clean-ups
Message-ID: <20090110010920.AA3DBD342@hg.openjdk.java.net>

Changeset: 961ea5a46a0c
Author:    martin
Date:      2009-01-09 16:48 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/961ea5a46a0c

6792066: src/share/native/java/io/io_util.c clean-ups
Reviewed-by: alanb

! src/share/native/java/io/io_util.c
! src/share/native/java/io/io_util.h



From digitalemil at yahoo.de  Sun Jan 11 11:51:20 2009
From: digitalemil at yahoo.de (Emil Siemes)
Date: Sun, 11 Jan 2009 19:51:20 +0000 (GMT)
Subject: AW: AW: AW: [Patch] 6502392 Invalid relative names for
	Filer.createResource and Filer.getResource
References: <5DF426C2-99DC-4E72-8C98-3933A034918E@yahoo.de>
	<4962AFBA.2090900@sun.com>
	<813911.52511.qm@web23008.mail.ird.yahoo.com>
	<61E948E5-BCD3-444B-BFE0-BBA50C8CBB37@Sun.COM>
	<418326.20769.qm@web23003.mail.ird.yahoo.com>
	<49668D51.2050308@sun.com>
Message-ID: <209251.1060.qm@web23007.mail.ird.yahoo.com>

Hi Jon,

thank you very much for providing insight!

Please find an improved isRelativeUri method below. It fixes accepting invalid paths like foo/../bar and accepts valid path like .something
Unfortunately I now believe that using URI is not the right way to go:
"foo:/bar.xml" is a valid relative pathname but when we construct a URI("foo:/bar.xml") the first part "foo:" is treated as schema obviously.
getPath() then returns /bar.xml and this fails isRelative.
Similar new URI("foo#bar.xml").getPath() returns "foo" and is accepted by isRelative while "foo#bar.xml" is a non-valid relative path.

I tried using other URI constructors with explicitly setting schema and fragment to "" but URI doesn't accept this: 
 java.net.URISyntaxException: Relative path in absolute URI: ://src/foo.java#
It looks to me like using URI in our context is somehow miss-using the class and it will be difficult to make it water-proof.


I think we can either use URI in isRelative and accept that there are still glitches or create a isRelative which parses the path on its own.
Please let me know what you think. If you prefer a URI based isRelative I would create the patch with the method below. If you prefer a URI-free version now I will create a new patch since the path I sent out before also uses URI.


protected static boolean isRelativeUri(URI uri) {
        String path= uri.getPath();

        if(path.length()> 0 && path.charAt(0)== '/') {
            return false;
        }

        if(path.length()== 0)
            return false;
        
        if(!path.equals(uri.normalize()..getPath()))
                return false;
        
        return true;
      }








________________________________
Von: Jonathan Gibbons <Jonathan.Gibbons at Sun.COM>
An: Emil Siemes <digitalemil at yahoo.de>
CC: compiler-dev at openjdk.java.net
Gesendet: Freitag, den 9. Januar 2009, 00:33:37 Uhr
Betreff: Re: AW: AW: [Patch] 6502392 Invalid relative names for Filer.createResource and Filer.getResource

Emil,

Comments inline.

-- Jon


Emil Siemes wrote: 
Hi Jon,

RFC 3986 Appendix D describes the additions and modifications
vs. 2396..
Basically 3986 tries to make things clearer. They say there have
been a lot of discussions and different interpretations of 2396.
(Sounds like JME fragmentation to me ;-)
A new ABNF was used, IPV6 literals added. URI normalization and
comparison was rewritten.
Clarification of reserved and unreserved characters. Support for
an empty path component were added.
OK, thanks for the summary.


6791041 & 6791060 seem to be non-public. Will this change
soon? I were not able to find them on bugs.sun.com
They should now be available on bugs.sun.com.  There is sometimes a
short delay in propogating bugs 
from the internal bug database to the external site.



If there is more information available on 6791041 I could look
for potential interpretation issues in the java.net.URI implementation
vs. 3986 spec.
6791041 provided a case where someone actually tried to have a relative
path beginning with ".", such as ".foo"



I should have a new isRelativeURI Monday latest. Would be good
to know what 6791041 is about by then.
Apparently, there was an attempt in JDK 6 to update URI for 3986, and
the work had to be reverted
for compatibility issues. This makes me less optimistic that we might
see any evolution for JDK 7.
As such, I think we should leverage what is in URI as much as possible,
and apply any necessary
extra work in JavacFileManager -- which is essentially where you are
heading, I believe.




For the missing FileNotFoundException in JavacFiler I think the
clearest solution is to explicitly check for file existence in the
method. 
Something like:

getResource(...

FileObject fileobject= ...

if(!new File(fileobject.toURI().exists())
     throw new FileNotFoundException();
}

Unfortunately this would include another creation of an URI
object but FileObject..getName() only returns a "user friendly" file
name which I understand is not necessarily useable for a File-Object
creation.
The fileobject involved in getResource & createResource is
actually a com.sun.tools.javac.file.RegularFileObject with a File
object as field. So another solution would be to either expose this
File object or add an exists() method to RegularFileObject which
delegates the call to file Object and cast the FileObject to a
RegularFileObject. (too ugly I believe).
You cannot call "new File(...)" or more generally, use any of the File
API outside of the javac.file package, except to some extent in the
command line processing classes (Main and JavaCompiler.) This is
because the compilation units might not be coming directly from files
in the host file system.   In an IDE using JSR199, for example, the
compilation units might come from a database or from string buffers,
depending on the implementation of JavaFileManager in use. The only
real solution would be to add a new exists() method to FileObject and
use that, but that too would be problematic because that would be a
binary-incompatible change. The best we can probably do in the short
term is to test if the
fileObject is an instance of RegularFileObject or perhaps
BaseFileObject, and only apply the check in that case. Which is
somewhat uglier than your "too ugly I believe" but arguably the best we
can do, for now. :-(

Longer term, I note as background that JavaFileManager was designed as
a "virtual file system as defined by the needs of javac". Some wise
person once made comments about "as simple as possible but no
simpler".  I think JavaFileManager ended up a tad too simple. 
Separately, JSR 203 ("Son of NIO") is providing a more general virtual
file system API.  I think it would be interesting to see an impl of
JavaFileManager/FileObject/JavaFileObject built on top of the JSR 203
APIs. This would then allow applications that wanted to use JSR199 to
drive the compiler using a "non-standard" file system to use the JSR
203 API to describe that file system instead of the JavaFileManager
API.  Put another way, if JSR203 had been available in time for JDK 6,
I don't think we would have bothered with JavaFileManager etc.  The
point of all of which is to say that the way forward here is to
(eventually) provide an adapter for JSR 203, and to encourage folk to
use JSR 203 as a way to provide virtual file systems.




Thanks
   Emil












________________________________
Von: Jonathan Gibbons <Jonathan.Gibbons at Sun.COM>
An: Emil Siemes <digitalemil at yahoo.de>
CC: compiler-dev at openjdk.java.net
Gesendet: Mittwoch,
den 7. Januar 2009, 18:07:35 Uhr
Betreff: Re: AW:
[Patch] 6502392 Invalid relative names for Filer.createResource and
Filer.getResource

Emil, 

First, some updates.
1) 6791041 has come in, which reports a specific instance of a
user encountering the issue you have been looking at. Specifically,
the submitter is affected by the "quick and dirty" check in
isRelativeURI.
2) I have filed 6791060 against java.net.URI

It sounds like you are reasonably familiar with the RFCs
involved here. If so, can you briefly summarize any relevant differences
between RFC 2396 (used by java.net.URI) and RFC 3986 (used by
JSR 269 and Filer.)

-- Jon


On Jan 6, 2009, at 8:21 AM, Emil Siemes wrote:

Hi Jon,

true, the code actually does things which
would belong into java.net.URI. Reason for this is that JSR269 requires
compliance with path-rootless rule of RFC3986 whereas java.net.URI
supports the older and obsolete RFC 2396. Basically I was afraid of
relying on the old implementation but that can be changed of course.
Given the limitation of the actual URI
implementation it might be tricky to achieve compliance with the JSR269
requirements without parsing URI..getPath(). Dot-segments are not
allowed as relative path names in JSR269 but are fine for the URI
class. The current implementation calls URI.normalize().getPath() which
actually removes dot-segments and therefore doesn't throw an exception. 

Given your feedback I propose I rewrite
my code in a way that it relies on java.net.URI and does a quick check
on the path. May be I can compare URI.getPath() and
URI.normalize().getPath() to find out if any dot-segments are part of
the path. I'll check and let you know.

Thanks
   Emil


 




________________________________
Von: Jonathan Gibbons <Jonathan.Gibbons at Sun.COM>
An: Emil Andreas Siemes <digitalemil at yahoo.de>
CC: compiler-dev at openjdk.java.net
Gesendet: Dienstag, den 6. Januar 2009,
02:11:22 Uhr
Betreff: Re: [Patch] 6502392 Invalid
relative names for Filer.createResource and Filer.getResource

Emil,

Thank you for looking at this, and for your patch.

I do not understand why 6419701 is not public. I am trying to find out
why it is not.
The bug itself is about the use of URI.create, not about the use of
isRelativeURI..

I'm not sure that your patch is warranted (or arguably, the correct
fix).  Your patch certainly 
contains functionality that on the face of it would better belong in
java.net.URI and not 
JavacFileManager. 

The way I read the code in JavacFileManager, isRelativeURI is not
intended to be a full and 
complete implementation of checking whether a URI is path-rootless.
Instead, it is used in 
exactly 3 places, and always in conjunction with URI.create. 
JavacFileManager is assuming 
the full syntax checking is done by URI.create, and is just using a
simple impl of 
isRelativeURI to distinguish relative URIs from absolute URIs created
by URI.create.

6419701 is about removing the use of URI.create -- presumably because
it is mildly icky
to create the URI object just to check whether a path string is a valid
URI.  So it seems 
to me that there are two ways to take this issue:  
1) Rewrite isRelativeURI to take a String argument and thereby avoid
the use of URI.create
2) Wait for URI to have some better method for checking the validity of
a path without
actually constructing the URI object.

I guess that I dislike JavacFileManager having code for detailed
parsing of URIs, and so
I think the current impl is better, of using URI.create to check the
syntax of a URI, and
then apply a quick check as to whether it is absolute or relative is
better.

Or am I misreading the situation or perhaps missing some subtlety in
your proposed code?

-- Jon


Emil Andreas Siemes wrote: 
com.sun.tools.javac.file.JavacFileManager
checks if a name fulfills the requirements of relative names:

"A relative name is a
non-null, non-empty sequence of path segments separated by '/'; '.' and '..' are
invalid path segments. A valid relative name must match the
"path-rootless" rule of RFC 3986,
section 3.3."

This is done via the isRelativeUri()
method. Unfortunately this method doesn't currently really check for
path-rootless compliance. A patch with an improved method is attached.
When java.net.Uri eventually supports
RFC 3986 the need for isRelativeUri() goes away.. I would also like to
propose to rename isRelativeUri() to isRF3986PathRootless() which would
more clearly describe what the method does.

There is a comment in JavacFileManager
in a couple of lines:
//FIX ME 6419701
but I don't find bug 6419701 in the bug
database. Any thoughts?

Thanks
    Emil




 
________________________________


________________________________


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

From tim.bell at sun.com  Sun Jan 11 18:05:33 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Mon, 12 Jan 2009 02:05:33 +0000
Subject: hg: jdk7/tl/hotspot: 31 new changesets
Message-ID: <20090112020632.AD546D418@hg.openjdk.java.net>

Changeset: 7b920868b475
Author:    coleenp
Date:      2008-12-08 15:50 -0500
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7b920868b475

6773838: There is no calling stack for Compiler thread in hs_err file on x86
Summary: On solaris, the inline assembly wasn't being processed.  Added volatile to il file fixed it.
Reviewed-by: phh, kvn

! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp
! src/os_cpu/solaris_x86/vm/solaris_x86_32.il
! src/os_cpu/solaris_x86/vm/solaris_x86_64.il

Changeset: 3ad2b8576c4a
Author:    coleenp
Date:      2008-12-09 09:55 -0500
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3ad2b8576c4a

6689685: Hotspot crash error message should include libraries version
Summary: Print out JDK/JRE version that hotspot knows about.
Reviewed-by: kamg, blacklion, acorn, alanb

! src/share/vm/utilities/vmError.cpp

Changeset: 7a018855d2f0
Author:    jrose
Date:      2008-12-08 17:15 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7a018855d2f0

6779339: turn off LinkWellKnownClasses by default pending further testing
Summary: temporarily turn off LinkWellKnownClasses optimization
Reviewed-by: never, kvn

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 284d0af00d53
Author:    jrose
Date:      2008-12-09 12:41 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/284d0af00d53

6771309: debugging AD files is difficult without #line directives in generated code
Summary: more and better #line and #define directives in the generated code; ADLC itself accepts #line directives
Reviewed-by: never, kvn

! make/linux/adlc_updater
! make/linux/makefiles/adlc.make
! make/solaris/adlc_updater
! make/solaris/makefiles/adlc.make
! src/share/vm/adlc/adlparse.cpp
! src/share/vm/adlc/adlparse.hpp
! src/share/vm/adlc/archDesc.cpp
! src/share/vm/adlc/dfa.cpp
! src/share/vm/adlc/filebuff.hpp
! src/share/vm/adlc/formssel.cpp

Changeset: 7b75310e57e2
Author:    kvn
Date:      2008-12-11 17:20 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7b75310e57e2

Merge

! src/share/vm/runtime/globals.hpp

Changeset: 24fda36852ce
Author:    coleenp
Date:      2008-12-10 15:14 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/24fda36852ce

6727377: VM stack guard pages on Windows should PAGE_READWRITE not PAGE_EXECUTE_READWRITE
Summary: Make reguard_stack change access to RW, not execute and use os::protect_memory with the new parameter when change needed to X.
Reviewed-by: acorn, jcoomes

! src/os/linux/vm/os_linux.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/windows/vm/os_windows.cpp
! src/os_cpu/linux_x86/vm/os_linux_x86.cpp
! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp
! src/share/vm/prims/jni.cpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/os.hpp

Changeset: a7fac4381b50
Author:    blacklion
Date:      2008-12-11 03:22 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a7fac4381b50

6639341: sometimes contended-exit event comes after contended-entered on another thread
Summary: DTrace probe "contended-exit" should be fired before unparking object, or context could be lost. Probe firing was moved to proper place.
Reviewed-by: coleenp, kamg

! src/share/vm/runtime/synchronizer.cpp

Changeset: 06d2c3204df4
Author:    blacklion
Date:      2008-12-12 10:19 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/06d2c3204df4

Merge


Changeset: d249b360e026
Author:    ysr
Date:      2008-12-10 23:46 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d249b360e026

6782457: CMS: Livelock in CompactibleFreeListSpace::block_size()
6736295: SIGSEGV in product jvm, assertion "these are the only valid states during a mark sweep" in fastdebug
Summary: Restructured the code in the perm gen allocation retry loop so as to avoid "safepoint-blocking" on locks, in this case the Heap_lock, while holding uninitialized allocated heap storage.
Reviewed-by: apetrusenko, iveresov, jcoomes, jmasa, poonam

! src/share/vm/memory/permGen.cpp

Changeset: 7d7a7c599c17
Author:    jcoomes
Date:      2008-12-11 12:05 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7d7a7c599c17

6578152: fill_region_with_object has usability and safety issues
Reviewed-by: apetrusenko, ysr

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp
! src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp
! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp
! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp
! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp
! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp
! src/share/vm/gc_interface/collectedHeap.cpp
! src/share/vm/gc_interface/collectedHeap.hpp
! src/share/vm/gc_interface/collectedHeap.inline.hpp
! src/share/vm/includeDB_gc
! src/share/vm/memory/sharedHeap.cpp
! src/share/vm/memory/sharedHeap.hpp
! src/share/vm/memory/space.cpp
! src/share/vm/memory/tenuredGeneration.cpp
! src/share/vm/memory/threadLocalAllocBuffer.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/oops/arrayOop.hpp
! src/share/vm/oops/typeArrayKlass.cpp
! src/share/vm/oops/typeArrayKlass.hpp
! src/share/vm/runtime/globals.hpp

Changeset: 7c2386d67889
Author:    jcoomes
Date:      2008-12-11 12:05 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7c2386d67889

6765745: par compact - allow young gen spaces to be split
Reviewed-by: jmasa

! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp

Changeset: 0f773163217d
Author:    jcoomes
Date:      2008-12-11 12:05 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0f773163217d

6765954: par compact - stress mode for splitting young gen spaces
Reviewed-by: jmasa

! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp

Changeset: ffe19141e312
Author:    jmasa
Date:      2008-12-12 15:37 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ffe19141e312

Merge

! src/share/vm/runtime/globals.hpp

Changeset: ac8fe14c93e4
Author:    never
Date:      2008-12-12 19:53 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ac8fe14c93e4

6767587: missing call to make_not_entrant after deoptimizing for patching volatiles
Reviewed-by: rasbold, kvn

! src/share/vm/c1/c1_Runtime1.cpp

Changeset: a738a625039a
Author:    never
Date:      2008-12-12 19:54 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a738a625039a

6757316: load_constant() produces a wrong long constant, with high a low words swapped
Reviewed-by: rasbold, jrose, kvn

! src/share/vm/c1/c1_LIRGenerator.cpp
+ test/compiler/6757316/Test6757316.java

Changeset: 80206b8a9128
Author:    never
Date:      2008-12-12 19:55 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/80206b8a9128

6758234: if (k cond (a ? : b: c)) returns reversed answer if k is constant and b and c are longs
Reviewed-by: kvn, jrose

! src/share/vm/c1/c1_Optimizer.cpp
+ test/compiler/6758234/Test6758234.java

Changeset: 569b3b226089
Author:    trims
Date:      2008-12-20 09:57 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/569b3b226089

Merge

! src/share/vm/adlc/adlparse.cpp
! src/share/vm/adlc/adlparse.hpp
! src/share/vm/adlc/filebuff.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp

Changeset: 2494ab195856
Author:    swamyv
Date:      2008-12-15 13:58 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2494ab195856

6653214: MemoryPoolMXBean.setUsageThreshold() does not support large heap sizes.
Reviewed-by: ysr, mchung

! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp
! src/share/vm/memory/cardTableModRefBS.cpp
! src/share/vm/memory/cardTableModRefBS.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/arguments.hpp
! src/share/vm/services/management.cpp

Changeset: dd70dd4c91de
Author:    kvn
Date:      2008-12-16 12:23 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/dd70dd4c91de

6782820: Server VM fails with "unhandled implicit exception in compiled code"
Summary: Restore the code which sets a control edge for a klass load node.
Reviewed-by: never

! src/share/vm/opto/compile.cpp
! src/share/vm/opto/macro.cpp

Changeset: 6c345e1c5992
Author:    kvn
Date:      2008-12-17 14:09 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6c345e1c5992

Merge


Changeset: 5496e074077f
Author:    kvn
Date:      2008-12-18 11:26 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5496e074077f

6787050: assert(n->in(0) == 0L,"no control") with UseCompressedOops on sparcv9
Summary: Relax the assert for Sparc.
Reviewed-by: never

! src/share/vm/opto/compile.cpp

Changeset: eb811d2ef72e
Author:    kvn
Date:      2008-12-18 13:59 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/eb811d2ef72e

Merge


Changeset: d593294016c3
Author:    jcoomes
Date:      2008-12-18 01:27 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d593294016c3

6786195: many nsk.monitoring tests fail with -server -Xcomp
Summary: remove Universe::_fillerArrayKlassObj and associated code
Reviewed-by: jmasa, tonyp

! src/share/vm/gc_interface/collectedHeap.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp

Changeset: 234c22e54b98
Author:    jcoomes
Date:      2008-12-18 10:53 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/234c22e54b98

6784849: par compact - can fail when to_space is non-empty
Reviewed-by: jmasa, tonyp

! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp

Changeset: b27c885f75f9
Author:    jcoomes
Date:      2008-12-18 10:54 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b27c885f75f9

6786188: par compact - "SplitALot" stress mode should fill to_space
Reviewed-by: jmasa, tonyp

! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp

Changeset: 7aadaf46ecd7
Author:    jmasa
Date:      2008-12-19 12:15 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7aadaf46ecd7

Merge


Changeset: c6065343356f
Author:    poonam
Date:      2008-12-18 17:28 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c6065343356f

6786340: hs14b09a pit: a lot of tests failed in "-server -Xcomp" on solaris-amd64 using fastdebug bits
Summary: Fixes the nsk-jdi PIT failures introduced by fix for 6739363
Reviewed-by: kvn, coleenp

! src/share/vm/runtime/javaCalls.cpp

Changeset: 8a25d96bcf08
Author:    xlu
Date:      2008-12-19 14:40 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8a25d96bcf08

6784100: getTimeNanos - CAS reduction
Summary: Get rid of the CAS loop in getTimeNanos to reduce coherence traffic on Solaris.
Reviewed-by: acorn, kvn, ysr

! src/os/solaris/vm/os_solaris.cpp

Changeset: ca7d48236048
Author:    xlu
Date:      2008-12-20 00:45 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ca7d48236048

Merge


Changeset: 26bc4770e671
Author:    trims
Date:      2008-12-20 09:58 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/26bc4770e671

Merge

! src/share/vm/runtime/javaCalls.cpp

Changeset: fc6a5ae3fef5
Author:    trims
Date:      2008-12-20 09:59 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/fc6a5ae3fef5

6787832: Bump Hotspot build number to 08
Summary: Update the HS14 build number to 08
Reviewed-by: jcoomes

! make/hotspot_version



From tim.bell at sun.com  Sun Jan 11 18:13:26 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Mon, 12 Jan 2009 02:13:26 +0000
Subject: hg: jdk7/tl/jdk: 31 new changesets
Message-ID: <20090112021929.490E8D442@hg.openjdk.java.net>

Changeset: 94bcd3503668
Author:    bae
Date:      2008-07-25 14:46 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/94bcd3503668

6687968: PNGImageReader leaks native memory through an Inflater.
Reviewed-by: igor, prr

! src/share/classes/com/sun/imageio/plugins/png/PNGImageReader.java
! src/share/classes/com/sun/imageio/plugins/png/PNGImageWriter.java

Changeset: e62bc7b05b8a
Author:    igor
Date:      2008-08-04 18:50 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e62bc7b05b8a

4356282: RFE: T2K should be used to rasterize CID/CFF fonts
Reviewed-by: bae, prr

! src/share/classes/sun/font/FontManager.java
! src/share/classes/sun/font/TrueTypeFont.java
! src/share/classes/sun/java2d/SunGraphicsEnvironment.java
! src/windows/native/sun/font/fontpath.c

Changeset: a56641c1f54e
Author:    tdv
Date:      2008-08-04 11:29 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a56641c1f54e

6728834: D3D/OGL: LCD AA text becomes bold and blurred when rendering to a non-opaque destination
Reviewed-by: campbell

! src/share/classes/sun/java2d/opengl/OGLSurfaceData.java
! src/windows/classes/sun/java2d/d3d/D3DSurfaceData.java
+ test/sun/java2d/DirectX/NonOpaqueDestLCDAATest/NonOpaqueDestLCDAATest.java

Changeset: b2413144d908
Author:    tdv
Date:      2008-08-04 11:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b2413144d908

6717988: D3D: rendering problems with JConsole on [Nvidia FX 5200]
Reviewed-by: campbell

! src/windows/native/sun/java2d/d3d/D3DBadHardware.h

Changeset: 06a02adcba4e
Author:    tdv
Date:      2008-08-05 09:37 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/06a02adcba4e

6733718: test /java/awt/FullScreen/UninitializedDisplayModeChangeTest/ fails
Reviewed-by: igor

+ test/java/awt/FullScreen/UninitializedDisplayModeChangeTest/DisplayModeChanger.java

Changeset: 15be3e891e97
Author:    jgodinez
Date:      2008-08-07 11:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/15be3e891e97

6731937: javax/print/CheckDupFlavor.java fails
Reviewed-by: campbell, tdv

! src/solaris/classes/sun/print/IPPPrintService.java
+ test/javax/print/CheckDupFlavor.java

Changeset: 3c4561f955f3
Author:    lana
Date:      2008-08-07 22:24 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3c4561f955f3

Merge

- make/tools/winver/Makefile
- make/tools/winver/bin/winver.exe
- make/tools/winver/src/StdAfx.cpp
- make/tools/winver/src/StdAfx.h
- make/tools/winver/src/winver.cpp
- src/share/classes/com/sun/jmx/mbeanserver/OpenConverter.java
- src/share/classes/javax/management/ToQueryString.java
! src/share/classes/sun/font/FontManager.java
! src/share/classes/sun/font/TrueTypeFont.java
! src/solaris/classes/sun/print/IPPPrintService.java
- test/javax/management/Introspector/LegacyIntrospectorTest.java

Changeset: 3d3ef4073bdd
Author:    jgodinez
Date:      2008-08-19 16:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3d3ef4073bdd

6731826: race condition in UnixPrintServiceLookup
Reviewed-by: campbell, tdv

! src/solaris/classes/sun/print/IPPPrintService.java
+ test/javax/print/TestRaceCond.java

Changeset: cd88b4ad7f25
Author:    tdv
Date:      2008-08-28 11:27 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cd88b4ad7f25

6739267: D3D/OGL: add missing ThreeByteBgr to texture upload blit loop
Reviewed-by: campbell, flar

! src/share/classes/sun/java2d/opengl/OGLBlitLoops.java
! src/share/classes/sun/java2d/opengl/OGLSurfaceData.java
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/ImageTests.java
! src/share/native/sun/java2d/opengl/OGLBlitLoops.c
! src/share/native/sun/java2d/opengl/OGLSurfaceData.c
! src/windows/classes/sun/java2d/d3d/D3DBlitLoops.java
! src/windows/classes/sun/java2d/d3d/D3DSurfaceData.java
! src/windows/native/sun/java2d/d3d/D3DBlitLoops.cpp
! src/windows/native/sun/java2d/d3d/D3DSurfaceData.h

Changeset: b8f91ea2fb33
Author:    tdv
Date:      2008-09-12 15:01 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b8f91ea2fb33

6748082: remove platform-specific code from SwingUtilities2.isDisplayLocal
Reviewed-by: prr, tdv
Contributed-by: rkennke at kennke.org

! src/share/classes/sun/java2d/SunGraphicsEnvironment.java
! src/share/classes/sun/swing/SwingUtilities2.java
! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java
! src/solaris/native/sun/awt/fontpath.c
! src/windows/classes/sun/awt/Win32GraphicsEnvironment.java

Changeset: 41ff3f84cd96
Author:    prr
Date:      2008-09-24 11:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/41ff3f84cd96

6751621: TextLayout.getBounds() doesn't account for strike through
Reviewed-by: igor, dougfelt

! src/share/classes/sun/font/Decoration.java
! src/share/classes/sun/font/Underline.java
+ test/java/awt/font/TextLayout/DecorationBoundsTest.java

Changeset: 3bc4d79d8123
Author:    tdv
Date:      2008-10-09 17:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3bc4d79d8123

6749060: LCD AA text rendered incorrectly when destination is non opaque (sw pipeline only)
Reviewed-by: campbell, prr

! src/share/classes/sun/java2d/SurfaceData.java
! test/sun/java2d/DirectX/NonOpaqueDestLCDAATest/NonOpaqueDestLCDAATest.java

Changeset: 9a6094d65d28
Author:    jgodinez
Date:      2008-10-13 15:41 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9a6094d65d28

6732647: isAttributeValueSupported() is not consistant with getSupportedValues() for Copies, TEXT flavor
Reviewed-by: tdv, prr

! src/solaris/classes/sun/print/IPPPrintService.java
! src/solaris/classes/sun/print/UnixPrintService.java
! test/javax/print/attribute/PSCopiesFlavorTest.java

Changeset: 22d965ed3b93
Author:    prr
Date:      2008-10-16 06:28 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/22d965ed3b93

6751616: outline for underline in TextLayout with underline is off rasterized underline
Reviewed-by: dougfelt, igor

! src/share/classes/sun/font/Decoration.java
+ test/java/awt/font/TextLayout/UnderlinePositionTest.java

Changeset: 665850610378
Author:    lana
Date:      2008-10-20 11:52 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/665850610378

Merge

- make/ASSEMBLY_EXCEPTION
- make/LICENSE
- make/README
- make/README-builds.html
- make/README.html
- make/THIRD_PARTY_README
- make/java/nio/spp.sh
- make/tools/auto_multi/Makefile
- make/tools/src/build/tools/automulti/AutoMulti.java
- make/tools/src/build/tools/automulti/README.txt
- make/tools/src/build/tools/automulti/TestALFGenerator.java
- make/tools/src/build/tools/automulti/TestALFLookAndFeel.java
- src/share/classes/java/nio/channels/package.html
- src/share/classes/javax/swing/colorchooser/DefaultHSBChooserPanel.java
- src/share/classes/javax/swing/colorchooser/DefaultRGBChooserPanel.java
- src/share/classes/javax/swing/colorchooser/SyntheticImage.java
- src/share/classes/org/jcp/xml/dsig/internal/package.html
- src/share/classes/sun/launcher/LauncherHelp.java
- src/share/classes/sun/nio/ch/OptionAdaptor.java
- src/share/classes/sun/nio/ch/SocketOpts.java
- src/share/classes/sun/nio/ch/SocketOptsImpl.java
- src/share/classes/sun/nio/ch/exceptions
! src/share/classes/sun/swing/SwingUtilities2.java
- src/share/javavm/include/opcodes.h
- src/share/javavm/include/opcodes.length
- src/share/javavm/include/opcodes.list
- src/share/javavm/include/opcodes.weight
- src/share/javavm/include/opcodes.wide
- src/share/javavm/include/sys_api.h
- src/share/javavm/include/typedefs.h
- src/solaris/classes/sun/awt/motif/MButtonPeer.java
- src/solaris/classes/sun/awt/motif/MCanvasPeer.java
- src/solaris/classes/sun/awt/motif/MCheckboxMenuItemPeer.java
- src/solaris/classes/sun/awt/motif/MCheckboxPeer.java
- src/solaris/classes/sun/awt/motif/MChoicePeer.java
- src/solaris/classes/sun/awt/motif/MComponentPeer.java
- src/solaris/classes/sun/awt/motif/MCustomCursor.java
- src/solaris/classes/sun/awt/motif/MDataTransferer.java
- src/solaris/classes/sun/awt/motif/MDialogPeer.java
- src/solaris/classes/sun/awt/motif/MDragSourceContextPeer.java
- src/solaris/classes/sun/awt/motif/MDropTargetContextPeer.java
- src/solaris/classes/sun/awt/motif/MEmbedCanvasPeer.java
- src/solaris/classes/sun/awt/motif/MEmbeddedFrame.java
- src/solaris/classes/sun/awt/motif/MEmbeddedFramePeer.java
- src/solaris/classes/sun/awt/motif/MFileDialogPeer.java
- src/solaris/classes/sun/awt/motif/MFramePeer.java
- src/solaris/classes/sun/awt/motif/MGlobalCursorManager.java
- src/solaris/classes/sun/awt/motif/MInputMethod.java
- src/solaris/classes/sun/awt/motif/MInputMethodControl.java
- src/solaris/classes/sun/awt/motif/MInputMethodDescriptor.java
- src/solaris/classes/sun/awt/motif/MLabelPeer.java
- src/solaris/classes/sun/awt/motif/MListPeer.java
- src/solaris/classes/sun/awt/motif/MMenuBarPeer.java
- src/solaris/classes/sun/awt/motif/MMenuItemPeer.java
- src/solaris/classes/sun/awt/motif/MMenuPeer.java
- src/solaris/classes/sun/awt/motif/MMouseDragGestureRecognizer.java
- src/solaris/classes/sun/awt/motif/MPanelPeer.java
- src/solaris/classes/sun/awt/motif/MPopupMenuPeer.java
- src/solaris/classes/sun/awt/motif/MRobotPeer.java
- src/solaris/classes/sun/awt/motif/MScrollPanePeer.java
- src/solaris/classes/sun/awt/motif/MScrollbarPeer.java
- src/solaris/classes/sun/awt/motif/MTextAreaPeer.java
- src/solaris/classes/sun/awt/motif/MTextFieldPeer.java
- src/solaris/classes/sun/awt/motif/MWindowPeer.java
- src/solaris/classes/sun/awt/motif/X11Clipboard.java
- src/solaris/classes/sun/awt/motif/X11DragSourceContextPeer.java
- src/solaris/classes/sun/awt/motif/X11DropTargetContextPeer.java
- src/solaris/classes/sun/awt/motif/X11Selection.java
- src/solaris/classes/sun/awt/motif/X11SelectionHolder.java
- src/solaris/javavm/include/typedefs_md.h
- src/solaris/native/sun/awt/awt_Button.c
- src/solaris/native/sun/awt/awt_Canvas.c
- src/solaris/native/sun/awt/awt_Checkbox.c
- src/solaris/native/sun/awt/awt_Choice12.c
- src/solaris/native/sun/awt/awt_Choice21.c
- src/solaris/native/sun/awt/awt_Component.c
- src/solaris/native/sun/awt/awt_Cursor.c
- src/solaris/native/sun/awt/awt_DataTransferer.c
- src/solaris/native/sun/awt/awt_DataTransferer.h
- src/solaris/native/sun/awt/awt_FileDialog.c
- src/solaris/native/sun/awt/awt_GlobalCursorManager.c
- src/solaris/native/sun/awt/awt_KeyboardFocusManager.c
- src/solaris/native/sun/awt/awt_Label.c
- src/solaris/native/sun/awt/awt_List.c
- src/solaris/native/sun/awt/awt_Menu.c
- src/solaris/native/sun/awt/awt_Menu.h
- src/solaris/native/sun/awt/awt_MenuBar.c
- src/solaris/native/sun/awt/awt_MenuBar.h
- src/solaris/native/sun/awt/awt_MenuComponent.c
- src/solaris/native/sun/awt/awt_MenuItem.c
- src/solaris/native/sun/awt/awt_PopupMenu.c
- src/solaris/native/sun/awt/awt_ScrollPane.c
- src/solaris/native/sun/awt/awt_Scrollbar.c
- src/solaris/native/sun/awt/awt_Selection.c
- src/solaris/native/sun/awt/awt_TextArea.c
- src/solaris/native/sun/awt/awt_TextArea.h
- src/solaris/native/sun/awt/awt_TextField.c
- src/solaris/native/sun/awt/awt_TextField.h
- src/solaris/native/sun/awt/awt_TopLevel.c
- src/solaris/native/sun/awt/awt_XmDnD.c
- src/solaris/native/sun/awt/awt_XmDnD.h
- src/solaris/native/sun/awt/awt_dnd.c
- src/solaris/native/sun/awt/awt_dnd.h
- src/solaris/native/sun/awt/awt_dnd_ds.c
- src/solaris/native/sun/awt/awt_dnd_dt.c
- src/solaris/native/sun/awt/awt_motif.c
- src/solaris/native/sun/awt/awt_motif12.c
- src/solaris/native/sun/awt/awt_motif21.c
- src/solaris/native/sun/awt/awt_xembed.c
- src/solaris/native/sun/awt/canvas.c
- src/solaris/native/sun/awt/cursor.c
- src/windows/javavm/include/typedefs_md.h
- test/javax/swing/JFileChooser/4252173/bug4252173.java
- test/javax/swing/JFileChooser/6524424/bug6524424.html
- test/javax/swing/JFileChooser/6524424/bug6524424.java
- test/sun/net/www/http/ChunkedInputStream/test.txt
- test/tools/launcher/Arrrghs.sh

Changeset: 452c58b2f533
Author:    tdv
Date:      2008-10-21 08:25 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/452c58b2f533

6755274: 6u10b33 2d tests fails on sles10x64 with jvm crash
Reviewed-by: campbell

! src/solaris/classes/sun/java2d/opengl/GLXGraphicsConfig.java
! src/windows/classes/sun/java2d/opengl/WGLGraphicsConfig.java

Changeset: c739feb28074
Author:    prr
Date:      2008-10-28 14:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c739feb28074

6764543: SIGSEGV in libfontconfig.so starting from jdk7b33
Reviewed-by: campbell, igor

! src/solaris/native/sun/awt/fontpath.c

Changeset: 594c52582b21
Author:    tdv
Date:      2008-10-28 14:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/594c52582b21

6764257: D3D/OGL: color is not reset properly after save/restoreState() [RSL]
Reviewed-by: campbell

! src/share/classes/sun/java2d/pipe/BufferedContext.java
+ test/sun/java2d/pipe/hw/RSLContextInvalidationTest/RSLContextInvalidationTest.java

Changeset: 9cdababf6179
Author:    igor
Date:      2008-10-29 01:52 +0300
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9cdababf6179

6761856: OpenJDK: vertical text metrics may be significanly different from those returned by Sun JDK
Reviewed-by: bae, prr

! src/share/native/sun/font/freetypeScaler.c
! test/java/awt/font/TextLayout/TextLayoutBounds.java

Changeset: 3a9d06af8830
Author:    bae
Date:      2008-11-01 20:42 +0300
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3a9d06af8830

6541476: PNG imageio plugin incorrectly handles iTXt chunk
Reviewed-by: igor, prr

! src/share/classes/com/sun/imageio/plugins/png/PNGImageReader.java
! src/share/classes/com/sun/imageio/plugins/png/PNGImageWriter.java
! src/share/classes/com/sun/imageio/plugins/png/PNGMetadata.java
+ test/javax/imageio/plugins/png/ITXtTest.java

Changeset: 8eb24fc88242
Author:    tdv
Date:      2008-11-18 17:16 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8eb24fc88242

6758179: D3D: AlphaComposite is applied incorrectly for uncached opaque BufferedImage
Reviewed-by: campbell, flar

! src/windows/native/sun/java2d/d3d/D3DBlitLoops.cpp
+ test/sun/java2d/DirectX/OpaqueImageToSurfaceBlitTest/OpaqueImageToSurfaceBlitTest.java

Changeset: 3fea7e660a8f
Author:    tdv
Date:      2008-11-18 18:32 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3fea7e660a8f

6757527: D3D: serious rendering issues on Nvidia boards with driver version 178.13 on Vista
Reviewed-by: campbell

! src/windows/native/sun/java2d/d3d/D3DBlitLoops.cpp
! src/windows/native/sun/java2d/d3d/D3DContext.cpp

Changeset: be363ea85cb4
Author:    jgodinez
Date:      2008-11-25 14:38 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/be363ea85cb4

6653384: Variable "initialized" in class CUPSPrinter is static by mistake
Reviewed-by: tdv, prr

! src/solaris/classes/sun/print/CUPSPrinter.java
! src/solaris/classes/sun/print/IPPPrintService.java
+ test/java/awt/print/PrinterJob/GetMediasTest.java

Changeset: c8eea39734e8
Author:    jgodinez
Date:      2008-12-04 10:05 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c8eea39734e8

6587245: Import declaration not used in sun.print.*
Reviewed-by: tdv, prr

! src/share/classes/javax/print/Doc.java
! src/share/classes/javax/print/DocFlavor.java
! src/share/classes/javax/print/DocPrintJob.java
! src/share/classes/javax/print/MultiDocPrintService.java
! src/share/classes/javax/print/PrintServiceLookup.java
! src/share/classes/javax/print/attribute/URISyntax.java
! src/share/classes/javax/print/event/PrintServiceAttributeEvent.java
! src/share/classes/sun/print/PSPathGraphics.java
! src/share/classes/sun/print/PrintJobAttributeException.java
! src/share/classes/sun/print/SunMinMaxPage.java
! src/share/classes/sun/print/SunPageSelection.java

Changeset: 15435c60c751
Author:    tdv
Date:      2008-12-04 11:21 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/15435c60c751

6708580: Java applications slow when EXA enabled
Reviewed-by: prr, tdv
Contributed-by: ceisserer <linuxhippy at gmail.com>

! make/sun/awt/mapfile-mawt-vers
! make/sun/xawt/mapfile-vers
! src/solaris/classes/sun/java2d/x11/X11SurfaceData.java
! src/solaris/native/sun/java2d/x11/X11SurfaceData.c

Changeset: b0c446712fae
Author:    jgodinez
Date:      2008-12-08 10:23 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b0c446712fae

6665212: PrinterJob class, method lookupStreamPrintServices(), "fos" in docs is unknown
Reviewed-by: tdv, prr

! src/share/classes/java/awt/print/PrinterJob.java

Changeset: b163d898f83f
Author:    tdv
Date:      2008-12-08 17:04 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b163d898f83f

6772137: D3D: Dragging the scroll bar of a JScrollPane containing a JTree causes incorrect red
Reviewed-by: campbell

! src/windows/native/sun/java2d/d3d/D3DBadHardware.h

Changeset: bf5dd3128c6a
Author:    lana
Date:      2008-12-08 19:49 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bf5dd3128c6a

Merge


Changeset: 50c67678b0d1
Author:    lana
Date:      2009-01-06 16:24 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/50c67678b0d1

Merge

! src/share/classes/sun/swing/SwingUtilities2.java

Changeset: 37a9442e3203
Author:    tbell
Date:      2009-01-09 21:54 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/37a9442e3203

Merge


Changeset: 5c39d920b488
Author:    tbell
Date:      2009-01-09 22:01 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5c39d920b488

Merge




From Jonathan.Gibbons at Sun.COM  Mon Jan 12 16:37:04 2009
From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons)
Date: Mon, 12 Jan 2009 16:37:04 -0800
Subject: AW: AW: AW: [Patch] 6502392 Invalid relative names for
	Filer.createResource and Filer.getResource
In-Reply-To: <209251.1060.qm@web23007.mail.ird.yahoo.com>
References: <5DF426C2-99DC-4E72-8C98-3933A034918E@yahoo.de>
	<4962AFBA.2090900@sun.com>
	<813911.52511.qm@web23008.mail.ird.yahoo.com>
	<61E948E5-BCD3-444B-BFE0-BBA50C8CBB37@Sun.COM>
	<418326.20769.qm@web23003.mail.ird.yahoo.com>
	<49668D51.2050308@sun.com>
	<209251.1060.qm@web23007.mail.ird.yahoo.com>
Message-ID: <496BE230.8060803@sun.com>

Emil,

I think the way forward is to go back and look at the spec of Filer, and 
to some extent, what was likely the
original intent of the spec.

Here's the relevant part of the File spec, from 
http://java.sun.com/javase/6/docs/api/javax/annotation/processing/Filer.html

> The methods for reading and writing resources take a relative name 
> argument. A relative name is a non-null, non-empty sequence of path 
> segments separated by |'/'|; |'.'| and |'..'| are invalid path 
> segments. A valid relative name must match the "path-rootless" rule of 
> RFC 3986 <http://www.ietf.org/rfc/rfc3986.txt>, section 3.3. 

The primary definition is "non-null, non-empty sequence of path segments 
separated by |'/'|".  It goes on to say that . and .. are invalid. 
Finally, it says they must match a spec in a section of rfc 3986.   In 
particular, the Filer spec does not say that all productions of the 
path-rootless rule are valid arguments.

So, to the intent.  I think that the intent is to (only) allow lowest 
common denominator of relative filenames across Java platforms. As such, 
allowing ":" seems a very problematic character, given its significance 
on Windows.  

So, to your patch. This is definitely heading in the right direction, 
although as written isRelativeURI does not check for port, authority, 
query and fragment.  [It never did.] So, I have one suggestion.  If you 
read the javadoc comments for isRelativeFile, and follow the references, 
you get to this part of the spec at 
http://java.sun.com/javase/6/docs/api/javax/tools/JavaFileManager.html#relative_name
This uses the same words as found on Filer, with the following 
interesting addition:
> Informally, this should be true:
>   URI.create <http://java.sun.com/javase/6/docs/api/java/net/URI.html#create%28java.lang.String%29>(relativeName).normalize <http://java.sun.com/javase/6/docs/api/java/net/URI.html#normalize%28%29>().getPath <http://java.sun.com/javase/6/docs/api/java/net/URI.html#getPath%28%29>().equals(relativeName)
This expression is very similar to the expression  you came up with.  
However, it uses "String relativeName", rather than a URI.   Looking at 
JavacFileManager, isRelativeURI is only called 3 times, and always on 
the result of URI.create. Since it is a protected static method on a 
javac-internal API, it would be reasonable to change the signature to 
take a String instead of a URI, and then we could formally check the 
informal assertion given above.

For example, the code might look something like:

protected static boolean isRelativeUri(String relativeName) {
        URI uri =  URI.create(relativeName);
        String path= uri.getPath();

        if(path.length()> 0 && path.charAt(0)== '/') {
            return false;
        }

        if(path.length()== 0)
            return false;
       
        if(!uri.normalize().getPath().equals(relativeName))
                return false;
       
        return true;
      }

In terms of cleanup, this would also allow us to remove the three 
comments  // FIXME 6419701 and merge them into a single new comment on 
the URI.create line in isRelativeUri.

You can also simplify the code a tiny bit more by reordering the first 
two if statements and thereby eliminating the redundant check on 
path.length() > 0.


-- Jon



Emil Siemes wrote:
> Hi Jon,
>
> thank you very much for providing insight!
>
> Please find an improved isRelativeUri method below. It fixes accepting 
> invalid paths like foo/../bar and accepts valid path like .something
> Unfortunately I now believe that using URI is not the right way to go:
> "foo:/bar.xml" is a valid relative pathname but when we construct a 
> URI("foo:/bar.xml") the first part "foo:" is treated as schema obviously.
> getPath() then returns /bar.xml and this fails isRelative.
> Similar new URI("foo#bar.xml").getPath() returns "foo" and is accepted 
> by isRelative while "foo#bar.xml" is a non-valid relative path.
>
> I tried using other URI constructors with explicitly setting schema 
> and fragment to "" but URI doesn't accept this:
>  java.net.URISyntaxException: Relative path in absolute URI: 
> ://src/foo.java#
> It looks to me like using URI in our context is somehow miss-using the 
> class and it will be difficult to make it water-proof.
>
>
> I think we can either use URI in isRelative and accept that there are 
> still glitches or create a isRelative which parses the path on its own.
> Please let me know what you think. If you prefer a URI based 
> isRelative I would create the patch with the method below. If you 
> prefer a URI-free version now I will create a new patch since the path 
> I sent out before also uses URI.
>
>
> protected static boolean isRelativeUri(URI uri) {
>         String path= uri.getPath();
>
>         if(path.length()> 0 && path.charAt(0)== '/') {
>             return false;
>         }
>
>         if(path.length()== 0)
>             return false;
>        
>         if(!path.equals(uri.normalize().getPath()))
>                 return false;
>        
>         return true;
>       }
>
>
>
>
>
> ------------------------------------------------------------------------
> *Von:* Jonathan Gibbons <Jonathan.Gibbons at Sun.COM>
> *An:* Emil Siemes <digitalemil at yahoo.de>
> *CC:* compiler-dev at openjdk.java.net
> *Gesendet:* Freitag, den 9. Januar 2009, 00:33:37 Uhr
> *Betreff:* Re: AW: AW: [Patch] 6502392 Invalid relative names for 
> Filer.createResource and Filer.getResource
>
> Emil,
>
> Comments inline.
>
> -- Jon
>
>
> Emil Siemes wrote:
>> Hi Jon,
>>
>> RFC 3986 Appendix D describes the additions and modifications vs. 2396.
>> Basically 3986 tries to make things clearer. They say there have been 
>> a lot of discussions and different interpretations of 2396. (Sounds 
>> like JME fragmentation to me ;-)
>> A new ABNF was used, IPV6 literals added. URI normalization and 
>> comparison was rewritten.
>> Clarification of reserved and unreserved characters. Support for an 
>> empty path component were added.
>
> OK, thanks for the summary.
>
>> 6791041 & 6791060 seem to be non-public. Will this change soon? I 
>> were not able to find them on bugs.sun..com
> They should now be available on bugs.sun.com.  There is sometimes a 
> short delay in propogating bugs
> from the internal bug database to the external site.
>
>
>> If there is more information available on 6791041 I could look for 
>> potential interpretation issues in the java.net.URI implementation 
>> vs. 3986 spec.
> 6791041 provided a case where someone actually tried to have a 
> relative path beginning with ".", such as ".foo"
>>
>> I should have a new isRelativeURI Monday latest. Would be good to 
>> know what 6791041 is about by then.
> Apparently, there was an attempt in JDK 6 to update URI for 3986, and 
> the work had to be reverted
> for compatibility issues. This makes me less optimistic that we might 
> see any evolution for JDK 7.
> As such, I think we should leverage what is in URI as much as 
> possible, and apply any necessary
> extra work in JavacFileManager -- which is essentially where you are 
> heading, I believe.
>
>>
>> For the missing FileNotFoundException in JavacFiler I think the 
>> clearest solution is to explicitly check for file existence in the 
>> method. 
>> Something like:
>>
>> getResource(...
>>
>> FileObject fileobject= ...
>>
>> if(!new File(fileobject.toURI().exists())
>>      throw new FileNotFoundException();
>> }
>>
>> Unfortunately this would include another creation of an URI object 
>> but FileObject..getName() only returns a "user friendly" file name 
>> which I understand is not necessarily useable for a File-Object creation.
>> The fileobject involved in getResource & createResource is actually a 
>> com.sun.tools.javac.file.RegularFileObject with a File object as 
>> field. So another solution would be to either expose this File object 
>> or add an exists() method to RegularFileObject which delegates the 
>> call to file Object and cast the FileObject to a RegularFileObject. 
>> (too ugly I believe).
>
> You cannot call "new File(...)" or more generally, use any of the File 
> API outside of the javac.file package, except to some extent in the 
> command line processing classes (Main and JavaCompiler.) This is 
> because the compilation units might not be coming directly from files 
> in the host file system.   In an IDE using JSR199, for example, the 
> compilation units might come from a database or from string buffers, 
> depending on the implementation of JavaFileManager in use. The only 
> real solution would be to add a new exists() method to FileObject and 
> use that, but that too would be problematic because that would be a 
> binary-incompatible change. The best we can probably do in the short 
> term is to test if the
> fileObject is an instance of RegularFileObject or perhaps 
> BaseFileObject, and only apply the check in that case. Which is 
> somewhat uglier than your "too ugly I believe" but arguably the best 
> we can do, for now. :-(
>
> Longer term, I note as background that JavaFileManager was designed as 
> a "virtual file system as defined by the needs of javac". Some wise 
> person once made comments about "as simple as possible but no 
> simpler".  I think JavaFileManager ended up a tad too simple.  
> Separately, JSR 203 ("Son of NIO") is providing a more general virtual 
> file system API.  I think it would be interesting to see an impl of 
> JavaFileManager/FileObject/JavaFileObject built on top of the JSR 203 
> APIs. This would then allow applications that wanted to use JSR199 to 
> drive the compiler using a "non-standard" file system to use the JSR 
> 203 API to describe that file system instead of the JavaFileManager 
> API.  Put another way, if JSR203 had been available in time for JDK 6, 
> I don't think we would have bothered with JavaFileManager etc.  The 
> point of all of which is to say that the way forward here is to 
> (eventually) provide an adapter for JSR 203, and to encourage folk to 
> use JSR 203 as a way to provide virtual file systems.
>
>>
>> Thanks
>>    Emil
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>> *Von:* Jonathan Gibbons <Jonathan.Gibbons at Sun.COM>
>> *An:* Emil Siemes <digitalemil at yahoo.de>
>> *CC:* compiler-dev at openjdk.java.net
>> *Gesendet:* Mittwoch, den 7. Januar 2009, 18:07:35 Uhr
>> *Betreff:* Re: AW: [Patch] 6502392 Invalid relative names for 
>> Filer.createResource and Filer..getResource
>>
>> Emil,
>>
>> First, some updates.
>> 1) 6791041 has come in, which reports a specific instance of a user 
>> encountering the issue you have been looking at. Specifically,
>> the submitter is affected by the "quick and dirty" check in 
>> isRelativeURI.
>> 2) I have filed 6791060 against java.net.URI
>>
>> It sounds like you are reasonably familiar with the RFCs involved 
>> here. If so, can you briefly summarize any relevant differences
>> between RFC 2396 (used by java.net.URI) and RFC 3986 (used by JSR 269 
>> and Filer.)
>>
>> -- Jon
>>
>> On Jan 6, 2009, at 8:21 AM, Emil Siemes wrote:
>>
>>> Hi Jon,
>>>
>>> true, the code actually does things which would belong into 
>>> java.net.URI. Reason for this is that JSR269 requires compliance 
>>> with path-rootless rule of RFC3986 whereas java.net.URI supports the 
>>> older and obsolete RFC 2396. Basically I was afraid of relying on 
>>> the old implementation but that can be changed of course.
>>> Given the limitation of the actual URI implementation it might be 
>>> tricky to achieve compliance with the JSR269 requirements without 
>>> parsing URI..getPath(). Dot-segments are not allowed as relative 
>>> path names in JSR269 but are fine for the URI class. The current 
>>> implementation calls URI.normalize().getPath() which actually 
>>> removes dot-segments and therefore doesn't throw an exception. 
>>>
>>> Given your feedback I propose I rewrite my code in a way that it 
>>> relies on java.net.URI and does a quick check on the path. May be I 
>>> can compare URI.getPath() and URI.normalize().getPath() to find out 
>>> if any dot-segments are part of the path. I'll check and let you know.
>>>
>>> Thanks
>>>    Emil
>>>
>>>
>>>  
>>>
>>>
>>> ------------------------------------------------------------------------
>>> *Von:* Jonathan Gibbons <Jonathan.Gibbons at Sun.COM 
>>> <mailto:Jonathan.Gibbons at Sun.COM>>
>>> *An:* Emil Andreas Siemes <digitalemil at yahoo.de 
>>> <mailto:digitalemil at yahoo.de>>
>>> *CC:* compiler-dev at openjdk.java.net 
>>> <mailto:compiler-dev at openjdk.java.net>
>>> *Gesendet:* Dienstag, den 6. Januar 2009, 02:11:22 Uhr
>>> *Betreff:* Re: [Patch] 6502392 Invalid relative names for 
>>> Filer.createResource and Filer.getResource
>>>
>>> Emil,
>>>
>>> Thank you for looking at this, and for your patch.
>>>
>>> I do not understand why 6419701 is not public. I am trying to find 
>>> out why it is not.
>>> The bug itself is about the use of URI.create, not about the use of 
>>> isRelativeURI..
>>>
>>> I'm not sure that your patch is warranted (or arguably, the correct 
>>> fix).  Your patch certainly 
>>> contains functionality that on the face of it would better belong in 
>>> java.net.URI and not 
>>> JavacFileManager. 
>>>
>>> The way I read the code in JavacFileManager, isRelativeURI is not 
>>> intended to be a full and 
>>> complete implementation of checking whether a URI is path-rootless. 
>>> Instead, it is used in 
>>> exactly 3 places, and always in conjunction with URI.create.  
>>> JavacFileManager is assuming 
>>> the full syntax checking is done by URI.create, and is just using a 
>>> simple impl of 
>>> isRelativeURI to distinguish relative URIs from absolute URIs 
>>> created by URI.create.
>>>
>>> 6419701 is about removing the use of URI.create -- presumably 
>>> because it is mildly icky
>>> to create the URI object just to check whether a path string is a 
>>> valid URI.  So it seems 
>>> to me that there are two ways to take this issue:  
>>> 1) Rewrite isRelativeURI to take a String argument and thereby avoid 
>>> the use of URI.create
>>> 2) Wait for URI to have some better method for checking the validity 
>>> of a path without
>>> actually constructing the URI object.
>>>
>>> I guess that I dislike JavacFileManager having code for detailed 
>>> parsing of URIs, and so
>>> I think the current impl is better, of using URI.create to check the 
>>> syntax of a URI, and
>>> then apply a quick check as to whether it is absolute or relative is 
>>> better.
>>>
>>> Or am I misreading the situation or perhaps missing some subtlety in 
>>> your proposed code?
>>>
>>> -- Jon
>>>
>>>
>>> Emil Andreas Siemes wrote:
>>>> com.sun.tools.javac.file.JavacFileManager checks if a name fulfills 
>>>> the requirements of relative names:
>>>> "A relative name is a non-null, non-empty sequence of path segments 
>>>> separated by |'/'|; |'.'| and |'..'| are invalid path segments. A 
>>>> valid relative name must match the "path-rootless" rule of RFC 3986 
>>>> <http://www.ietf.org/rfc/rfc3986.txt>, section 3.3."
>>>>
>>>> This is done via the isRelativeUri() method. Unfortunately this 
>>>> method doesn't currently really check for path-rootless compliance. 
>>>> A patch with an improved method is attached.
>>>> When java.net.Uri eventually supports RFC 3986 the need for 
>>>> isRelativeUri() goes away.. I would also like to propose to rename 
>>>> isRelativeUri() to isRF3986PathRootless() which would more clearly 
>>>> describe what the method does.
>>>>
>>>> There is a comment in JavacFileManager in a couple of lines:
>>>> //FIX ME 6419701
>>>> but I don't find bug 6419701 in the bug database. Any thoughts?
>>>>
>>>> Thanks
>>>>     Emil
>>>>
>>>>
>>>>
>>>>
>>>>  
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>
>>>
>>>
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20090112/9a423c84/attachment.html 

From maurizio.cimadamore at sun.com  Tue Jan 13 05:51:59 2009
From: maurizio.cimadamore at sun.com (maurizio.cimadamore at sun.com)
Date: Tue, 13 Jan 2009 13:51:59 +0000
Subject: hg: jdk7/tl/langtools: 4 new changesets
Message-ID: <20090113135206.4AD4FD512@hg.openjdk.java.net>

Changeset: 905e151a185a
Author:    mcimadamore
Date:      2009-01-13 13:27 +0000
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/905e151a185a

6765045: Remove rawtypes warnings from langtools
Summary: Removed all occurrences of rawtypes warnings from langtools
Reviewed-by: jjg, bpatel

! make/build.properties
! src/share/classes/com/sun/source/util/Trees.java
! src/share/classes/com/sun/tools/apt/comp/Apt.java
! src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationProxyMaker.java
! src/share/classes/com/sun/tools/apt/mirror/declaration/Constants.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/ConstantsSummaryWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractMemberBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeOptionalMemberBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstantsSummaryBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstructorBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/EnumConstantBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/FieldBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/LayoutParser.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MethodBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ParamTaglet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassTree.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassUseMapper.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Group.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ImplementedMethods.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/IndexBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/VisibleMemberMap.java
! src/share/classes/com/sun/tools/javac/Main.java
! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java
! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java
! src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! src/share/classes/com/sun/tools/javac/processing/ServiceProxy.java
! src/share/classes/com/sun/tools/javac/util/Context.java
! src/share/classes/com/sun/tools/javac/util/List.java
! src/share/classes/com/sun/tools/javac/util/Pair.java
! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java
! src/share/classes/com/sun/tools/javah/Gen.java
! src/share/classes/com/sun/tools/javah/LLNI.java
! src/share/classes/com/sun/tools/javah/TypeSignature.java
! src/share/classes/sun/tools/javap/FieldData.java
! src/share/classes/sun/tools/javap/JavapPrinter.java
! src/share/classes/sun/tools/javap/MethodData.java

Changeset: d57378c34fdb
Author:    mcimadamore
Date:      2009-01-13 13:28 +0000
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d57378c34fdb

6665356: Cast not allowed when both qualifying type and inner class are parameterized
Summary: Fixed parser and cats conversion in order to allow cast between generic inner classes
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
+ test/tools/javac/cast/6665356/T6665356.java
+ test/tools/javac/cast/6665356/T6665356.out
+ test/tools/javac/generics/rare/6665356/T6665356.java
+ test/tools/javac/generics/rare/6665356/T6665356.out

Changeset: 09eb1acc9610
Author:    mcimadamore
Date:      2009-01-13 13:28 +0000
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/09eb1acc9610

6723444: javac fails to substitute type variables into a constructor's throws clause
Summary: Added constructor's actual type info to NewClass AST node
Reviewed-by: jjg
Contributed-by: mark at twistedbanana.demon.co.uk

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Flow.java
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
+ test/tools/javac/generics/6723444/T6723444.java
+ test/tools/javac/generics/6723444/T6723444.out

Changeset: e157bd68dfc5
Author:    mcimadamore
Date:      2009-01-13 13:31 +0000
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/e157bd68dfc5

6558559: Extra "unchecked" diagnostic
Summary: Fixed Types.sideCast in order to suppress redundant unchecked warnings
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/cast/6558559/T6558559a.java
+ test/tools/javac/cast/6558559/T6558559b.java



From xueming.shen at sun.com  Tue Jan 13 09:28:28 2009
From: xueming.shen at sun.com (xueming.shen at sun.com)
Date: Tue, 13 Jan 2009 17:28:28 +0000
Subject: hg: jdk7/tl/jdk: 6332094: "jar t" and "jar x" should use ZipFile,
	not ZipInputStream
Message-ID: <20090113172841.E4D26D577@hg.openjdk.java.net>

Changeset: 13d7e2477737
Author:    sherman
Date:      2009-01-13 09:21 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/13d7e2477737

6332094: "jar t" and "jar x" should use ZipFile, not ZipInputStream
Summary: To use ZipFile for jar "t" and "x" to boost performance
Reviewed-by: martin, alanb

! src/share/classes/sun/tools/jar/Main.java



From christopher.hegarty at sun.com  Wed Jan 14 09:24:36 2009
From: christopher.hegarty at sun.com (christopher.hegarty at sun.com)
Date: Wed, 14 Jan 2009 17:24:36 +0000
Subject: hg: jdk7/tl/jdk: 6755782: It is not clear how DatagramSocket deals
	with broadcast enabling/disabling
Message-ID: <20090114172458.6F58DD680@hg.openjdk.java.net>

Changeset: 8c1c6e11204b
Author:    chegar
Date:      2009-01-14 17:17 +0000
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8c1c6e11204b

6755782: It is not clear how DatagramSocket deals with broadcast enabling/disabling
Reviewed-by: jccollet

! src/share/classes/java/net/DatagramSocket.java



From joe.darcy at sun.com  Wed Jan 14 16:36:03 2009
From: joe.darcy at sun.com (joe.darcy at sun.com)
Date: Thu, 15 Jan 2009 00:36:03 +0000
Subject: hg: jdk7/tl/jdk: 6792545: Typo in java.util.Collection JavaDoc; ...
Message-ID: <20090115003622.488A2D7D7@hg.openjdk.java.net>

Changeset: 7f6969c09075
Author:    darcy
Date:      2009-01-14 16:23 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7f6969c09075

6792545: Typo in java.util.Collection JavaDoc
6655123: Incorrect ref to The Art of Computer Programming in doc for java.util.Random
Summary: Fix a pair of typos.
Reviewed-by: jjg

! src/share/classes/java/util/Collection.java
! src/share/classes/java/util/Random.java



From bhavesh.patel at sun.com  Thu Jan 15 17:24:43 2009
From: bhavesh.patel at sun.com (bhavesh.patel at sun.com)
Date: Fri, 16 Jan 2009 01:24:43 +0000
Subject: hg: jdk7/tl/langtools: 6786682: Javadoc HTML WCAG 2.0 accessibility
	issues in standard doclet - HTML tag should have lang attribute
Message-ID: <20090116012445.33DEDD9AF@hg.openjdk.java.net>

Changeset: d79ad96ce47c
Author:    bpatel
Date:      2009-01-15 17:21 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d79ad96ce47c

6786682: Javadoc HTML WCAG 2.0 accessibility issues in standard doclet - HTML tag should have lang attribute
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourceToHTMLConverter.java
! src/share/classes/com/sun/tools/javadoc/RootDocImpl.java
+ test/com/sun/javadoc/testHtmlTag/TestHtmlTag.java
+ test/com/sun/javadoc/testHtmlTag/pkg1/C1.java
+ test/com/sun/javadoc/testHtmlTag/pkg2/C2.java



From jonathan.gibbons at sun.com  Thu Jan 15 18:08:48 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Fri, 16 Jan 2009 02:08:48 +0000
Subject: hg: jdk7/tl/langtools: 6794520: MessageRetriever should be upgraded
	to use varargs Object...
Message-ID: <20090116020850.70F42D9B4@hg.openjdk.java.net>

Changeset: 42f9d392159d
Author:    jjg
Date:      2009-01-15 18:06 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/42f9d392159d

6794520: MessageRetriever should be upgraded to use varargs Object...
Reviewed-by: bpatel

! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MessageRetriever.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java



From joe.darcy at sun.com  Fri Jan 16 14:09:36 2009
From: joe.darcy at sun.com (joe.darcy at sun.com)
Date: Fri, 16 Jan 2009 22:09:36 +0000
Subject: hg: jdk7/tl/langtools: 6583626: Improve serialization support in
	javax.lang.model.type exception classes
Message-ID: <20090116220940.4F455DB20@hg.openjdk.java.net>

Changeset: 18c433be7aa7
Author:    darcy
Date:      2009-01-16 14:05 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/18c433be7aa7

6583626: Improve serialization support in javax.lang.model.type exception classes
Reviewed-by: jjg

! src/share/classes/javax/lang/model/type/MirroredTypeException.java
! src/share/classes/javax/lang/model/type/MirroredTypesException.java



From weijun.wang at sun.com  Mon Jan 19 02:52:55 2009
From: weijun.wang at sun.com (weijun.wang at sun.com)
Date: Mon, 19 Jan 2009 10:52:55 +0000
Subject: hg: jdk7/tl/jdk: 6793475: krb5.ini not found on some Windows
Message-ID: <20090119105314.6715ADBC8@hg.openjdk.java.net>

Changeset: 9260d9bd0843
Author:    weijun
Date:      2009-01-19 18:49 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9260d9bd0843

6793475: krb5.ini not found on some Windows
Reviewed-by: xuelei

! src/share/classes/sun/security/krb5/Config.java
! src/windows/native/sun/security/krb5/WindowsDirectory.c



From digitalemil at yahoo.de  Mon Jan 19 18:02:10 2009
From: digitalemil at yahoo.de (Emil Siemes)
Date: Tue, 20 Jan 2009 02:02:10 +0000 (GMT)
Subject: [Patch] 6502392 Invalid relative names for Filer.createResource and
	Filer.getResource
References: <5DF426C2-99DC-4E72-8C98-3933A034918E@yahoo.de>
	<4962AFBA.2090900@sun.com>
	<813911.52511.qm@web23008.mail.ird.yahoo.com>
	<61E948E5-BCD3-444B-BFE0-BBA50C8CBB37@Sun.COM>
	<418326.20769.qm@web23003.mail.ird.yahoo.com>
	<49668D51.2050308@sun.com>
	<209251.1060.qm@web23007.mail.ird.yahoo.com>
	<496BE230.8060803@sun.com>
Message-ID: <281485.44530.qm@web23004.mail.ird.yahoo.com>

Hi Jon,

sorry for the radio silence. I was and still am travelling. Your comments makes perfectly sense to me. I didn't dare to ask for changing the signature of isRelativeURI ;-)
I would also like to suggest to rename the method to isRelativePath. Passing the path as String gives also the chance to check if we hit one of those rare cases where we misinterpret the path like foo:bar.xml.

protected static boolean isRelativeUri(String relativeName) {
        URI uri =  URI.create(relativeName);
        String path= uri.getPath();

        if(!relativeName.equals(uri.getRawPath())) {
                throw new AssertionError("Unsupported relative name: " + relativeName);
        }

        if(path== null || path.length()== 0 || path.charAt(0)== '/') {
            return false;
        }

        if(!uri.normalize().getPath().equals(relativeName))
                return false;

        return true;
}

This implementation would throw an AsserionError for those unusal paths. Is that the correct handling? Or should I better just log a warning (The method is static and doesn't have automatic access to the log object)? 
The path==null check is also only necessary for "odd" urls where URI.getPath() does indeed return null in some cases. So if we throw an exception we can delete it but if we log a warning only I would prefer to keep it to prevent any NPEs.

Best Regards
    Emil






________________________________
Von: Jonathan Gibbons <Jonathan.Gibbons at Sun.COM>
An: Emil Siemes <digitalemil at yahoo.de>
CC: compiler-dev at openjdk.java.net
Gesendet: Dienstag, den 13. Januar 2009, 01:37:04 Uhr
Betreff: Re: AW: AW: AW: [Patch] 6502392 Invalid relative names for Filer.createResource and Filer.getResource

Emil,

I think the way forward is to go back and look at the spec of Filer,
and to some extent, what was likely the
original intent of the spec.

Here's the relevant part of the File spec, from http://java.sun.com/javase/6/docs/api/javax/annotation/processing/Filer.html


The methods for reading and writing resources
take a relative name argument. A relative name is a non-null, non-empty
sequence of path segments separated by '/'; '.' and '..' are invalid path segments. A valid relative name
must match the "path-rootless" rule of RFC 3986, section 3.3. 
The primary definition is "non-null, non-empty sequence of path
segments separated by '/'".  It goes on to say that . and
.. are invalid. Finally, it says they must match a spec in a section of
rfc 3986.   In particular, the Filer spec does not say that all
productions of the path-rootless rule are valid arguments.

So, to the intent.  I think that the intent is to (only) allow lowest
common denominator of relative filenames across Java platforms. As
such, allowing ":" seems a very problematic character, given its
significance on Windows.   

So, to your patch. This is definitely heading in the right direction,
although as written isRelativeURI does not check for port, authority,
query and fragment.  [It never did.] So, I have one suggestion.  If you
read the javadoc comments for isRelativeFile, and follow the
references, you get to this part of the spec at http://java.sun.com/javase/6/docs/api/javax/tools/JavaFileManager.html#relative_name
This uses the same words as found on Filer, with the following
interesting addition:

Informally, this should be true: 
  URI.create(relativeName).normalize().getPath().equals(relativeName)
This expression is very similar to the expression  you came up with. 
However, it uses "String relativeName", rather than a URI.   Looking at
JavacFileManager, isRelativeURI is only called 3 times, and always on
the result of URI.create. Since it is a protected static method on a
javac-internal API, it would be reasonable to change the signature to
take a String instead of a URI, and then we could formally check the
informal assertion given above.

For example, the code might look something like:

protected static boolean isRelativeUri(String relativeName) {
        URI uri =  URI.create(relativeName);
        String path= uri.getPath();

        if(path.length()> 0 && path.charAt(0)== '/') {
            return false;
        }

        if(path.length()== 0)
            return false;
        
        if(!uri.normalize().getPath().equals(relativeName))
                return false;
        
        return true;
      }

In terms of cleanup, this would also allow us to remove the three
comments  // FIXME 6419701 and merge them into a single new comment on
the URI.create line in isRelativeUri.

You can also simplify the code a tiny bit more by reordering the first
two if statements and thereby eliminating the redundant check on
path.length() > 0.


-- Jon



Emil Siemes wrote: 
Hi Jon,

thank you very much for providing insight!

Please find an improved isRelativeUri method below. It fixes accepting
invalid paths like foo/../bar and accepts valid path like .something
Unfortunately I now believe that using URI is not the right way to go:
"foo:/bar.xml" is a valid relative pathname but when we construct a
URI("foo:/bar.xml") the first part "foo:" is treated as schema
obviously.
getPath() then returns /bar.xml and this fails isRelative.
Similar new URI("foo#bar.xml").getPath() returns "foo" and is accepted
by isRelative while "foo#bar.xml" is a non-valid relative path.

I tried using other URI constructors with explicitly setting schema and
fragment to "" but URI doesn't accept this: 
 java.net.URISyntaxException: Relative path in absolute URI:
://src/foo.java#
It looks to me like using URI in our context is somehow miss-using the
class and it will be difficult to make it water-proof.


I think we can either use URI in isRelative and accept that there are
still glitches or create a isRelative which parses the path on its own.
Please let me know what you think. If you prefer a URI based isRelative
I would create the patch with the method below. If you prefer a
URI-free version now I will create a new patch since the path I sent
out before also uses URI.


protected static boolean isRelativeUri(URI uri) {
        String path= uri.getPath();

        if(path.length()> 0 && path.charAt(0)== '/') {
            return false;
        }

        if(path.length()== 0)
            return false;
        
        if(!path.equals(uri.normalize().getPath()))
                return false;
        
        return true;
      }








________________________________
Von: Jonathan Gibbons <Jonathan.Gibbons at Sun.COM>
An: Emil Siemes <digitalemil at yahoo.de>
CC: compiler-dev at openjdk.java.net
Gesendet: Freitag, den
9. Januar 2009, 00:33:37 Uhr
Betreff: Re: AW: AW:
[Patch] 6502392 Invalid relative names for Filer.createResource and
Filer.getResource

Emil,

Comments inline.

-- Jon


Emil Siemes wrote: 
Hi Jon,

RFC 3986 Appendix D describes the additions and modifications
vs. 2396.
Basically 3986 tries to make things clearer. They say there
have
been a lot of discussions and different interpretations of 2396.
(Sounds like JME fragmentation to me ;-)
A new ABNF was used, IPV6 literals added. URI normalization
and
comparison was rewritten.
Clarification of reserved and unreserved characters. Support
for
an empty path component were added.
OK, thanks for the summary.


6791041 & 6791060 seem to be non-public. Will this change
soon? I were not able to find them on bugs.sun..com
They should now be available on bugs.sun.com.  There is sometimes a
short delay in propogating bugs 
from the internal bug database to the external site.



If there is more information available on 6791041 I could look
for potential interpretation issues in the java.net.URI implementation
vs. 3986 spec.
6791041 provided a case where someone actually tried to have a relative
path beginning with ".", such as ".foo"



I should have a new isRelativeURI Monday latest. Would be good
to know what 6791041 is about by then.
Apparently, there was an attempt in JDK 6 to update URI for 3986, and
the work had to be reverted
for compatibility issues. This makes me less optimistic that we might
see any evolution for JDK 7.
As such, I think we should leverage what is in URI as much as possible,
and apply any necessary
extra work in JavacFileManager -- which is essentially where you are
heading, I believe.




For the missing FileNotFoundException in JavacFiler I think
the
clearest solution is to explicitly check for file existence in the
method. 
Something like:

getResource(...

FileObject fileobject= ...

if(!new File(fileobject.toURI().exists())
     throw new FileNotFoundException();
}

Unfortunately this would include another creation of an URI
object but FileObject..getName() only returns a "user friendly" file
name which I understand is not necessarily useable for a File-Object
creation.
The fileobject involved in getResource & createResource is
actually a com.sun.tools.javac.file.RegularFileObject with a File
object as field. So another solution would be to either expose this
File object or add an exists() method to RegularFileObject which
delegates the call to file Object and cast the FileObject to a
RegularFileObject. (too ugly I believe).
You cannot call "new File(...)" or more generally, use any of the File
API outside of the javac.file package, except to some extent in the
command line processing classes (Main and JavaCompiler.) This is
because the compilation units might not be coming directly from files
in the host file system.   In an IDE using JSR199, for example, the
compilation units might come from a database or from string buffers,
depending on the implementation of JavaFileManager in use. The only
real solution would be to add a new exists() method to FileObject and
use that, but that too would be problematic because that would be a
binary-incompatible change. The best we can probably do in the short
term is to test if the
fileObject is an instance of RegularFileObject or perhaps
BaseFileObject, and only apply the check in that case. Which is
somewhat uglier than your "too ugly I believe" but arguably the best we
can do, for now. :-(

Longer term, I note as background that JavaFileManager was designed as
a "virtual file system as defined by the needs of javac". Some wise
person once made comments about "as simple as possible but no
simpler".  I think JavaFileManager ended up a tad too simple. 
Separately, JSR 203 ("Son of NIO") is providing a more general virtual
file system API.  I think it would be interesting to see an impl of
JavaFileManager/FileObject/JavaFileObject built on top of the JSR 203
APIs. This would then allow applications that wanted to use JSR199 to
drive the compiler using a "non-standard" file system to use the JSR
203 API to describe that file system instead of the JavaFileManager
API.  Put another way, if JSR203 had been available in time for JDK 6,
I don't think we would have bothered with JavaFileManager etc.  The
point of all of which is to say that the way forward here is to
(eventually) provide an adapter for JSR 203, and to encourage folk to
use JSR 203 as a way to provide virtual file systems.




Thanks
   Emil












________________________________
Von: Jonathan Gibbons <Jonathan.Gibbons at Sun.COM>
An: Emil Siemes <digitalemil at yahoo.de>
CC: compiler-dev at openjdk.java.net
Gesendet: Mittwoch,
den 7. Januar 2009, 18:07:35 Uhr
Betreff: Re: AW:
[Patch] 6502392 Invalid relative names for Filer.createResource and
Filer..getResource

Emil, 

First, some updates.
1) 6791041 has come in, which reports a specific instance of a
user encountering the issue you have been looking at. Specifically,
the submitter is affected by the "quick and dirty" check in
isRelativeURI.
2) I have filed 6791060 against java.net.URI

It sounds like you are reasonably familiar with the RFCs
involved here.. If so, can you briefly summarize any relevant differences
between RFC 2396 (used by java.net.URI) and RFC 3986 (used by
JSR 269 and Filer.)

-- Jon


On Jan 6, 2009, at 8:21 AM, Emil Siemes wrote:

Hi Jon,

true, the code actually does things
which
would belong into java.net.URI. Reason for this is that JSR269 requires
compliance with path-rootless rule of RFC3986 whereas java.net.URI
supports the older and obsolete RFC 2396. Basically I was afraid of
relying on the old implementation but that can be changed of course.
Given the limitation of the actual URI
implementation it might be tricky to achieve compliance with the JSR269
requirements without parsing URI..getPath(). Dot-segments are not
allowed as relative path names in JSR269 but are fine for the URI
class. The current implementation calls URI.normalize().getPath() which
actually removes dot-segments and therefore doesn't throw an exception. 

Given your feedback I propose I rewrite
my code in a way that it relies on java.net.URI and does a quick check
on the path. May be I can compare URI.getPath() and
URI.normalize().getPath() to find out if any dot-segments are part of
the path. I'll check and let you know.

Thanks
   Emil


 




________________________________
Von: Jonathan Gibbons <Jonathan.Gibbons at Sun.COM>
An: Emil Andreas Siemes <digitalemil at yahoo.de>
CC: compiler-dev at openjdk.java.net
Gesendet: Dienstag, den 6. Januar 2009,
02:11:22 Uhr
Betreff: Re: [Patch] 6502392 Invalid
relative names for Filer.createResource and Filer.getResource

Emil,

Thank you for looking at this, and for your patch.

I do not understand why 6419701 is not public. I am trying to find out
why it is not.
The bug itself is about the use of URI.create, not about the use of
isRelativeURI..

I'm not sure that your patch is warranted (or arguably, the correct
fix).  Your patch certainly 
contains functionality that on the face of it would better belong in
java.net.URI and not 
JavacFileManager. 

The way I read the code in JavacFileManager, isRelativeURI is not
intended to be a full and 
complete implementation of checking whether a URI is path-rootless.
Instead, it is used in 
exactly 3 places, and always in conjunction with URI.create. 
JavacFileManager is assuming 
the full syntax checking is done by URI.create, and is just using a
simple impl of 
isRelativeURI to distinguish relative URIs from absolute URIs created
by URI.create.

6419701 is about removing the use of URI.create -- presumably because
it is mildly icky
to create the URI object just to check whether a path string is a valid
URI.  So it seems 
to me that there are two ways to take this issue:  
1) Rewrite isRelativeURI to take a String argument and thereby avoid
the use of URI.create
2) Wait for URI to have some better method for checking the validity of
a path without
actually constructing the URI object.

I guess that I dislike JavacFileManager having code for detailed
parsing of URIs, and so
I think the current impl is better, of using URI.create to check the
syntax of a URI, and
then apply a quick check as to whether it is absolute or relative is
better.

Or am I misreading the situation or perhaps missing some subtlety in
your proposed code?

-- Jon


Emil Andreas Siemes wrote: 
com.sun.tools.javac.file.JavacFileManager
checks if a name fulfills the requirements of relative names:

"A relative name is a
non-null, non-empty sequence of path segments separated by '/'; '.' and '..' are
invalid path segments. A valid relative name must match the
"path-rootless" rule of RFC 3986,
section 3.3."

This is done via the isRelativeUri()
method. Unfortunately this method doesn't currently really check for
path-rootless compliance. A patch with an improved method is attached.
When java.net.Uri eventually supports
RFC 3986 the need for isRelativeUri() goes away.. I would also like to
propose to rename isRelativeUri() to isRF3986PathRootless() which would
more clearly describe what the method does.

There is a comment in
JavacFileManager
in a couple of lines:
//FIX ME 6419701
but I don't find bug 6419701 in the
bug
database. Any thoughts?

Thanks
    Emil




 
________________________________


________________________________


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

From digitalemil at yahoo.de  Mon Jan 19 18:16:46 2009
From: digitalemil at yahoo.de (Emil Siemes)
Date: Tue, 20 Jan 2009 02:16:46 +0000 (GMT)
Subject: AW: AW: AW: AW: 6502395: Is not a bug
References: <540A46B0-ABB5-47AB-911B-0249BDCA644E@yahoo.de>
Message-ID: <684041.53585.qm@web23004.mail.ird.yahoo.com>

Hi Jon,

I created two methods for JavacFiler which would do the necessary checks and throw the missing exceptions.
checkExistence needs to be called by getResource and checkFileCreation by createResource.
Unfortunately RegularFileObject is not accessible from the com.sun.tools.javac.processing package that's why I thought of using reflection.
For FileObjects not extending RegularFileObject I thought of opening the stream as test for existence. Is that too heavy weight? Shall I better just completely ignore those cases? If you think that in principle it is ok to open the stream as check I would surround the openIn/OutputStream with a try/catch clause to make sure close gets always called.
For createResource the test actually already creates the file but I think that should be ok because the only real test whether a file could be created is to create it. An alternatice would be to delete the file in the test after creating it which should be fine for any not "write only once" filesystems. What are your thoughts?

Emil


private void checkExistence(FileObject fo) throws IOException {
        Class foclass= fo.getClass();
        do {
            if(foclass.getName().equals("com.sun.tools.java.file.RegularFileObject")) {
                if(!new File(fo.toUri()).exists()) {
                    throw new FileNotFoundException("Resource does not exists: "+fo.getName());
                }
                return;
            }
            foclass= foclass.getSuperclass();
        }
        while(foclass!= null);
        InputStream in= fo.openInputStream();
        in.close();
    }

    private void checkFileCreation(FileObject fo) throws IOException {
        Class foclass= fo.getClass();
        do {
            if(foclass.getName().equals("com.sun.tools.java.file.RegularFileObject")) {
                File file= new File(fo.toUri());
                try {
                    if(!file.createNewFile()) {
                        OutputStream out= fo.openOutputStream();
                        out.close();
                    }
InputStream in= fo.openInputStream();
        in.close();
    }

    private void checkFileCreation(FileObject fo) throws IOException {
        Class foclass= fo.getClass();
        do {
            if(foclass.getName().equals("com.sun.tools.java.file.RegularFileObject")) {
                File file= new File(fo.toUri());
                try {
                    if(!file.createNewFile()) {
                        OutputStream out= fo.openOutputStream();
                        out.close();
                    }
                }
                catch(SecurityException e) {
                    throw new IOException("Not allowed to create resource: "+fo.getName());
                }
                return;
            }
            foclass= foclass.getSuperclass();
        }
        while(foclass!= null);
        OutputStream out= fo.openOutputStream();
        out.close();
    }





________________________________
Von: Emil Andreas Siemes <digitalemil at yahoo.de>
An: Jonathan Gibbons <Jonathan.Gibbons at Sun.COM>; compiler-dev at openjdk.java.net
Gesendet: Dienstag, den 6. Januar 2009, 18:35:04 Uhr
Betreff: AW: AW: AW: 6502395: Is not a bug

Hi Jon,

regarding the bug as it is reported nothing changed:
"When we are trying to open nonexistent resource we should expect IOException thrown. 
However getting nonexistent resource doesn't cause to IOException. Instead IllegalStateExceptionis thrown."
This is because the bug report uses createResource().openReader() and not getResource().openReader() and throwing IllegalStateException is expected in this case.
Nevertheless there is an issue with the current implementations:
JDK6u11:
getResource(... "unexisting-resource" ...) doesn't throw any exception. Ugly, spec is says IOException has to be thrown.
getResource(... "unexisting-resource" ...).openReader() throws UnsupportedOperationException. Ugly.

OpenJDK7 (b18, b24, 41 & 42):
getResource(... "unexisting-resource" ...) doesn't throw any exception. Ugly, spec is says IOException has to be thrown.
getResource(... "unexisting-resource" ...).openReader() throws FileNotFoundException. Better.

Let me investigate where we can insert a check for the existence of the file to be opened. Then we can throw FileNotFound in getResource()...
Thanks
Emil








________________________________
Von: Jonathan Gibbons <Jonathan.Gibbons at Sun.COM>
An: Emil Siemes <digitalemil at yahoo.de>
CC: compiler-dev at openjdk.java.net
Gesendet: Dienstag, den 6. Januar 2009, 00:07:16 Uhr
Betreff: Re: AW: AW: 6502395: Is not a bug

Emil,

The spec is what it is, and cannot easily be changed. And, being pedantic, the spec does not require the file
to be opened; it merely says that an exception must be thrown if the file cannot be opened. The implementation
may perform a number of checks to determine whether the file can be opened in principle without actually
opening it.

What is your current disposition regarding this bug?  Are you now saying the javac behavior and the test's
behavior are now both correct?

-- Jon



Emil Siemes wrote:
Seems I was a bit too fast. When I tried b18 (see last mail) the path to java was correct but I still used JDK6u11 javac.
After correcting the setup b18 also throws FileNotFoundException (which is the correct behavior). So the bug was fixed before b18.

But the method which throws the exception in the following code  
"FileObject fo = filer.getResource(location, "", "foo/" + location + "..unexisting");
Reader reader = fo.openReader(true);"
is openReader not getResource as the spec suggests:

java.io.FileNotFoundException: foo/SOURCE_OUTPUT.unexisting (No such file or directory)
    at java.io.FileInputStream.open(Native Method)
    at java.io.FileInputStream.<init>(FileInputStream.java:137)
    at com.sun.tools.javac.file.RegularFileObject.openInputStream(RegularFileObject.java:68)
    at com.sun.tools.javac.file.BaseFileObject.openReader(BaseFileObject.java:76)



getResource
FileObject getResource(JavaFileManager.Location location,
CharSequence pkg,
CharSequence relativeName)
                       throws IOException
Returns an object for reading an existing resource. The locations CLASS_OUTPUT andSOURCE_OUTPUT must be supported.
Parameters:
location - location of the file
pkg - package relative to which the file should be searched, or the empty string if none
relativeName - final pathname components of the file
Returns:
an object to read the file
Throws:
FilerException - if the same pathname has already been opened for writing
IOException - if the file cannot be openedI'm challenging the spec a bit. Why should getResource() open the file at all? I think the normal behavior is like in the bug report:
getResource and then try opening the resource and expecting an exception if it fails. And as we see this is how the implementation works: getResource() returns a FileObject but doesn't open it and doesn't test if the file could be openend.

Any thoughts?

 









________________________________
Von: Emil Siemes <digitalemil at yahoo.de>
An: Mark Wielaard <mark at klomp.org>
CC: compiler-dev at openjdk.java.net; Jonathan Gibbons <Jonathan.Gibbons at Sun.COM>
Gesendet: Dienstag, den 16. Dezember 2008, 14:01:24 Uhr
Betreff: AW: 6502395: Is not a bug


Hi Mark,

thanks for the links. I was able to test b18 and at least this build still throws UnsupportedOperationException.
I now wanted to follow-up the path but it seems that the fedoraproject has some database issues...
Will try again later. And yes a central repository with all old binary & source bundles would be helpful.

Thanks
  Emil




________________________________
Von: Mark Wielaard <mark at klomp.org>
An: Dalibor Topic <Dalibor.Topic at Sun.COM>
CC: Jonathan Gibbons <Jonathan.Gibbons at Sun.COM>; compiler-dev at openjdk.java.net
Gesendet: Samstag, den 13. Dezember 2008, 21:52:15 Uhr
Betreff: Re: 6502395: Is not a bug

On Sat, 2008-12-13 at 21:25 +0100, Dalibor Topic wrote:
> Martin Buchholz wrote:
> > On Fri, Dec 12, 2008 at 08:56, Jonathan Gibbons
> > <Jonathan.Gibbons at sun.com> wrote:
> > 
> >> Like you, I could not find public builds for JDK7 builds earlier than b36. I
> >> am sorry (and somewhat surprised) that they are not available.
> > 
> > I complained about this elsewhere.
> > Lack of hardware resources to hold the archives were cited.
> > 
> > I'd like to see every build remain available for download for at least 3 years.
> 
> Did I hear someone volunteering to build & maintain a mirror? ;)

We do keep a mirror of the old GPL sources (which came from the svn
repository) in mercurial at http://icedtea.classpath.org/hg/openjdk if
anybody needs anything early (b13 till b23). Although the changes
between the bxx drops are somewhat big, you can do some simple
investigations against it through mercurial.

Also various GNU/Linux distros still have old GPL binary icedtea/openjdk
1.7 packages (and source code of course) around (although most are
tracking jdk6 these days). Here are old builds of the 1.7.0 tree (b18
till b24) for Fedora 8/9 for example:
http://koji.fedoraproject.org/koji/packageinfo?packageID=4946

Cheers,

Mark


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

From Jonathan.Gibbons at Sun.COM  Mon Jan 19 18:46:40 2009
From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons)
Date: Mon, 19 Jan 2009 18:46:40 -0800
Subject: [Patch] 6502392 Invalid relative names for Filer.createResource
	and Filer.getResource
In-Reply-To: <281485.44530.qm@web23004.mail.ird.yahoo.com>
References: <5DF426C2-99DC-4E72-8C98-3933A034918E@yahoo.de>
	<4962AFBA.2090900@sun.com>
	<813911.52511.qm@web23008.mail.ird.yahoo.com>
	<61E948E5-BCD3-444B-BFE0-BBA50C8CBB37@Sun.COM>
	<418326.20769.qm@web23003.mail.ird.yahoo.com>
	<49668D51.2050308@sun.com>
	<209251.1060.qm@web23007.mail.ird.yahoo.com> <496BE230.8060803@sun.com>
	<281485.44530.qm@web23004.mail.ird.yahoo.com>
Message-ID: <CE1D4BE4-E812-4267-B206-9EE3BA1F84CF@Sun.COM>

IllegalArgumentException would seem a better choice than  
AssertionError, since the only "assrtion" being tested is that the  
caller has provided a valid argument.

The method is only static because it can be, and because it was  
natural when it was written. We could make it not static if that bwere  
convenient, but using log seems wrong -- that is for reporting user- 
level diagnostics.

As a very minor point, note that the coding convention tends towards a  
space between 'if' and '('.  More pragmatically, the rule would be  
something like "as much as possible, make your code look like the  
surrounding code".

Happy travels.

-- Jon


On Jan 19, 2009, at 6:02 PM, Emil Siemes wrote:

> Hi Jon,
>
> sorry for the radio silence. I was and still am travelling. Your  
> comments makes perfectly sense to me. I didn't dare to ask for  
> changing the signature of isRelativeURI ;-)
> I would also like to suggest to rename the method to isRelativePath.  
> Passing the path as String gives also the chance to check if we hit  
> one of those rare cases where we misinterpret the path like  
> foo:bar.xml.
>
> protected static boolean isRelativeUri(String relativeName) {
>         URI uri =  URI.create(relativeName);
>         String path= uri.getPath();
>
>         if(!relativeName.equals(uri.getRawPath())) {
>                 throw new AssertionError("Unsupported relative name:  
> " + relativeName);
>         }
>
>         if(path== null || path.length()== 0 || path.charAt(0)== '/') {
>             return false;
>         }
>
>         if(!uri.normalize().getPath().equals(relativeName))
>                 return false;
>
>         return true;
> }
>
> This implementation would throw an AsserionError for those unusal  
> paths. Is that the correct handling? Or should I better just log a  
> warning (The method is static and doesn't have automatic access to  
> the log object)?
> The path==null check is also only necessary for "odd" urls where  
> URI.getPath() does indeed return null in some cases. So if we throw  
> an exception we can delete it but if we log a warning only I would  
> prefer to keep it to prevent any NPEs.
>
> Best Regards
>     Emil
>
>
>
> Von: Jonathan Gibbons <Jonathan.Gibbons at Sun.COM>
> An: Emil Siemes <digitalemil at yahoo.de>
> CC: compiler-dev at openjdk.java.net
> Gesendet: Dienstag, den 13. Januar 2009, 01:37:04 Uhr
> Betreff: Re: AW: AW: AW: [Patch] 6502392 Invalid relative names for  
> Filer.createResource and Filer.getResource
>
> Emil,
>
> I think the way forward is to go back and look at the spec of Filer,  
> and to some extent, what was likely the
> original intent of the spec.
>
> Here's the relevant part of the File spec, from http://java.sun.com/javase/6/docs/api/javax/annotation/processing/Filer.html
>
>> The methods for reading and writing resources take a relative name  
>> argument. A relative name is a non-null, non-empty sequence of path  
>> segments separated by '/'; '.' and '..' are invalid path segments.  
>> A valid relative name must match the "path-rootless" rule of RFC  
>> 3986, section 3..3.
>
> The primary definition is "non-null, non-empty sequence of path  
> segments separated by '/'".  It goes on to say that . and .. are  
> invalid. Finally, it says they must match a spec in a section of rfc  
> 3986.   In particular, the Filer spec does not say that all  
> productions of the path-rootless rule are valid arguments.
>
> So, to the intent.  I think that the intent is to (only) allow  
> lowest common denominator of relative filenames across Java  
> platforms. As such, allowing ":" seems a very problematic character,  
> given its significance on Windows.
>
> So, to your patch. This is definitely heading in the right  
> direction, although as written isRelativeURI does not check for  
> port, authority, query and fragment.  [It never did.] So, I have one  
> suggestion.  If you read the javadoc comments for isRelativeFile,  
> and follow the references, you get to this part of the spec athttp://java.sun.com/javase/6/docs/api/javax/tools/JavaFileManager.html#relative_name
> This uses the same words as found on Filer, with the following  
> interesting addition:
>> Informally, this should be true:
>>   URI.create(relativeName).normalize().getPath().equals(relativeName)
> This expression is very similar to the expression  you came up  
> with.  However, it uses "String relativeName", rather than a URI.    
> Looking at JavacFileManager, isRelativeURI is only called 3 times,  
> and always on the result of URI.create. Since it is a protected  
> static method on a javac-internal API, it would be reasonable to  
> change the signature to take a String instead of a URI, and then we  
> could formally check the informal assertion given above.
>
> For example, the code might look something like:
>
> protected static boolean isRelativeUri(String relativeName) {
>         URI uri =  URI.create(relativeName);
>         String path= uri.getPath();
>
>         if(path.length()> 0 && path.charAt(0)== '/') {
>             return false;
>         }
>
>         if(path.length()== 0)
>             return false;
>
>         if(!uri.normalize().getPath().equals(relativeName))
>                 return false;
>
>         return true;
>       }
>
> In terms of cleanup, this would also allow us to remove the three  
> comments  // FIXME 6419701 and merge them into a single new comment  
> on the URI.create line in isRelativeUri.
>
> You can also simplify the code a tiny bit more by reordering the  
> first two if statements and thereby eliminating the redundant check  
> on path.length() > 0.
>
>
> -- Jon
>
>
>
> Emil Siemes wrote:
>>
>> Hi Jon,
>>
>> thank you very much for providing insight!
>>
>> Please find an improved isRelativeUri method below. It fixes  
>> accepting invalid paths like foo/../bar and accepts valid path  
>> like .something
>> Unfortunately I now believe that using URI is not the right way to  
>> go:
>> "foo:/bar.xml" is a valid relative pathname but when we construct a  
>> URI("foo:/bar.xml") the first part "foo:" is treated as schema  
>> obviously.
>> getPath() then returns /bar.xml and this fails isRelative.
>> Similar new URI("foo#bar.xml").getPath() returns "foo" and is  
>> accepted by isRelative while "foo#bar..xml" is a non-valid relative  
>> path.
>>
>> I tried using other URI constructors with explicitly setting schema  
>> and fragment to "" but URI doesn't accept this:
>>  java.net.URISyntaxException: Relative path in absolute URI: ://src/ 
>> foo.java#
>> It looks to me like using URI in our context is somehow miss-using  
>> the class and it will be difficult to make it water-proof.
>>
>>
>> I think we can either use URI in isRelative and accept that there  
>> are still glitches or create a isRelative which parses the path on  
>> its own.
>> Please let me know what you think. If you prefer a URI based  
>> isRelative I would create the patch with the method below. If you  
>> prefer a URI-free version now I will create a new patch since the  
>> path I sent out before also uses URI.
>>
>>
>> protected static boolean isRelativeUri(URI uri) {
>>         String path= uri.getPath();
>>
>>         if(path.length()> 0 && path.charAt(0)== '/') {
>>             return false;
>>         }
>>
>>         if(path.length()== 0)
>>             return false;
>>
>>         if(!path.equals(uri.normalize().getPath()))
>>                 return false;
>>
>>         return true;
>>       }
>>
>>
>>
>>
>>
>> Von: Jonathan Gibbons <Jonathan.Gibbons at Sun.COM>
>> An: Emil Siemes <digitalemil at yahoo.de>
>> CC: compiler-dev at openjdk.java.net
>> Gesendet: Freitag, den 9. Januar 2009, 00:33:37 Uhr
>> Betreff: Re: AW: AW: [Patch] 6502392 Invalid relative names for  
>> Filer.createResource and Filer.getResource
>>
>> Emil,
>>
>> Comments inline.
>>
>> -- Jon
>>
>>
>> Emil Siemes wrote:
>>>
>>> Hi Jon,
>>>
>>> RFC 3986 Appendix D describes the additions and modifications vs.  
>>> 2396.
>>> Basically 3986 tries to make things clearer. They say there have  
>>> been a lot of discussions and different interpretations of 2396.  
>>> (Sounds like JME fragmentation to me ;-)
>>> A new ABNF was used, IPV6 literals added. URI normalization and  
>>> comparison was rewritten.
>>> Clarification of reserved and unreserved characters. Support for  
>>> an empty path component were added.
>>
>> OK, thanks for the summary.
>>
>>> 6791041 & 6791060 seem to be non-public. Will this change soon? I  
>>> were not able to find them on bugs.sun..com
>> They should now be available on bugs.sun.com.  There is sometimes a  
>> short delay in propogating bugs
>> from the internal bug database to the external site.
>>
>>
>>> If there is more information available on 6791041 I could look for  
>>> potential interpretation issues in the java.net.URI implementation  
>>> vs. 3986 spec.
>> 6791041 provided a case where someone actually tried to have a  
>> relative path beginning with ".", such as ".foo"
>>>
>>> I should have a new isRelativeURI Monday latest. Would be good to  
>>> know what 6791041 is about by then.
>> Apparently, there was an attempt in JDK 6 to update URI for 3986,  
>> and the work had to be reverted
>> for compatibility issues. This makes me less optimistic that we  
>> might see any evolution for JDK 7.
>> As such, I think we should leverage what is in URI as much as  
>> possible, and apply any necessary
>> extra work in JavacFileManager -- which is essentially where you  
>> are heading, I believe.
>>
>>>
>>> For the missing FileNotFoundException in JavacFiler I think the  
>>> clearest solution is to explicitly check for file existence in the  
>>> method.
>>> Something like:
>>>
>>> getResource(...
>>>
>>> FileObject fileobject= ...
>>>
>>> if(!new File(fileobject.toURI().exists())
>>>      throw new FileNotFoundException();
>>> }
>>>
>>> Unfortunately this would include another creation of an URI object  
>>> but FileObject..getName() only returns a "user friendly" file name  
>>> which I understand is not necessarily useable for a File-Object  
>>> creation.
>>> The fileobject involved in getResource & createResource is  
>>> actually a com.sun.tools.javac.file.RegularFileObject with a File  
>>> object as field. So another solution would be to either expose  
>>> this File object or add an exists() method to RegularFileObject  
>>> which delegates the call to file Object and cast the FileObject to  
>>> a RegularFileObject. (too ugly I believe).
>>
>> You cannot call "new File(...)" or more generally, use any of the  
>> File API outside of the javac.file package, except to some extent  
>> in the command line processing classes (Main and JavaCompiler.)  
>> This is because the compilation units might not be coming directly  
>> from files in the host file system.   In an IDE using JSR199, for  
>> example, the compilation units might come from a database or from  
>> string buffers, depending on the implementation of JavaFileManager  
>> in use. The only real solution would be to add a new exists()  
>> method to FileObject and use that, but that too would be  
>> problematic because that would be a binary-incompatible change. The  
>> best we can probably do in the short term is to test if the
>> fileObject is an instance of RegularFileObject or perhaps  
>> BaseFileObject, and only apply the check in that case. Which is  
>> somewhat uglier than your "too ugly I believe" but arguably the  
>> best we can do, for now. :-(
>>
>> Longer term, I note as background that JavaFileManager was designed  
>> as a "virtual file system as defined by the needs of javac". Some  
>> wise person once made comments about "as simple as possible but no  
>> simpler".  I think JavaFileManager ended up a tad too simple.   
>> Separately, JSR 203 ("Son of NIO") is providing a more general  
>> virtual file system API.  I think it would be interesting to see an  
>> impl of JavaFileManager/FileObject/JavaFileObject built on top of  
>> the JSR 203 APIs. This would then allow applications that wanted to  
>> use JSR199 to drive the compiler using a "non-standard" file system  
>> to use the JSR 203 API to describe that file system instead of the  
>> JavaFileManager API.  Put another way, if JSR203 had been available  
>> in time for JDK 6, I don't think we would have bothered with  
>> JavaFileManager etc.  The point of all of which is to say that the  
>> way forward here is to (eventually) provide an adapter for JSR 203,  
>> and to encourage folk to use JSR 203 as a way to provide virtual  
>> file systems.
>>
>>>
>>> Thanks
>>>    Emil
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Von: Jonathan Gibbons <Jonathan.Gibbons at Sun.COM>
>>> An: Emil Siemes <digitalemil at yahoo.de>
>>> CC: compiler-dev at openjdk.java.net
>>> Gesendet: Mittwoch, den 7. Januar 2009, 18:07:35 Uhr
>>> Betreff: Re: AW: [Patch] 6502392 Invalid relative names for  
>>> Filer.createResource and Filer..getResource
>>>
>>> Emil,
>>>
>>> First, some updates.
>>> 1) 6791041 has come in, which reports a specific instance of a  
>>> user encountering the issue you have been looking at. Specifically,
>>> the submitter is affected by the "quick and dirty" check in  
>>> isRelativeURI..
>>> 2) I have filed 6791060 against java.net.URI
>>>
>>> It sounds like you are reasonably familiar with the RFCs involved  
>>> here. If so, can you briefly summarize any relevant differences
>>> between RFC 2396 (used by java.net.URI) and RFC 3986 (used by JSR  
>>> 269 and Filer.)
>>>
>>> -- Jon
>>>
>>> On Jan 6, 2009, at 8:21 AM, Emil Siemes wrote:
>>>
>>>> Hi Jon,
>>>>
>>>> true, the code actually does things which would belong into  
>>>> java.net.URI. Reason for this is that JSR269 requires compliance  
>>>> with path-rootless rule of RFC3986 whereas java.net.URI supports  
>>>> the older and obsolete RFC 2396. Basically I was afraid of  
>>>> relying on the old implementation but that can be changed of  
>>>> course.
>>>> Given the limitation of the actual URI implementation it might be  
>>>> tricky to achieve compliance with the JSR269 requirements without  
>>>> parsing URI..getPath(). Dot-segments are not allowed as relative  
>>>> path names in JSR269 but are fine for the URI class. The current  
>>>> implementation calls URI.normalize().getPath() which actually  
>>>> removes dot-segments and therefore doesn't throw an exception.
>>>>
>>>> Given your feedback I propose I rewrite my code in a way that it  
>>>> relies on java.net.URI and does a quick check on the path. May be  
>>>> I can compare URI.getPath() and URI.normalize().getPath() to find  
>>>> out if any dot-segments are part of the path. I'll check and let  
>>>> you know.
>>>>
>>>> Thanks
>>>>    Emil
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Von: Jonathan Gibbons <Jonathan.Gibbons at Sun.COM>
>>>> An: Emil Andreas Siemes <digitalemil at yahoo.de>
>>>> CC: compiler-dev at openjdk.java.net
>>>> Gesendet: Dienstag, den 6. Januar 2009, 02:11:22 Uhr
>>>> Betreff: Re: [Patch] 6502392 Invalid relative names for  
>>>> Filer.createResource and Filer.getResource
>>>>
>>>> Emil,
>>>>
>>>> Thank you for looking at this, and for your patch.
>>>>
>>>> I do not understand why 6419701 is not public. I am trying to  
>>>> find out why it is not.
>>>> The bug itself is about the use of URI.create, not about the use  
>>>> of isRelativeURI..
>>>>
>>>> I'm not sure that your patch is warranted (or arguably, the  
>>>> correct fix).  Your patch certainly
>>>> contains functionality that on the face of it would better belong  
>>>> in java.net.URI and not
>>>> JavacFileManager.
>>>>
>>>> The way I read the code in JavacFileManager, isRelativeURI is not  
>>>> intended to be a full and
>>>> complete implementation of checking whether a URI is path- 
>>>> rootless. Instead, it is used in
>>>> exactly 3 places, and always in conjunction with URI.create.   
>>>> JavacFileManager is assuming
>>>> the full syntax checking is done by URI.create, and is just using  
>>>> a simple impl of
>>>> isRelativeURI to distinguish relative URIs from absolute URIs  
>>>> created by URI.create.
>>>>
>>>> 6419701 is about removing the use of URI.create -- presumably  
>>>> because it is mildly icky
>>>> to create the URI object just to check whether a path string is a  
>>>> valid URI.  So it seems
>>>> to me that there are two ways to take this issue:
>>>> 1) Rewrite isRelativeURI to take a String argument and thereby  
>>>> avoid the use of URI.create
>>>> 2) Wait for URI to have some better method for checking the  
>>>> validity of a path without
>>>> actually constructing the URI object.
>>>>
>>>> I guess that I dislike JavacFileManager having code for detailed  
>>>> parsing of URIs, and so
>>>> I think the current impl is better, of using URI.create to check  
>>>> the syntax of a URI, and
>>>> then apply a quick check as to whether it is absolute or relative  
>>>> is better.
>>>>
>>>> Or am I misreading the situation or perhaps missing some subtlety  
>>>> in your proposed code?
>>>>
>>>> -- Jon
>>>>
>>>>
>>>> Emil Andreas Siemes wrote:
>>>>>
>>>>> com.sun.tools.javac.file.JavacFileManager checks if a name  
>>>>> fulfills the requirements of relative names:
>>>>> "A relative name is a non-null, non-empty sequence of path  
>>>>> segments separated by '/'; '.' and '..' are invalid path  
>>>>> segments. A valid relative name must match the "path-rootless"  
>>>>> rule of RFC 3986, section 3.3."
>>>>>
>>>>> This is done via the isRelativeUri() method. Unfortunately this  
>>>>> method doesn't currently really check for path-rootless  
>>>>> compliance. A patch with an improved method is attached.
>>>>> When java.net.Uri eventually supports RFC 3986 the need for  
>>>>> isRelativeUri() goes away.. I would also like to propose to  
>>>>> rename isRelativeUri() to isRF3986PathRootless() which would  
>>>>> more clearly describe what the method does.
>>>>>
>>>>> There is a comment in JavacFileManager in a couple of lines:
>>>>> //FIX ME 6419701
>>>>> but I don't find bug 6419701 in the bug database. Any thoughts?
>>>>>
>>>>> Thanks
>>>>>     Emil
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>

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

From Jonathan.Gibbons at Sun.COM  Mon Jan 19 18:55:13 2009
From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons)
Date: Mon, 19 Jan 2009 18:55:13 -0800
Subject: AW: AW: AW: AW: 6502395: Is not a bug
In-Reply-To: <684041.53585.qm@web23004.mail.ird.yahoo.com>
References: <540A46B0-ABB5-47AB-911B-0249BDCA644E@yahoo.de>
	<684041.53585.qm@web23004.mail.ird.yahoo.com>
Message-ID: <46B679D1-9089-49F2-92CD-0C2B3AC63ECA@Sun.COM>

Uuugh.  There is clearly some API missing.   We have  
StandardJavaFileManager as a subtype of JavaFileManager, but there is  
no corresponding public subtype of [Java]FileObject. There needs to  
be, but that is a separate issue.  In the meantime, making  
RegularFileObject public is better than using reflection, and an  
import statement is better than a fully qualified name deep in the
code.

I would ignore, for now, the issue of opening streams as a way of  
testing for existence.   I think the long term way forward is to look  
at taking the code in the direction of the new JSR 203 Son of IO API,  
and providing recommended subtypes of [Java]FileObject that provide  
some of the additional API we are missing.

-- Jon

On Jan 19, 2009, at 6:16 PM, Emil Siemes wrote:

> Hi Jon,
>
> I created two methods for JavacFiler which would do the necessary  
> checks and throw the missing exceptions.
> checkExistence needs to be called by getResource and  
> checkFileCreation by createResource.
> Unfortunately RegularFileObject is not accessible from the  
> com.sun.tools.javac.processing package that's why I thought of using  
> reflection.
> For FileObjects not extending RegularFileObject I thought of opening  
> the stream as test for existence. Is that too heavy weight? Shall I  
> better just completely ignore those cases? If you think that in  
> principle it is ok to open the stream as check I would surround the  
> openIn/OutputStream with a try/catch clause to make sure close gets  
> always called.
> For createResource the test actually already creates the file but I  
> think that should be ok because the only real test whether a file  
> could be created is to create it. An alternatice would be to delete  
> the file in the test after creating it which should be fine for any  
> not "write only once" filesystems.. What are your thoughts?
>
> Emil
>
>
> private void checkExistence(FileObject fo) throws IOException {
>         Class foclass= fo.getClass();
>         do {
>              
> if 
> (foclass 
> .getName().equals("com.sun.tools.java.file.RegularFileObject")) {
>                 if(!new File(fo.toUri()).exists()) {
>                     throw new FileNotFoundException("Resource does  
> not exists: "+fo.getName());
>                 }
>                 return;
>             }
>             foclass= foclass.getSuperclass();
>         }
>         while(foclass!= null);
>         InputStream in= fo.openInputStream();
>         in.close();
>     }
>
>     private void checkFileCreation(FileObject fo) throws IOException {
>         Class foclass= fo.getClass();
>         do {
>              
> if 
> (foclass 
> .getName().equals("com.sun.tools.java.file.RegularFileObject")) {
>                 File file= new File(fo.toUri());
>                 try {
>                     if(!file.createNewFile()) {
>                         OutputStream out= fo.openOutputStream();
>                         out.close();
>                     }
> InputStream in= fo.openInputStream();
>         in..close();
>     }
>
>     private void checkFileCreation(FileObject fo) throws IOException {
>         Class foclass= fo.getClass();
>         do {
>              
> if 
> (foclass 
> .getName().equals("com.sun.tools.java.file.RegularFileObject")) {
>                 File file= new File(fo.toUri());
>                 try {
>                     if(!file.createNewFile()) {
>                         OutputStream out= fo.openOutputStream();
>                         out.close();
>                     }
>                 }
>                 catch(SecurityException e) {
>                     throw new IOException("Not allowed to create  
> resource: "+fo.getName());
>                 }
>                 return;
>             }
>             foclass= foclass.getSuperclass();
>         }
>         while(foclass!= null);
>         OutputStream out= fo.openOutputStream();
>         out.close();
>     }
>
>
>
> Von: Emil Andreas Siemes <digitalemil at yahoo.de>
> An: Jonathan Gibbons <Jonathan.Gibbons at Sun.COM>; compiler-dev at openjdk.java.net
> Gesendet: Dienstag, den 6. Januar 2009, 18:35:04 Uhr
> Betreff: AW: AW: AW: 6502395: Is not a bug
>
> Hi Jon,
>
> regarding the bug as it is reported nothing changed:
> "When we are trying to open nonexistent resource we should expect  
> IOException thrown.
> However getting nonexistent resource doesn't cause to IOException.  
> Instead IllegalStateExceptionis thrown."
> This is because the bug report uses createResource().openReader()  
> and not
>  getResource().openReader() and throwing IllegalStateException is  
> expected in this case.
> Nevertheless there is an issue with the current implementations:
> JDK6u11:
> getResource(... "unexisting-resource" ...) doesn't throw any  
> exception. Ugly, spec is says IOException has to be thrown.
> getResource(... "unexisting-resource" ...).openReader() throws  
> UnsupportedOperationException. Ugly.
>
> OpenJDK7 (b18, b24, 41 & 42):
> getResource(... "unexisting-resource" ...) doesn't throw any  
> exception. Ugly, spec is says IOException has to be thrown.
> getResource(... "unexisting-resource" ...).openReader() throws  
> FileNotFoundException. Better.
>
> Let me investigate where we can insert a check for the existence of  
> the file to be opened. Then we can throw FileNotFound in  
> getResource()...
> Thanks
> Emil
>
>
>
>
>
>
> Von: Jonathan Gibbons <Jonathan.Gibbons at Sun.COM>
> An: Emil Siemes <digitalemil at yahoo.de>
> CC: compiler-dev at openjdk.java.net
> Gesendet: Dienstag, den 6. Januar 2009, 00:07:16 Uhr
> Betreff: Re: AW: AW: 6502395: Is not a bug
>
> Emil,
>
> The spec is what it is, and cannot easily be changed. And, being  
> pedantic, the spec does not require the file
> to be opened; it merely says that an exception must be thrown if the  
> file cannot be opened. The implementation
> may perform a number of checks to determine whether the file can be  
> opened in principle without actually
> opening it.
>
> What is your current disposition regarding this bug?  Are you now  
> saying the javac behavior and the test's
> behavior are now both correct?
>
> -- Jon
>
>
>
> Emil Siemes wrote:
>>
>> Seems I was a bit too fast. When I tried b18 (see last mail) the  
>> path to java was correct but I still used JDK6u11 javac.
>> After correcting the setup b18 also throws FileNotFoundException  
>> (which is the correct behavior). So the bug was fixed before b18.
>>
>> But the method which throws the exception in the following code
>> "FileObject fo = filer.getResource(location, "", "foo/" + location  
>> + ".unexisting");
>> Reader reader = fo.openReader(true);"
>> is openReader not getResource as the spec suggests:
>>
>> java.io.FileNotFoundException: foo/SOURCE_OUTPUT.unexisting (No  
>> such file or directory)
>>     at java.io.FileInputStream.open(Native Method)
>>     at java..io.FileInputStream.<init>(FileInputStream.java:137)
>>     at  
>> com 
>> .sun 
>> .tools 
>> .javac 
>> .file.RegularFileObject.openInputStream(RegularFileObject.java:68)
>>     at  
>> com 
>> .sun.tools.javac.file.BaseFileObject.openReader(BaseFileObject.java: 
>> 76)
>>
>>
>> getResource
>>
>> FileObject getResource(JavaFileManager.Location location,
>>                        CharSequence pkg,
>>                        CharSequence relativeName)
>>                        throws IOException
>> Returns an object for reading an existing resource. The locations  
>> CLASS_OUTPUT andSOURCE_OUTPUT must be supported.
>> Parameters:
>> location - location of the file
>> pkg - package relative to which the file should be searched, or the  
>> empty string if none
>> relativeName - final pathname components of the file
>> Returns:
>> an object to read the file
>> Throws:
>> FilerException - if the same pathname has already been opened for  
>> writing
>> IOException - if the file cannot be opened
>> I'm challenging the spec a bit. Why should getResource() open the  
>> file at all? I think the normal behavior is like in the bug report:
>> getResource and then try opening the resource and expecting an  
>> exception if it fails. And as we see this is how the implementation  
>> works: getResource() returns a FileObject but doesn't open it and  
>> doesn't test if the file could be openend.
>>
>> Any thoughts?
>>
>>
>>
>>
>>
>>
>>
>>
>> Von: Emil Siemes <digitalemil at yahoo.de>
>> An: Mark Wielaard <mark at klomp.org>
>> CC: compiler-dev at openjdk.java.net; Jonathan Gibbons <Jonathan.Gibbons at Sun.COM 
>> >
>> Gesendet: Dienstag, den 16. Dezember 2008, 14:01:24 Uhr
>> Betreff: AW: 6502395: Is not a bug
>>
>> Hi Mark,
>>
>> thanks for the links. I was able to test b18 and at least this  
>> build still throws UnsupportedOperationException.
>> I now wanted to follow-up the path but it seems that the  
>> fedoraproject has some database issues...
>> Will try again later. And yes a central repository with all old  
>> binary & source bundles would be helpful.
>>
>> Thanks
>>   Emil
>>
>> Von: Mark Wielaard <mark at klomp.org>
>> An: Dalibor Topic <Dalibor.Topic at Sun.COM>
>> CC: Jonathan Gibbons <Jonathan.Gibbons at Sun.COM>; compiler-dev at openjdk.java.net
>> Gesendet: Samstag, den 13. Dezember 2008, 21:52:15 Uhr
>> Betreff: Re: 6502395: Is not a bug
>>
>> On Sat, 2008-12-13 at 21:25 +0100, Dalibor Topic wrote:
>> > Martin Buchholz wrote:
>> > > On Fri, Dec 12, 2008 at 08:56, Jonathan Gibbons
>> > > <Jonathan.Gibbons at sun.com> wrote:
>> > >
>> > >> Like you, I could not find public builds for JDK7 builds  
>> earlier than b36. I
>> > >> am sorry (and somewhat surprised) that they are not available.
>> > >
>> > > I complained about this elsewhere.
>> > > Lack of hardware resources to hold the archives were cited.
>> > >
>> > > I'd like to see every build remain available for download for  
>> at least 3 years.
>> >
>> > Did I hear someone volunteering to build & maintain a mirror? ;)
>>
>> We do keep a mirror of the old GPL sources (which came from the svn
>> repository) in mercurial at http://icedtea.classpath.org/hg/openjdk  
>> if
>> anybody needs anything early (b13 till b23). Although the changes
>> between the bxx drops are somewhat big, you can do some simple
>> investigations against it through mercurial.
>>
>> Also various GNU/Linux distros still have old GPL binary icedtea/ 
>> openjdk
>> 1.7 packages (and source code of course) around (although most are
>> tracking jdk6 these days). Here are old builds of the 1.7.0 tree (b18
>> till b24) for Fedora 8/9 for example:
>> http://koji.fedoraproject.org/koji/packageinfo?packageID=4946
>>
>> Cheers,
>>
>> Mark
>>
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20090119/42ec5c1e/attachment.html 

From jonathan.gibbons at sun.com  Mon Jan 19 19:40:51 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Tue, 20 Jan 2009 03:40:51 +0000
Subject: hg: jdk7/tl/langtools: 6794959: add new switch -XDexpectKeys=key,
	key....
Message-ID: <20090120034055.CB0FDDBD6@hg.openjdk.java.net>

Changeset: d0b33fe8e710
Author:    jjg
Date:      2009-01-19 19:36 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d0b33fe8e710

6794959: add new switch -XDexpectKeys=key,key....
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/main/Main.java
! src/share/classes/com/sun/tools/javac/util/Log.java
+ test/tools/javac/T6794959.java



From maurizio.cimadamore at sun.com  Tue Jan 20 10:00:21 2009
From: maurizio.cimadamore at sun.com (maurizio.cimadamore at sun.com)
Date: Tue, 20 Jan 2009 18:00:21 +0000
Subject: hg: jdk7/tl/langtools: 2 new changesets
Message-ID: <20090120180024.C24F2DC49@hg.openjdk.java.net>

Changeset: 83c59a9d4b94
Author:    mcimadamore
Date:      2009-01-20 17:49 +0000
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/83c59a9d4b94

6795580: parser confused by square brackets in qualified generic cast
Summary: Parser rejects cast with qualified generic array types
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
+ test/tools/javac/cast/6795580/T6795580.java
+ test/tools/javac/cast/6795580/T6795580.out

Changeset: 1ca2dc8584e1
Author:    mcimadamore
Date:      2009-01-20 17:49 +0000
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/1ca2dc8584e1

6557199: Fails to reject bad override of generic method
Summary: Javac does not correctly implement JLS3 8.4.5
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
+ test/tools/javac/generics/rawOverride/6557199/T6557199.java
+ test/tools/javac/generics/rawOverride/6557199/T6557199.out



From jonathan.gibbons at sun.com  Tue Jan 20 15:20:09 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Tue, 20 Jan 2009 23:20:09 +0000
Subject: hg: jdk7/tl/langtools: 6794582: javadoc should read files using a
	FileManager
Message-ID: <20090120232010.E379CDC98@hg.openjdk.java.net>

Changeset: 1bf037016426
Author:    jjg
Date:      2009-01-20 15:17 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/1bf037016426

6794582: javadoc should read files using a FileManager
Reviewed-by: darcy, bpatel

! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourceToHTMLConverter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java
! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java
! src/share/classes/com/sun/tools/javadoc/DocEnv.java
! src/share/classes/com/sun/tools/javadoc/DocImpl.java
! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java
! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java
! src/share/classes/com/sun/tools/javadoc/JavadocClassReader.java
! src/share/classes/com/sun/tools/javadoc/JavadocTool.java
! src/share/classes/com/sun/tools/javadoc/PackageDocImpl.java
! src/share/classes/com/sun/tools/javadoc/RootDocImpl.java
! src/share/classes/com/sun/tools/javadoc/SourcePositionImpl.java



From mandy.chung at sun.com  Tue Jan 20 16:19:27 2009
From: mandy.chung at sun.com (mandy.chung at sun.com)
Date: Wed, 21 Jan 2009 00:19:27 +0000
Subject: hg: jdk7/tl/jdk: 3 new changesets
Message-ID: <20090121002002.59213DCB1@hg.openjdk.java.net>

Changeset: 1f751a9f7052
Author:    mchung
Date:      2009-01-20 13:02 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1f751a9f7052

6793429: Use compiled properties instead of plain properties for resource file
Summary: Rename the variables in Resources.gmk to make compiled properties more explicit
Reviewed-by: naoto, yhuang

! make/com/sun/org/apache/xml/Makefile
! make/com/sun/rowset/Makefile
! make/common/internal/Resources.gmk
! make/sun/launcher/Makefile
! make/sun/rmi/oldtools/Makefile
! make/sun/rmi/registry/Makefile
! make/sun/rmi/rmic/Makefile
! make/sun/rmi/rmid/Makefile
! make/sun/serialver/Makefile

Changeset: 42f8dea1b865
Author:    mchung
Date:      2009-01-20 13:04 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/42f8dea1b865

6769976: (fc) FileChannelImpl.isAMappedBufferField not used
Summary: Remove the FileChannelImpl.isAMappedBufferField field
Reviewed-by: alanb

! src/share/classes/sun/nio/ch/FileChannelImpl.java

Changeset: 7fa0a7a3c080
Author:    mchung
Date:      2009-01-20 16:16 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7fa0a7a3c080

Merge




From jonathan.gibbons at sun.com  Tue Jan 20 18:25:36 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Wed, 21 Jan 2009 02:25:36 +0000
Subject: hg: jdk7/tl/langtools: 6795903: fix latent build warnings in
	langtools repository
Message-ID: <20090121022537.E20D5DCC5@hg.openjdk.java.net>

Changeset: b4b1f7732289
Author:    jjg
Date:      2009-01-20 18:23 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/b4b1f7732289

6795903: fix latent build warnings in langtools repository
Reviewed-by: darcy

! make/build.properties
! src/share/classes/com/sun/tools/apt/comp/AnnotationProcessingError.java
! src/share/classes/com/sun/tools/apt/comp/Apt.java
! src/share/classes/com/sun/tools/apt/comp/UsageMessageNeededException.java
! src/share/classes/com/sun/tools/apt/main/JavaCompiler.java
! src/share/classes/com/sun/tools/apt/mirror/apt/RoundCompleteEventImpl.java
! src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationProxyMaker.java
! src/share/classes/com/sun/tools/apt/mirror/type/TypeVariableImpl.java
! src/share/classes/com/sun/tools/classfile/Annotation.java
! src/share/classes/com/sun/tools/classfile/AttributeException.java
! src/share/classes/com/sun/tools/classfile/Code_attribute.java
! src/share/classes/com/sun/tools/classfile/ConstantPool.java
! src/share/classes/com/sun/tools/classfile/ConstantPoolException.java
! src/share/classes/com/sun/tools/classfile/Descriptor.java
! src/share/classes/com/sun/tools/classfile/DescriptorException.java
! src/share/classes/com/sun/tools/classfile/StackMapTable_attribute.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocletAbortException.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java
! src/share/classes/com/sun/tools/javadoc/Comment.java
! src/share/classes/com/sun/tools/javadoc/Messager.java
! src/share/classes/com/sun/tools/javadoc/TypeMaker.java
! src/share/classes/com/sun/tools/javah/Gen.java
! src/share/classes/com/sun/tools/javap/InternalError.java
! src/share/classes/sun/tools/javap/JavapPrinter.java



From John.Rose at Sun.COM  Tue Jan 20 23:20:47 2009
From: John.Rose at Sun.COM (John Rose)
Date: Tue, 20 Jan 2009 23:20:47 -0800
Subject: langtools and NetBeans
In-Reply-To: <49430278.80806@sun.com>
References: <49430278.80806@sun.com>
Message-ID: <64D00D9D-ADC1-4827-9EB3-F02CBF5EDF7F@sun.com>

On Dec 12, 2008, at 4:31 PM, Jonathan Gibbons wrote:

> The patch is a preview, to give folk who use NetBeans for langtools  
> a chance
> to give feedback, before we push this to the main repository,  
> perhaps sometime
> early in January.  Comment and feedback welcome.

I like this patch, since I use NetBeans with increasing frequency and  
enthusiasm.  But I use 6.5, so the old langtools sub-projects do not  
work for me.  With your patch, I can get work done now.

I like it so well I have put it into the mlvm/langtools patch  
repository, with instructions on how to work with javac in NetBeans:
   http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/6de49f01c9f0

I hope something like this gets into the real langtools repo., so I  
can remove the patch from mlvm.

Configuring my environment to use it was non-trivial: lots of moving  
parts.  I recorded my experiences starting at about line 70 of this  
file:
   http://hg.openjdk.java.net/mlvm/mlvm/langtools/file/tip/meth.txt

Thanks!

-- John


From Jonathan.Gibbons at Sun.COM  Wed Jan 21 07:26:39 2009
From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons)
Date: Wed, 21 Jan 2009 07:26:39 -0800
Subject: langtools and NetBeans
In-Reply-To: <64D00D9D-ADC1-4827-9EB3-F02CBF5EDF7F@sun.com>
References: <49430278.80806@sun.com>
	<64D00D9D-ADC1-4827-9EB3-F02CBF5EDF7F@sun.com>
Message-ID: <F4CF1F14-C80C-4A90-9C93-9211D4ECE497@Sun.COM>

Funny you should mention this;  I'm just waiting for a review and will  
put
the change back soon.  Thanks for the feedback.

-- Jon

On Jan 20, 2009, at 11:20 PM, John Rose wrote:

> On Dec 12, 2008, at 4:31 PM, Jonathan Gibbons wrote:
>
>> The patch is a preview, to give folk who use NetBeans for langtools  
>> a chance
>> to give feedback, before we push this to the main repository,  
>> perhaps sometime
>> early in January.  Comment and feedback welcome.
>
> I like this patch, since I use NetBeans with increasing frequency  
> and enthusiasm.  But I use 6.5, so the old langtools sub-projects do  
> not work for me.  With your patch, I can get work done now.
>
> I like it so well I have put it into the mlvm/langtools patch  
> repository, with instructions on how to work with javac in NetBeans:
>  http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/6de49f01c9f0
>
> I hope something like this gets into the real langtools repo., so I  
> can remove the patch from mlvm.
>
> Configuring my environment to use it was non-trivial: lots of moving  
> parts.  I recorded my experiences starting at about line 70 of this  
> file:
>  http://hg.openjdk.java.net/mlvm/mlvm/langtools/file/tip/meth.txt
>
> Thanks!
>
> -- John



From jonathan.gibbons at sun.com  Wed Jan 21 08:24:45 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Wed, 21 Jan 2009 16:24:45 +0000
Subject: hg: jdk7/tl/langtools: 6795030: Files in langtools build can be
	compiled ignoring java.home settings
Message-ID: <20090121162446.EC2FBDCD8@hg.openjdk.java.net>

Changeset: d486ac6389d7
Author:    jjg
Date:      2009-01-21 08:21 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d486ac6389d7

6795030: Files in langtools build can be compiled ignoring java.home settings
Reviewed-by: mcimadamore

! make/build.xml



From John.Rose at Sun.COM  Wed Jan 21 10:52:19 2009
From: John.Rose at Sun.COM (John Rose)
Date: Wed, 21 Jan 2009 10:52:19 -0800
Subject: NetBeans support for proposed small language extensions
Message-ID: <5E93D53B-5167-43E5-85F7-101980CD0236@sun.com>

The mlvm/langtools patch repository has support for some small Java  
extensions, which I am in the process of proposing to the Java  
language people.

I have wired the updated javac into the ant scripts that NetBeans  
uses, and can build invokedynamic call sites directly from Java code  
in the NetBeans editor.  This will be a preferred way to create call  
sites for metaobject protocol infrastructure and any parts of dynamic  
language runtimes written in Java.  (Dynamic languages will probably  
not compile via Java, but use ASM to generate invokedynamic calls  
directly.)  You'll see the tweaks for that on my next hotspot push.

Meanwhile, NetBeans still (very reasonably) reports the extensions as  
syntax or type errors.  I just filed a NetBeans RFE to get this  
fixed.  Now all we need is a NetBeans expert!  (Are *you* that  
expert? :-)

http://www.netbeans.org/issues/show_bug.cgi?id=157264

Best wishes,
-- John


From digitalemil at yahoo.de  Wed Jan 21 18:22:38 2009
From: digitalemil at yahoo.de (Emil Siemes)
Date: Thu, 22 Jan 2009 02:22:38 +0000 (GMT)
Subject: [Patch] 6502392 Invalid relative names for Filer.createResource
Message-ID: <475926.9706.qm@web23005.mail.ird.yahoo.com>

So, finally.
'if(' replaced with 'if (' and other cosmetic changes included.
( 'if (' how ugly looks this? ;-)


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20090122/8a275cc0/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JavacFileManager.diff
Type: application/octet-stream
Size: 2690 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20090122/8a275cc0/JavacFileManager.diff 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TestFor6502395.java
Type: application/octet-stream
Size: 3526 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20090122/8a275cc0/TestFor6502395.java 

From digitalemil at yahoo.de  Wed Jan 21 18:26:11 2009
From: digitalemil at yahoo.de (Emil Siemes)
Date: Thu, 22 Jan 2009 02:26:11 +0000 (GMT)
Subject: Correction [Patch] 6502392 Invalid relative names for
	Filer.createResource
References: <475926.9706.qm@web23005.mail.ird.yahoo.com>
Message-ID: <336630.11346.qm@web23005.mail.ird.yahoo.com>

Sorry wrong test attached. Find the correct one here same diff also attached.




________________________________
Von: Emil Siemes <digitalemil at yahoo.de>
An: compiler-dev at openjdk.java.net
Gesendet: Donnerstag, den 22. Januar 2009, 03:22:38 Uhr
Betreff: [Patch] 6502392 Invalid relative names for Filer.createResource


So, finally.
'if(' replaced with 'if (' and other cosmetic changes included.
( 'if (' how ugly looks this? ;-)


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20090122/1b360bbc/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TestFor6502392.java
Type: application/octet-stream
Size: 1892 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20090122/1b360bbc/TestFor6502392.java 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JavacFileManager.diff
Type: application/octet-stream
Size: 2690 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20090122/1b360bbc/JavacFileManager.diff 

From digitalemil at yahoo.de  Wed Jan 21 18:31:47 2009
From: digitalemil at yahoo.de (Emil Siemes)
Date: Thu, 22 Jan 2009 02:31:47 +0000 (GMT)
Subject: [Patch] 6502395 Filer.getResource doesn't throw IOException when
	getting nonexistent file
Message-ID: <677985.16636.qm@web23008.mail.ird.yahoo.com>

removed opening streams as test. RegularFileObject made public. Reflection removed, using 'instanceof' now.


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20090122/06513494/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RegularFileObject.diff
Type: application/octet-stream
Size: 451 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20090122/06513494/RegularFileObject.diff 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JavacFiler.diff
Type: application/octet-stream
Size: 2327 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20090122/06513494/JavacFiler.diff 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TestFor6502395.java
Type: application/octet-stream
Size: 3526 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20090122/06513494/TestFor6502395.java 

From jonathan.gibbons at sun.com  Thu Jan 22 15:48:22 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Thu, 22 Jan 2009 23:48:22 +0000
Subject: hg: jdk7/tl/langtools: 6796965: dev-time wrapper script for javac
	broken
Message-ID: <20090122234824.2F7F4DE54@hg.openjdk.java.net>

Changeset: e6dafbf35355
Author:    jjg
Date:      2009-01-22 15:45 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/e6dafbf35355

6796965: dev-time wrapper script for javac broken
Reviewed-by: ksrini

! make/build.xml



From xueming.shen at sun.com  Thu Jan 22 20:46:35 2009
From: xueming.shen at sun.com (xueming.shen at sun.com)
Date: Fri, 23 Jan 2009 04:46:35 +0000
Subject: hg: jdk7/tl/jdk: 6476425: (fmt)java.util.Formatter.print() throws
	IllegalArgumentException on large BigDecima
Message-ID: <20090123044647.9C0DEDED5@hg.openjdk.java.net>

Changeset: 63f8707112be
Author:    sherman
Date:      2009-01-22 20:29 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/63f8707112be

6476425: (fmt)java.util.Formatter.print() throws IllegalArgumentException on large BigDecima
Summary: Correct the wrong calculation of "precision" in certain circumstances.
Reviewed-by: darcy, alanb

! src/share/classes/java/util/Formatter.java
! test/java/util/Formatter/Basic-X.java
! test/java/util/Formatter/Basic.java
! test/java/util/Formatter/BasicBigDecimal.java
! test/java/util/Formatter/BasicBigInteger.java
! test/java/util/Formatter/BasicBoolean.java
! test/java/util/Formatter/BasicBooleanObject.java
! test/java/util/Formatter/BasicByte.java
! test/java/util/Formatter/BasicByteObject.java
! test/java/util/Formatter/BasicChar.java
! test/java/util/Formatter/BasicCharObject.java
! test/java/util/Formatter/BasicDateTime.java
! test/java/util/Formatter/BasicDouble.java
! test/java/util/Formatter/BasicDoubleObject.java
! test/java/util/Formatter/BasicFloat.java
! test/java/util/Formatter/BasicFloatObject.java
! test/java/util/Formatter/BasicInt.java
! test/java/util/Formatter/BasicIntObject.java
! test/java/util/Formatter/BasicLong.java
! test/java/util/Formatter/BasicLongObject.java
! test/java/util/Formatter/BasicShort.java
! test/java/util/Formatter/BasicShortObject.java
! test/java/util/Formatter/genBasic.sh



From joe.darcy at sun.com  Fri Jan 23 10:44:15 2009
From: joe.darcy at sun.com (joe.darcy at sun.com)
Date: Fri, 23 Jan 2009 18:44:15 +0000
Subject: hg: jdk7/tl/jdk: 6604864: Double.valueOf(String) does not specify
	behaviour for overflow and underflow
Message-ID: <20090123184427.3B322E005@hg.openjdk.java.net>

Changeset: cb641d17bbb3
Author:    darcy
Date:      2009-01-23 10:37 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cb641d17bbb3

6604864: Double.valueOf(String) does not specify behaviour for overflow and underflow
Reviewed-by: emcmanus

! src/share/classes/java/lang/Double.java
! src/share/classes/java/lang/Float.java



From jonathan.gibbons at sun.com  Fri Jan 23 11:25:42 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Fri, 23 Jan 2009 19:25:42 +0000
Subject: hg: jdk7/tl/langtools: 6795365: NetBeans projects in langtools
	repository are not NB6.5-friendly
Message-ID: <20090123192544.3BCE2E00A@hg.openjdk.java.net>

Changeset: e3930187199c
Author:    jjg
Date:      2009-01-23 11:23 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/e3930187199c

6795365: NetBeans projects in langtools repository are not NB6.5-friendly
Reviewed-by: mcimadamore

! make/README
! make/build.xml
! make/netbeans/README
- make/netbeans/apt/README
- make/netbeans/apt/build.xml
- make/netbeans/apt/nbproject/project.xml
- make/netbeans/common/shared.xml
- make/netbeans/common/standard-context-menu-items-no-javadoc.ent
- make/netbeans/common/standard-context-menu-items.ent
- make/netbeans/common/standard-ide-actions-no-javadoc.ent
- make/netbeans/common/standard-ide-actions.ent
- make/netbeans/compiler/README
- make/netbeans/compiler/build.xml
- make/netbeans/compiler/nbproject/project.xml
- make/netbeans/doclets/README
- make/netbeans/doclets/build.xml
- make/netbeans/doclets/nbproject/project.xml
- make/netbeans/javadoc/README
- make/netbeans/javadoc/build.xml
- make/netbeans/javadoc/nbproject/project.xml
- make/netbeans/javah/README
- make/netbeans/javah/build.xml
- make/netbeans/javah/nbproject/project.xml
- make/netbeans/javap/README
- make/netbeans/javap/build.xml
- make/netbeans/javap/nbproject/project.xml
+ make/netbeans/langtools/build.xml
+ make/netbeans/langtools/nbproject/project.xml
+ make/netbeans/langtools/nbproject/standard-context-menu-items.ent
+ make/netbeans/langtools/nbproject/standard-ide-actions.ent
+ make/tools/SelectTool/SelectToolTask.java



From tim.bell at sun.com  Sat Jan 24 15:18:51 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Sat, 24 Jan 2009 23:18:51 +0000
Subject: hg: jdk7/tl/langtools: 6797463: 6557199 breaks the jax-ws workspace
Message-ID: <20090124231853.5D997E085@hg.openjdk.java.net>

Changeset: 3b2c55b7bd01
Author:    tbell
Date:      2009-01-24 11:07 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/3b2c55b7bd01

6797463: 6557199 breaks the jax-ws workspace
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Check.java



From tim.bell at sun.com  Sun Jan 25 16:36:16 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Mon, 26 Jan 2009 00:36:16 +0000
Subject: hg: jdk7/tl: 2 new changesets
Message-ID: <20090126003616.51F4AE11C@hg.openjdk.java.net>

Changeset: a395e3aac474
Author:    xdono
Date:      2009-01-15 11:46 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/a395e3aac474

Added tag jdk7-b43 for changeset 848e684279d2

! .hgtags

Changeset: 99846f001ca2
Author:    xdono
Date:      2009-01-22 14:41 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/99846f001ca2

Added tag jdk7-b44 for changeset a395e3aac474

! .hgtags



From tim.bell at sun.com  Sun Jan 25 16:38:32 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Mon, 26 Jan 2009 00:38:32 +0000
Subject: hg: jdk7/tl/corba: 2 new changesets
Message-ID: <20090126003833.F33C1E121@hg.openjdk.java.net>

Changeset: 9803dac72540
Author:    xdono
Date:      2009-01-15 11:46 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/9803dac72540

Added tag jdk7-b43 for changeset 9cd740d48a48

! .hgtags

Changeset: 68814aa5b44b
Author:    xdono
Date:      2009-01-22 14:41 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/68814aa5b44b

Added tag jdk7-b44 for changeset 9803dac72540

! .hgtags



From tim.bell at sun.com  Sun Jan 25 16:42:05 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Mon, 26 Jan 2009 00:42:05 +0000
Subject: hg: jdk7/tl/hotspot: 2 new changesets
Message-ID: <20090126004209.0EFE4E126@hg.openjdk.java.net>

Changeset: 809e899c638b
Author:    xdono
Date:      2009-01-15 11:46 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/809e899c638b

Added tag jdk7-b43 for changeset fc6a5ae3fef5

! .hgtags

Changeset: 945bf7540697
Author:    xdono
Date:      2009-01-22 14:42 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/945bf7540697

Added tag jdk7-b44 for changeset 809e899c638b

! .hgtags



From tim.bell at sun.com  Sun Jan 25 16:47:04 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Mon, 26 Jan 2009 00:47:04 +0000
Subject: hg: jdk7/tl/jaxp: 2 new changesets
Message-ID: <20090126004707.4A5A8E12B@hg.openjdk.java.net>

Changeset: b203df0741af
Author:    xdono
Date:      2009-01-15 11:46 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/b203df0741af

Added tag jdk7-b43 for changeset 96fe28d4a913

! .hgtags

Changeset: 0f113667880d
Author:    xdono
Date:      2009-01-22 14:42 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/0f113667880d

Added tag jdk7-b44 for changeset b203df0741af

! .hgtags



From tim.bell at sun.com  Sun Jan 25 16:49:23 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Mon, 26 Jan 2009 00:49:23 +0000
Subject: hg: jdk7/tl/jaxws: 2 new changesets
Message-ID: <20090126004926.36796E130@hg.openjdk.java.net>

Changeset: 344485a03674
Author:    xdono
Date:      2009-01-15 11:46 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/344485a03674

Added tag jdk7-b43 for changeset 1ad2f51564db

! .hgtags

Changeset: dea7753d7139
Author:    xdono
Date:      2009-01-22 14:42 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/dea7753d7139

Added tag jdk7-b44 for changeset 344485a03674

! .hgtags



From tim.bell at sun.com  Sun Jan 25 16:52:13 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Mon, 26 Jan 2009 00:52:13 +0000
Subject: hg: jdk7/tl/jdk: 6 new changesets
Message-ID: <20090126005322.18B76E135@hg.openjdk.java.net>

Changeset: 8dcc06d43798
Author:    xdono
Date:      2009-01-15 11:46 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8dcc06d43798

Added tag jdk7-b43 for changeset 50c67678b0d1

! .hgtags

Changeset: 4dab1a24dca2
Author:    tbell
Date:      2009-01-16 10:37 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4dab1a24dca2

Merge


Changeset: 6dce6ac0929e
Author:    tbell
Date:      2009-01-14 21:35 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6dce6ac0929e

6754862: jdk/src/windows/bin/java_md.c: hardcoded reference to msvcr71.dll
6779412: VS2008 errors compiling jdk sources
Summary: Update Makefiles to tolerate newer Visual Studio releases and runtimes.
Reviewed-by: ohair

! make/com/sun/java/pack/Makefile
! make/common/Defs-windows.gmk
! make/common/Library.gmk
! make/common/Program.gmk
! make/common/shared/Compiler-msvc.gmk
! make/common/shared/Defs-windows.gmk
! make/common/shared/Sanity-Settings.gmk
! make/common/shared/Sanity.gmk
! make/java/main/java/Makefile
! make/java/main/javaw/Makefile
! make/java/redist/Makefile
! src/share/bin/main.c
! src/windows/bin/java_md.c

Changeset: d8eb2738db6b
Author:    xdono
Date:      2009-01-20 09:42 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d8eb2738db6b

Merge

- src/share/classes/sun/nio/cs/IBM437.java
- src/share/classes/sun/nio/cs/IBM737.java
- src/share/classes/sun/nio/cs/IBM775.java
- src/share/classes/sun/nio/cs/IBM850.java
- src/share/classes/sun/nio/cs/IBM852.java
- src/share/classes/sun/nio/cs/IBM855.java
- src/share/classes/sun/nio/cs/IBM857.java
- src/share/classes/sun/nio/cs/IBM858.java
- src/share/classes/sun/nio/cs/IBM862.java
- src/share/classes/sun/nio/cs/IBM866.java
- src/share/classes/sun/nio/cs/IBM874.java
- src/share/classes/sun/nio/cs/ISO_8859_13.java
- src/share/classes/sun/nio/cs/ISO_8859_15.java
- src/share/classes/sun/nio/cs/ISO_8859_2.java
- src/share/classes/sun/nio/cs/ISO_8859_4.java
- src/share/classes/sun/nio/cs/ISO_8859_5.java
- src/share/classes/sun/nio/cs/ISO_8859_7.java
- src/share/classes/sun/nio/cs/ISO_8859_9.java
- src/share/classes/sun/nio/cs/KOI8_R.java
- src/share/classes/sun/nio/cs/KOI8_U.java
- src/share/classes/sun/nio/cs/MS1250.java
- src/share/classes/sun/nio/cs/MS1251.java
- src/share/classes/sun/nio/cs/MS1252.java
- src/share/classes/sun/nio/cs/MS1253.java
- src/share/classes/sun/nio/cs/MS1254.java
- src/share/classes/sun/nio/cs/MS1257.java
- src/share/classes/sun/nio/cs/ext/IBM037.java
- src/share/classes/sun/nio/cs/ext/IBM1006.java
- src/share/classes/sun/nio/cs/ext/IBM1025.java
- src/share/classes/sun/nio/cs/ext/IBM1026.java
- src/share/classes/sun/nio/cs/ext/IBM1046.java
- src/share/classes/sun/nio/cs/ext/IBM1047.java
- src/share/classes/sun/nio/cs/ext/IBM1097.java
- src/share/classes/sun/nio/cs/ext/IBM1098.java
- src/share/classes/sun/nio/cs/ext/IBM1112.java
- src/share/classes/sun/nio/cs/ext/IBM1122.java
- src/share/classes/sun/nio/cs/ext/IBM1123.java
- src/share/classes/sun/nio/cs/ext/IBM1124.java
- src/share/classes/sun/nio/cs/ext/IBM1140.java
- src/share/classes/sun/nio/cs/ext/IBM1141.java
- src/share/classes/sun/nio/cs/ext/IBM1142.java
- src/share/classes/sun/nio/cs/ext/IBM1143.java
- src/share/classes/sun/nio/cs/ext/IBM1144.java
- src/share/classes/sun/nio/cs/ext/IBM1145.java
- src/share/classes/sun/nio/cs/ext/IBM1146.java
- src/share/classes/sun/nio/cs/ext/IBM1147.java
- src/share/classes/sun/nio/cs/ext/IBM1148.java
- src/share/classes/sun/nio/cs/ext/IBM1149.java
- src/share/classes/sun/nio/cs/ext/IBM273.java
- src/share/classes/sun/nio/cs/ext/IBM277.java
- src/share/classes/sun/nio/cs/ext/IBM278.java
- src/share/classes/sun/nio/cs/ext/IBM280.java
- src/share/classes/sun/nio/cs/ext/IBM284.java
- src/share/classes/sun/nio/cs/ext/IBM285.java
- src/share/classes/sun/nio/cs/ext/IBM297.java
- src/share/classes/sun/nio/cs/ext/IBM420.java
- src/share/classes/sun/nio/cs/ext/IBM424.java
- src/share/classes/sun/nio/cs/ext/IBM500.java
- src/share/classes/sun/nio/cs/ext/IBM838.java
- src/share/classes/sun/nio/cs/ext/IBM856.java
- src/share/classes/sun/nio/cs/ext/IBM860.java
- src/share/classes/sun/nio/cs/ext/IBM861.java
- src/share/classes/sun/nio/cs/ext/IBM863.java
- src/share/classes/sun/nio/cs/ext/IBM864.java
- src/share/classes/sun/nio/cs/ext/IBM865.java
- src/share/classes/sun/nio/cs/ext/IBM868.java
- src/share/classes/sun/nio/cs/ext/IBM869.java
- src/share/classes/sun/nio/cs/ext/IBM870.java
- src/share/classes/sun/nio/cs/ext/IBM871.java
- src/share/classes/sun/nio/cs/ext/IBM875.java
- src/share/classes/sun/nio/cs/ext/IBM918.java
- src/share/classes/sun/nio/cs/ext/IBM921.java
- src/share/classes/sun/nio/cs/ext/IBM922.java
- src/share/classes/sun/nio/cs/ext/ISO_8859_11.java
- src/share/classes/sun/nio/cs/ext/ISO_8859_3.java
- src/share/classes/sun/nio/cs/ext/ISO_8859_6.java
- src/share/classes/sun/nio/cs/ext/ISO_8859_8.java
- src/share/classes/sun/nio/cs/ext/MS1255.java
- src/share/classes/sun/nio/cs/ext/MS1256.java
- src/share/classes/sun/nio/cs/ext/MS1258.java
- src/share/classes/sun/nio/cs/ext/MS874.java
- src/share/classes/sun/nio/cs/ext/MacArabic.java
- src/share/classes/sun/nio/cs/ext/MacCentralEurope.java
- src/share/classes/sun/nio/cs/ext/MacCroatian.java
- src/share/classes/sun/nio/cs/ext/MacCyrillic.java
- src/share/classes/sun/nio/cs/ext/MacDingbat.java
- src/share/classes/sun/nio/cs/ext/MacGreek.java
- src/share/classes/sun/nio/cs/ext/MacHebrew.java
- src/share/classes/sun/nio/cs/ext/MacIceland.java
- src/share/classes/sun/nio/cs/ext/MacRoman.java
- src/share/classes/sun/nio/cs/ext/MacRomania.java
- src/share/classes/sun/nio/cs/ext/MacSymbol.java
- src/share/classes/sun/nio/cs/ext/MacThai.java
- src/share/classes/sun/nio/cs/ext/MacTurkish.java
- src/share/classes/sun/nio/cs/ext/MacUkraine.java
- src/share/classes/sun/nio/cs/ext/TIS_620.java

Changeset: 527b426497a2
Author:    xdono
Date:      2009-01-22 14:42 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/527b426497a2

Added tag jdk7-b44 for changeset d8eb2738db6b

! .hgtags

Changeset: 175b6adf65b3
Author:    tbell
Date:      2009-01-24 16:35 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/175b6adf65b3

Merge




From tim.bell at sun.com  Sun Jan 25 16:59:01 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Mon, 26 Jan 2009 00:59:01 +0000
Subject: hg: jdk7/tl/langtools: 4 new changesets
Message-ID: <20090126005907.BE732E13A@hg.openjdk.java.net>

Changeset: 05b47447cbcf
Author:    xdono
Date:      2009-01-15 11:46 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/05b47447cbcf

Added tag jdk7-b43 for changeset e2f8f6daee9d

! .hgtags

Changeset: 28f0b10d6c1a
Author:    tbell
Date:      2009-01-16 10:38 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/28f0b10d6c1a

Merge


Changeset: 30db5e0aaf83
Author:    xdono
Date:      2009-01-22 14:42 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/30db5e0aaf83

Added tag jdk7-b44 for changeset 28f0b10d6c1a

! .hgtags

Changeset: 40fd14d94c3c
Author:    tbell
Date:      2009-01-24 16:35 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/40fd14d94c3c

Merge

- make/netbeans/apt/README
- make/netbeans/apt/build.xml
- make/netbeans/apt/nbproject/project.xml
- make/netbeans/common/shared.xml
- make/netbeans/common/standard-context-menu-items-no-javadoc.ent
- make/netbeans/common/standard-context-menu-items.ent
- make/netbeans/common/standard-ide-actions-no-javadoc.ent
- make/netbeans/common/standard-ide-actions.ent
- make/netbeans/compiler/README
- make/netbeans/compiler/build.xml
- make/netbeans/compiler/nbproject/project.xml
- make/netbeans/doclets/README
- make/netbeans/doclets/build.xml
- make/netbeans/doclets/nbproject/project.xml
- make/netbeans/javadoc/README
- make/netbeans/javadoc/build.xml
- make/netbeans/javadoc/nbproject/project.xml
- make/netbeans/javah/README
- make/netbeans/javah/build.xml
- make/netbeans/javah/nbproject/project.xml
- make/netbeans/javap/README
- make/netbeans/javap/build.xml
- make/netbeans/javap/nbproject/project.xml



From tim.bell at sun.com  Mon Jan 26 16:39:34 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Tue, 27 Jan 2009 00:39:34 +0000
Subject: hg: jdk7/tl/langtools: 6797871: Fix for 6797463 did not remove the
	jtreg tests, and it should have
Message-ID: <20090127003938.50DC1E1EC@hg.openjdk.java.net>

Changeset: 0f922ff6968f
Author:    tbell
Date:      2009-01-26 15:14 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/0f922ff6968f

6797871: Fix for 6797463 did not remove the jtreg tests, and it should have
Reviewed-by: jjg

- test/tools/javac/generics/rawOverride/6557199/T6557199.java
- test/tools/javac/generics/rawOverride/6557199/T6557199.out



From joe.darcy at sun.com  Mon Jan 26 19:52:20 2009
From: joe.darcy at sun.com (joe.darcy at sun.com)
Date: Tue, 27 Jan 2009 03:52:20 +0000
Subject: hg: jdk7/tl/jdk: 6601457: Move wrapper class tests from closed to
	open; ...
Message-ID: <20090127035248.4AA83E1F3@hg.openjdk.java.net>

Changeset: f3ad2ee4600b
Author:    darcy
Date:      2009-01-26 19:49 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f3ad2ee4600b

6601457: Move wrapper class tests from closed to open
6601458: Move java.math tests from closed to open
6740185: Move java/lang/annotations tests to open
6759433: Move Math and StrictMath regression tests from closed to open
Summary: Move some more regression tests to the open
Reviewed-by: jjg

+ test/java/lang/Boolean/Factory.java
+ test/java/lang/Boolean/GetBoolean.java
+ test/java/lang/Boolean/MakeBooleanComparable.java
+ test/java/lang/Boolean/ParseBoolean.java
+ test/java/lang/Byte/Decode.java
+ test/java/lang/Double/BitwiseConversion.java
+ test/java/lang/Double/Constants.java
+ test/java/lang/Double/Extrema.java
+ test/java/lang/Double/NaNInfinityParsing.java
+ test/java/lang/Double/ParseDouble.java
+ test/java/lang/Double/ParseHexFloatingPoint.java
+ test/java/lang/Double/ToHexString.java
+ test/java/lang/Float/BitwiseConversion.java
+ test/java/lang/Float/Constants.java
+ test/java/lang/Float/Extrema.java
+ test/java/lang/Float/NaNInfinityParsing.java
+ test/java/lang/Float/ParseFloat.java
+ test/java/lang/Integer/BitTwiddle.java
+ test/java/lang/Integer/Decode.java
+ test/java/lang/Integer/GetInteger.java
+ test/java/lang/Integer/ParsingTest.java
+ test/java/lang/Long/BitTwiddle.java
+ test/java/lang/Long/Decode.java
+ test/java/lang/Long/GetLong.java
+ test/java/lang/Long/ParsingTest.java
+ test/java/lang/Math/AbsPositiveZero.java
+ test/java/lang/Math/Atan2Tests.java
+ test/java/lang/Math/CubeRootTests.java
+ test/java/lang/Math/Expm1Tests.java
+ test/java/lang/Math/HyperbolicTests.java
+ test/java/lang/Math/HypotTests.java
+ test/java/lang/Math/IeeeRecommendedTests.java
+ test/java/lang/Math/Log10Tests.java
+ test/java/lang/Math/Log1pTests.java
+ test/java/lang/Math/MinMax.java
+ test/java/lang/Math/PowTests.java
+ test/java/lang/Math/Rint.java
+ test/java/lang/Math/TanTests.java
+ test/java/lang/Math/Tests.java
+ test/java/lang/Short/ByteSwap.java
+ test/java/lang/Short/Decode.java
+ test/java/lang/StrictMath/CubeRootTests.java
+ test/java/lang/StrictMath/Expm1Tests.java
+ test/java/lang/StrictMath/HyperbolicTests.java
+ test/java/lang/StrictMath/HypotTests.java
+ test/java/lang/StrictMath/Log10Tests.java
+ test/java/lang/StrictMath/Log1pTests.java
+ test/java/lang/StrictMath/Tests.java
+ test/java/lang/ToString.java
+ test/java/lang/annotation/AnnotationTypeMismatchException/FoundType.java
+ test/java/lang/annotation/Missing/A.java
+ test/java/lang/annotation/Missing/B.java
+ test/java/lang/annotation/Missing/C.java
+ test/java/lang/annotation/Missing/D.java
+ test/java/lang/annotation/Missing/Marker.java
+ test/java/lang/annotation/Missing/Missing.java
+ test/java/lang/annotation/Missing/MissingTest.java
+ test/java/lang/annotation/Missing/MissingWrapper.java
+ test/java/lang/annotation/PackageMain.java
+ test/java/lang/annotation/RecursiveAnnotation.java
+ test/java/lang/annotation/UnitTest.java
+ test/java/lang/annotation/loaderLeak/A.java
+ test/java/lang/annotation/loaderLeak/B.java
+ test/java/lang/annotation/loaderLeak/C.java
+ test/java/lang/annotation/loaderLeak/LoaderLeak.sh
+ test/java/lang/annotation/loaderLeak/Main.java
+ test/java/lang/annotation/package-info.java
+ test/java/math/BigDecimal/AddTests.java
+ test/java/math/BigDecimal/CompareToTests.java
+ test/java/math/BigDecimal/Constructor.java
+ test/java/math/BigDecimal/DivideTests.java
+ test/java/math/BigDecimal/FloatDoubleValueTests.java
+ test/java/math/BigDecimal/IntegralDivisionTests.java
+ test/java/math/BigDecimal/NegateTests.java
+ test/java/math/BigDecimal/PowTests.java
+ test/java/math/BigDecimal/RoundingTests.java
+ test/java/math/BigDecimal/ScaleByPowerOfTenTests.java
+ test/java/math/BigDecimal/SerializationTests.java
+ test/java/math/BigDecimal/StringConstructor.java
+ test/java/math/BigDecimal/StrippingZerosTest.java
+ test/java/math/BigDecimal/ToPlainStringTests.java
+ test/java/math/BigDecimal/ZeroScalingTests.java
+ test/java/math/BigInteger/BigIntegerTest.java
+ test/java/math/BigInteger/ModPow.java
+ test/java/math/BigInteger/ModPow65537.java
+ test/java/math/BigInteger/ModPowPowersof2.java
+ test/java/math/BigInteger/OperatorNpeTests.java
+ test/java/math/BigInteger/ProbablePrime.java
+ test/java/math/BigInteger/StringConstructor.java
+ test/java/math/BigInteger/UnicodeConstructor.java
+ test/java/math/RoundingMode/RoundingModeTests.java



From jean-christophe.collet at sun.com  Tue Jan 27 02:46:26 2009
From: jean-christophe.collet at sun.com (jean-christophe.collet at sun.com)
Date: Tue, 27 Jan 2009 10:46:26 +0000
Subject: hg: jdk7/tl/jdk: 6790677: java.net.HttpCookie.parse(String) should
	ignore unrecognized attributes, RFC2965
Message-ID: <20090127104638.08BF8E20B@hg.openjdk.java.net>

Changeset: 53d9259661c3
Author:    jccollet
Date:      2009-01-27 11:36 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/53d9259661c3

6790677: java.net.HttpCookie.parse(String) should ignore unrecognized attributes, RFC2965
Summary: Changed code not to throw an exception on unknown attributes
Reviewed-by: chegar

! src/share/classes/java/net/HttpCookie.java
! test/java/net/CookieHandler/TestHttpCookie.java



From martinrb at google.com  Tue Jan 27 15:13:31 2009
From: martinrb at google.com (martinrb at google.com)
Date: Tue, 27 Jan 2009 23:13:31 +0000
Subject: hg: jdk7/tl/jdk: 6797480: Remove synchronization bottleneck in logger
Message-ID: <20090127231400.3CDA8E2A5@hg.openjdk.java.net>

Changeset: 6eac3829cb41
Author:    martin
Date:      2009-01-27 15:04 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6eac3829cb41

6797480: Remove synchronization bottleneck in logger
Reviewed-by: swamyv
Contributed-by: jeremymanson at google.com

! src/share/classes/java/util/logging/Logger.java



From joe.darcy at sun.com  Tue Jan 27 17:56:12 2009
From: joe.darcy at sun.com (joe.darcy at sun.com)
Date: Wed, 28 Jan 2009 01:56:12 +0000
Subject: hg: jdk7/tl/langtools: 6707027:
	langtools/test/tools/javac/processing/model/testgetallmember/Main.java
	fails
Message-ID: <20090128015615.90B56E306@hg.openjdk.java.net>

Changeset: edb8d7985cfd
Author:    darcy
Date:      2009-01-27 17:50 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/edb8d7985cfd

6707027: langtools/test/tools/javac/processing/model/testgetallmember/Main.java fails
Reviewed-by: jjg

! test/tools/javac/processing/model/testgetallmembers/Main.java



From jonathan.gibbons at sun.com  Tue Jan 27 18:41:11 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Wed, 28 Jan 2009 02:41:11 +0000
Subject: hg: jdk7/tl/langtools: 6176978: current Javadoc's invocation and
	extension (Doclet) mechanisms are problematic
Message-ID: <20090128024113.9CEA0E31B@hg.openjdk.java.net>

Changeset: 9199b9092f73
Author:    jjg
Date:      2009-01-27 18:38 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/9199b9092f73

6176978: current Javadoc's invocation and extension (Doclet) mechanisms are problematic
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java
+ test/tools/javadoc/6176978/T6176978.java
+ test/tools/javadoc/6176978/X.java



From joe.darcy at sun.com  Wed Jan 28 10:40:45 2009
From: joe.darcy at sun.com (joe.darcy at sun.com)
Date: Wed, 28 Jan 2009 18:40:45 +0000
Subject: hg: jdk7/tl/jdk: 6704655: Test
	test/java/lang/reflect/Generics/Probe.java fails under OpenJDK
Message-ID: <20090128184104.9E425E361@hg.openjdk.java.net>

Changeset: c2d2185a79dd
Author:    darcy
Date:      2009-01-28 10:30 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c2d2185a79dd

6704655: Test test/java/lang/reflect/Generics/Probe.java fails under OpenJDK
Reviewed-by: ksrini

! test/java/lang/reflect/Generics/Probe.java



From joe.darcy at sun.com  Wed Jan 28 12:52:18 2009
From: joe.darcy at sun.com (joe.darcy at sun.com)
Date: Wed, 28 Jan 2009 20:52:18 +0000
Subject: hg: jdk7/tl/jdk: 6719182: update legal notice in
	java/lang/instrument/package.html
Message-ID: <20090128205232.52A28E366@hg.openjdk.java.net>

Changeset: 1ebbc958f06a
Author:    darcy
Date:      2009-01-28 12:46 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1ebbc958f06a

6719182: update legal notice in java/lang/instrument/package.html
Reviewed-by: jjh

! src/share/classes/java/lang/instrument/package.html



From martinrb at google.com  Wed Jan 28 14:20:55 2009
From: martinrb at google.com (martinrb at google.com)
Date: Wed, 28 Jan 2009 22:20:55 +0000
Subject: hg: jdk7/tl/jdk: 6798822: (process) Non-portable use of isdigit in
	src/solaris/native/java/lang/UNIXProcess_md.c
Message-ID: <20090128222111.D745BE371@hg.openjdk.java.net>

Changeset: 6607850bd7fc
Author:    martin
Date:      2009-01-28 14:13 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6607850bd7fc

6798822: (process) Non-portable use of isdigit in src/solaris/native/java/lang/UNIXProcess_md.c
Reviewed-by: alanb
Contributed-by: christos at zoulas.com

! src/solaris/native/java/lang/UNIXProcess_md.c



From maurizio.cimadamore at sun.com  Thu Jan 29 04:26:03 2009
From: maurizio.cimadamore at sun.com (maurizio.cimadamore at sun.com)
Date: Thu, 29 Jan 2009 12:26:03 +0000
Subject: hg: jdk7/tl/langtools: 3 new changesets
Message-ID: <20090129122608.85745E3A2@hg.openjdk.java.net>

Changeset: 1aa81917016a
Author:    mcimadamore
Date:      2009-01-29 12:17 +0000
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/1aa81917016a

6315770: javac inference allows creation of strange types: Integer & Runnable
Summary: Javac does not apply glb correctly as per JLS3 15.12.2.8
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
+ test/tools/javac/generics/inference/6315770/T6315770.java
+ test/tools/javac/generics/inference/6315770/T6315770.out

Changeset: 4542977c959e
Author:    mcimadamore
Date:      2009-01-29 12:18 +0000
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4542977c959e

6557182: Unchecked warning *and* inconvertible types
Summary: Redundant warnings are generated when casting from intersection types
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/cast/6557182/T6557182.java
+ test/tools/javac/cast/6557182/T6557182.out

Changeset: 79f2f2c7d846
Author:    mcimadamore
Date:      2009-01-29 12:19 +0000
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/79f2f2c7d846

6729401: Compiler error when using F-bounded generics with free type variables
Summary: Javac applies wrong substitution to recursive type-variable bounds
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/generics/6729401/T6729401.java



From joe.darcy at sun.com  Thu Jan 29 09:08:48 2009
From: joe.darcy at sun.com (joe.darcy at sun.com)
Date: Thu, 29 Jan 2009 17:08:48 +0000
Subject: hg: jdk7/tl/jdk: 6239194: Object.hashCode() should reference
	System.identityHashCode()
Message-ID: <20090129170921.42403E3C8@hg.openjdk.java.net>

Changeset: 7241bd422542
Author:    darcy
Date:      2009-01-29 09:04 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7241bd422542

6239194: Object.hashCode() should reference System.identityHashCode()
Reviewed-by: emcmanus

! src/share/classes/java/lang/Object.java



From Jonathan.Gibbons at Sun.COM  Thu Jan 29 09:45:36 2009
From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons)
Date: Thu, 29 Jan 2009 09:45:36 -0800
Subject: CFV: Project sponsorship: Jigsaw
Message-ID: <4981EB40.4050705@sun.com>


Question: Should the Compiler Group sponsor the proposed 
         "Jigsaw" Project [1]?

Please cast your vote by replying, publicly, to this message with
either

Vote: yes

or

Vote: no

as the first line of the message body.

You may, at your option, indicate the reason for your decision on
subsequent lines.

Votes must be cast in the open; votes sent as private replies will
not be counted.

The sponsorship decision will be made by a simple majority vote of
the Group's Members.  Votes are due by midnight UTC next Monday,
15 December.  As an optimization, if an absolute majority of the
Group's Members votes one way or the other prior to that time then
the decision may be rendered earlier.

Only Members of the Compiler' Group are eligible to vote on this
decision.  The current Members are:

   Alex Buckley
   Maurizio Cimadamore
   Iris Clark
   Joe Darcy
   Neal Gafter
   Jonathan Gibbons
   John Rose
   Kumar Srinivasan

Once a decision has been made the votes will be summarized and
reported to this list and also to discuss at openjdk.java.net 
<mailto:discuss at openjdk.java.net>.

-- Jon

[1] http://mail.openjdk.java.net/pipermail/announce/2009-January/000066.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20090129/97e87c9a/attachment.html 

From Jonathan.Gibbons at Sun.COM  Thu Jan 29 09:49:17 2009
From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons)
Date: Thu, 29 Jan 2009 09:49:17 -0800
Subject: CFV: Project sponsorship: Jigsaw
In-Reply-To: <4981EB40.4050705@sun.com>
References: <4981EB40.4050705@sun.com>
Message-ID: <4981EC1D.1020206@sun.com>

Vote: yes


Jonathan Gibbons wrote:
>
> Question: Should the Compiler Group sponsor the proposed 
>          "Jigsaw" Project [1]?
>
> Please cast your vote by replying, publicly, to this message with
> either
>
> Vote: yes
>
> or
>
> Vote: no
>
> as the first line of the message body.
>
> You may, at your option, indicate the reason for your decision on
> subsequent lines.
>
> Votes must be cast in the open; votes sent as private replies will
> not be counted.
>
> The sponsorship decision will be made by a simple majority vote of
> the Group's Members.  Votes are due by midnight UTC next Monday,
> 15 December.  As an optimization, if an absolute majority of the
> Group's Members votes one way or the other prior to that time then
> the decision may be rendered earlier.
>
> Only Members of the Compiler' Group are eligible to vote on this
> decision.  The current Members are:
>
>    Alex Buckley
>    Maurizio Cimadamore
>    Iris Clark
>    Joe Darcy
>    Neal Gafter
>    Jonathan Gibbons
>    John Rose
>    Kumar Srinivasan
>
> Once a decision has been made the votes will be summarized and
> reported to this list and also to discuss at openjdk.java.net 
> <mailto:discuss at openjdk.java.net>.
>
> -- Jon
>
> [1] 
> http://mail.openjdk.java.net/pipermail/announce/2009-January/000066.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20090129/6d106ce5/attachment.html 

From Joe.Darcy at Sun.COM  Thu Jan 29 09:57:27 2009
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Thu, 29 Jan 2009 09:57:27 -0800
Subject: CFV: Project sponsorship: Jigsaw
In-Reply-To: <4981EB40.4050705@sun.com>
References: <4981EB40.4050705@sun.com>
Message-ID: <4981EE07.7080008@sun.com>

Vote: yes

Jonathan Gibbons wrote:
>
> Question: Should the Compiler Group sponsor the proposed 
>          "Jigsaw" Project [1]?
>
> Please cast your vote by replying, publicly, to this message with
> either
>
> Vote: yes
>
> or
>
> Vote: no
>
> as the first line of the message body.
>
> You may, at your option, indicate the reason for your decision on
> subsequent lines.
>
> Votes must be cast in the open; votes sent as private replies will
> not be counted.
>
> The sponsorship decision will be made by a simple majority vote of
> the Group's Members.  Votes are due by midnight UTC next Monday,
> 15 December.  As an optimization, if an absolute majority of the
> Group's Members votes one way or the other prior to that time then
> the decision may be rendered earlier.
>
> Only Members of the Compiler' Group are eligible to vote on this
> decision.  The current Members are:
>
>    Alex Buckley
>    Maurizio Cimadamore
>    Iris Clark
>    Joe Darcy
>    Neal Gafter
>    Jonathan Gibbons
>    John Rose
>    Kumar Srinivasan
>
> Once a decision has been made the votes will be summarized and
> reported to this list and also to discuss at openjdk.java.net 
> <mailto:discuss at openjdk.java.net>.
>
> -- Jon
>
> [1] 
> http://mail.openjdk.java.net/pipermail/announce/2009-January/000066.html



From Maurizio.Cimadamore at Sun.COM  Thu Jan 29 10:10:19 2009
From: Maurizio.Cimadamore at Sun.COM (Maurizio Cimadamore)
Date: Thu, 29 Jan 2009 18:10:19 +0000
Subject: CFV: Project sponsorship: Jigsaw
In-Reply-To: <4981EB40.4050705@sun.com>
References: <4981EB40.4050705@sun.com>
Message-ID: <4981F10B.5050201@sun.com>

Vote: yes

Maurizio

Jonathan Gibbons wrote:
>
> Question: Should the Compiler Group sponsor the proposed 
>          "Jigsaw" Project [1]?
>
> Please cast your vote by replying, publicly, to this message with
> either
>
> Vote: yes
>
> or
>
> Vote: no
>
> as the first line of the message body.
>
> You may, at your option, indicate the reason for your decision on
> subsequent lines.
>
> Votes must be cast in the open; votes sent as private replies will
> not be counted.
>
> The sponsorship decision will be made by a simple majority vote of
> the Group's Members.  Votes are due by midnight UTC next Monday,
> 15 December.  As an optimization, if an absolute majority of the
> Group's Members votes one way or the other prior to that time then
> the decision may be rendered earlier.
>
> Only Members of the Compiler' Group are eligible to vote on this
> decision.  The current Members are:
>
>    Alex Buckley
>    Maurizio Cimadamore
>    Iris Clark
>    Joe Darcy
>    Neal Gafter
>    Jonathan Gibbons
>    John Rose
>    Kumar Srinivasan
>
> Once a decision has been made the votes will be summarized and
> reported to this list and also to discuss at openjdk.java.net 
> <mailto:discuss at openjdk.java.net>.
>
> -- Jon
>
> [1] 
> http://mail.openjdk.java.net/pipermail/announce/2009-January/000066.html



From Kumar.Srinivasan at Sun.COM  Thu Jan 29 10:25:32 2009
From: Kumar.Srinivasan at Sun.COM (Kumar Srinivasan)
Date: Thu, 29 Jan 2009 10:25:32 -0800
Subject: CFV: Project sponsorship: Jigsaw
In-Reply-To: <4981EB40.4050705@sun.com>
References: <4981EB40.4050705@sun.com>
Message-ID: <4981F49C.2070501@Sun.COM>

Vote: yes
>
> Question: Should the Compiler Group sponsor the proposed 
>          "Jigsaw" Project [1]?
>
> Please cast your vote by replying, publicly, to this message with
> either
>
> Vote: yes
>
> or
>
> Vote: no
>
> as the first line of the message body.
>
> You may, at your option, indicate the reason for your decision on
> subsequent lines.
>
> Votes must be cast in the open; votes sent as private replies will
> not be counted.
>
> The sponsorship decision will be made by a simple majority vote of
> the Group's Members.  Votes are due by midnight UTC next Monday,
> 15 December.  As an optimization, if an absolute majority of the
> Group's Members votes one way or the other prior to that time then
> the decision may be rendered earlier.
>
> Only Members of the Compiler' Group are eligible to vote on this
> decision.  The current Members are:
>
>    Alex Buckley
>    Maurizio Cimadamore
>    Iris Clark
>    Joe Darcy
>    Neal Gafter
>    Jonathan Gibbons
>    John Rose
>    Kumar Srinivasan
>
> Once a decision has been made the votes will be summarized and
> reported to this list and also to discuss at openjdk.java.net 
> <mailto:discuss at openjdk.java.net>.
>
> -- Jon
>
> [1] 
> http://mail.openjdk.java.net/pipermail/announce/2009-January/000066.html


-- 
Kumar Srinivasan           
Sun Microsystems, Java Software.
408-276-7586

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20090129/7f530ea1/attachment.html 

From irisg at alum.mit.edu  Thu Jan 29 11:19:35 2009
From: irisg at alum.mit.edu (Iris Clark)
Date: Thu, 29 Jan 2009 14:19:35 -0500 (EST)
Subject: Project sponsorship: Jigsaw
Message-ID: <32246863.2226.1233256775008.JavaMail.help@alum.mit.edu>

Vote:  yes

iris

From John.Rose at Sun.COM  Thu Jan 29 12:39:58 2009
From: John.Rose at Sun.COM (John Rose)
Date: Thu, 29 Jan 2009 12:39:58 -0800
Subject: CFV: Project sponsorship: Jigsaw
In-Reply-To: <4981EB40.4050705@sun.com>
References: <4981EB40.4050705@sun.com>
Message-ID: <FC169F63-ED41-4DBD-A7E1-941F22C54E6C@sun.com>

Vote: yes

On Jan 29, 2009, at 9:45 AM, Jonathan Gibbons wrote:

>
> Question: Should the Compiler Group sponsor the proposed
>          "Jigsaw" Project [1]?
>
> ...
> [1] http://mail.openjdk.java.net/pipermail/announce/2009-January/ 
> 000066.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20090129/738fccbd/attachment.html 

From joe.darcy at sun.com  Thu Jan 29 13:09:57 2009
From: joe.darcy at sun.com (joe.darcy at sun.com)
Date: Thu, 29 Jan 2009 21:09:57 +0000
Subject: hg: jdk7/tl/jdk: 6327048: Enum javadoc could link to JLS; ...
Message-ID: <20090129211009.32523E3FB@hg.openjdk.java.net>

Changeset: ff9ad99b63cc
Author:    darcy
Date:      2009-01-29 13:04 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ff9ad99b63cc

6327048: Enum javadoc could link to JLS
6653154: Exception message for bad Enum.valueOf has spurious "class"
Reviewed-by: emcmanus

! src/share/classes/java/lang/Enum.java
! src/share/classes/java/lang/annotation/Annotation.java
+ test/java/lang/Enum/ValueOf.java



From Jonathan.Gibbons at Sun.COM  Thu Jan 29 15:19:36 2009
From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons)
Date: Thu, 29 Jan 2009 15:19:36 -0800
Subject: CFV: Project sponsorship: Jigsaw
In-Reply-To: <4981EB40.4050705@sun.com>
References: <4981EB40.4050705@sun.com>
Message-ID: <49823988.10705@sun.com>

There are already 6 votes in favor, which is an absolute majority of
the Group's Members. Therefore I am calling the result early, and
am pleased to announce the Compiler Group will sponsor this Project.

-- Jon


Jonathan Gibbons wrote:
>
> Question: Should the Compiler Group sponsor the proposed 
>          "Jigsaw" Project [1]?
>
> Please cast your vote by replying, publicly, to this message with
> either
>
> Vote: yes
>
> or
>
> Vote: no
>
> as the first line of the message body.
>
> You may, at your option, indicate the reason for your decision on
> subsequent lines.
>
> Votes must be cast in the open; votes sent as private replies will
> not be counted.
>
> The sponsorship decision will be made by a simple majority vote of
> the Group's Members.  Votes are due by midnight UTC next Monday,
> 15 December.  As an optimization, if an absolute majority of the
> Group's Members votes one way or the other prior to that time then
> the decision may be rendered earlier.
>
> Only Members of the Compiler' Group are eligible to vote on this
> decision.  The current Members are:
>
>    Alex Buckley
>    Maurizio Cimadamore
>    Iris Clark
>    Joe Darcy
>    Neal Gafter
>    Jonathan Gibbons
>    John Rose
>    Kumar Srinivasan
>
> Once a decision has been made the votes will be summarized and
> reported to this list and also to discuss at openjdk.java.net 
> <mailto:discuss at openjdk.java.net>.
>
> -- Jon
>
> [1] 
> http://mail.openjdk.java.net/pipermail/announce/2009-January/000066.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20090129/1f6e3804/attachment.html 

From mr at sun.com  Thu Jan 29 15:24:25 2009
From: mr at sun.com (Mark Reinhold)
Date: Thu, 29 Jan 2009 15:24:25 -0800
Subject: CFV: Project sponsorship: Jigsaw 
In-Reply-To: jonathan.gibbons@sun.com; Thu, 29 Jan 2009 15:19:36 PST;
	<49823988.10705@sun.com> 
Message-ID: <20090129232425.06C8D28CF40@eggemoggin.niobe.net>

> Date: Thu, 29 Jan 2009 15:19:36 -0800
> From: jonathan.gibbons at sun.com

> There are already 6 votes in favor, which is an absolute majority of
> the Group's Members. Therefore I am calling the result early, and
> am pleased to announce the Compiler Group will sponsor this Project.

Thank you all very much!

- Mark


From Jonathan.Gibbons at Sun.COM  Fri Jan 30 07:55:34 2009
From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons)
Date: Fri, 30 Jan 2009 07:55:34 -0800
Subject: langtools: no more warnings
Message-ID: <A6ABB274-6143-40D3-AF3C-EE1650E13A00@Sun.COM>

For those that didn't notice the fine print, a recent push to the  
langtools repository [1]  finally raised the quality bar on the  
langtools repository.
That push fixed (or suppressed) the remaining outstanding warnings in  
the repository, and enabled -Xlint:all -Werror.

Now, if only the other repositories could do the same...

-- Jon

[1] http://mail.openjdk.java.net/pipermail/compiler-dev/2009-January/000873.html


From gnu_andrew at member.fsf.org  Fri Jan 30 07:59:24 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Fri, 30 Jan 2009 15:59:24 +0000
Subject: langtools: no more warnings
In-Reply-To: <A6ABB274-6143-40D3-AF3C-EE1650E13A00@Sun.COM>
References: <A6ABB274-6143-40D3-AF3C-EE1650E13A00@Sun.COM>
Message-ID: <17c6771e0901300759s22884ba8l84f018bf18bffa11@mail.gmail.com>

2009/1/30 Jonathan Gibbons <Jonathan.Gibbons at sun.com>:
> For those that didn't notice the fine print, a recent push to the langtools
> repository [1]  finally raised the quality bar on the langtools repository.
> That push fixed (or suppressed) the remaining outstanding warnings in the
> repository, and enabled -Xlint:all -Werror.
>
> Now, if only the other repositories could do the same...
>
> -- Jon
>
> [1]
> http://mail.openjdk.java.net/pipermail/compiler-dev/2009-January/000873.html
>

We already had such a bug request for some of the JDK C code:

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=289

I just hope we're not going to be mired in cleanup patches as opposed
to real bug fixes.
-- 
Andrew :-)

IcedTea/OpenJDK Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8


From Jonathan.Gibbons at Sun.COM  Fri Jan 30 08:07:00 2009
From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons)
Date: Fri, 30 Jan 2009 08:07:00 -0800
Subject: langtools: no more warnings
In-Reply-To: <17c6771e0901300759s22884ba8l84f018bf18bffa11@mail.gmail.com>
References: <A6ABB274-6143-40D3-AF3C-EE1650E13A00@Sun.COM>
	<17c6771e0901300759s22884ba8l84f018bf18bffa11@mail.gmail.com>
Message-ID: <6806A0A0-594F-4C3A-931E-ECDCAB9456CA@Sun.COM>

Both cleanup patches and real bug fixes are good.  Reducing the  
unnecessary warnings makes it easier to see the significant ones.

Experience says we're unlikely to be overwhelmed by the cleanup  
patches ;-)

-- Jon

On Jan 30, 2009, at 7:59 AM, Andrew John Hughes wrote:

> 2009/1/30 Jonathan Gibbons <Jonathan.Gibbons at sun.com>:
>> For those that didn't notice the fine print, a recent push to the  
>> langtools
>> repository [1]  finally raised the quality bar on the langtools  
>> repository.
>> That push fixed (or suppressed) the remaining outstanding warnings  
>> in the
>> repository, and enabled -Xlint:all -Werror.
>>
>> Now, if only the other repositories could do the same...
>>
>> -- Jon
>>
>> [1]
>> http://mail.openjdk.java.net/pipermail/compiler-dev/2009-January/000873.html
>>
>
> We already had such a bug request for some of the JDK C code:
>
> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=289
>
> I just hope we're not going to be mired in cleanup patches as opposed
> to real bug fixes.
> -- 
> Andrew :-)
>
> IcedTea/OpenJDK Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> Support Free Java!
> Contribute to GNU Classpath and the OpenJDK
> http://www.gnu.org/software/classpath
> http://openjdk.java.net
>
> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
> Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8



From joe.darcy at sun.com  Fri Jan 30 12:44:30 2009
From: joe.darcy at sun.com (joe.darcy at sun.com)
Date: Fri, 30 Jan 2009 20:44:30 +0000
Subject: hg: jdk7/tl/jdk: 6799343: (fmt) java.util.Formatter uses plainlink
	instead of linkplain
Message-ID: <20090130204442.28818E5BA@hg.openjdk.java.net>

Changeset: 483e5c97d438
Author:    darcy
Date:      2009-01-30 12:40 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/483e5c97d438

6799343: (fmt) java.util.Formatter uses plainlink instead of linkplain
Reviewed-by: alanb

! src/share/classes/java/util/Formatter.java



From joe.darcy at sun.com  Fri Jan 30 15:11:39 2009
From: joe.darcy at sun.com (joe.darcy at sun.com)
Date: Fri, 30 Jan 2009 23:11:39 +0000
Subject: hg: jdk7/tl/jdk: 6799462: Minor typo (wrong word) in JavaDoc for
	InputStream.read(byte[] b) method
Message-ID: <20090130231151.4C80DE634@hg.openjdk.java.net>

Changeset: 948c504d6ef7
Author:    darcy
Date:      2009-01-30 15:09 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/948c504d6ef7

6799462: Minor typo (wrong word) in JavaDoc for InputStream.read(byte[] b) method
Reviewed-by: sherman, martin

! src/share/classes/java/io/InputStream.java