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

Jonathan Gibbons Jonathan.Gibbons at Sun.COM
Mon Jan 19 18:55:13 PST 2009


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 


More information about the compiler-dev mailing list