AW: AW: 6502395: Is not a bug

Mon Jan 5 15:07:16 PST 2009

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 