AW: AW: 6502395: Is not a bug

[Emil Siemes]

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