AW: AW: AW: 6502395: Is not a bug

[Emil Andreas Siemes]

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