6502395: Is not a bug

[Jonathan Gibbons]

Thank you for your analysis. I am inclined to agree with you that the  
use of createResource is incorrect.

UnsupportedOperationException is normally used when an implementing  
class does not conceptually implement a method, typically an abstract  
method, defined by a supertype or superinterface.  It should not be  
used in cases like you describe for 6u11, when the operation is  
conceptually supported, but user arguments or user state preclude  
successful operation.

The behavior in 6u11 seems wrong, but 6u11 is not part of OpenJDK and  
so it will fall to us (Sun) to follow up and fix.  However, it is good  
to know that the behavior in 7 is already fixed.

There was no change in behavior of the Filer class intended when the  
DefaultFileManager was changed to JavacFileManager. However, it could  
be that the behavior was changed as part of some other fix.

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.

-- Jon


On Dec 12, 2008, at 8:18 AM, Emil Siemes wrote:

> The bug report 6502395 says: "Filer.getResource() states that  
> IOException is thrown if the file cannot be opened."
> But the attached Java class (see below) calls Filer.createResource()  
> instead of getResource() and when openReader() gets called an  
> IllegalStateException is thrown (Reading from a write-only Object).
> This is actually expected behavior and not a bug .  
> JavacFiler.createResource returns a FileObject. The spec for  
> FileObject.createResource reads:
> "Throws:
> IllegalStateException - if this file object was opened for writing  
> and does not support reading
> UnsupportedOperationException - if this kind of file object does not  
> support character access
> IOException - if an I/O error occurred"
> The Object implementing FileObject returned by the JavacFiler is a  
> com.sun.tools.javac.processing.JavacFiler$FilerOutputFileObject  and  
> the openReader method clearly throws a IllegalStateException.So I  
> think 6502395 should be closed and the bug effectively is in the bug  
> report not in the jdk :-)
>
> If we change the attached Java class and replace createResource with  
> getResource and run it again with jdk7 (b36&b40 & b41) I get:
> "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)
>     at  
> javax 
> .tools.ForwardingFileObject.openReader(ForwardingFileObject.java:92)
>     at  
> UnexistingResourceProcessor.process(UnexistingResourceProcessor.java"
> as it should be.
> With jdk6 update 11 I get instead:
> "java.lang.UnsupportedOperationException
>     at com.sun.tools.javac.util.DefaultFileManager 
> $RegularFileObject.openReader(DefaultFileManager.java:1281)
>     at  
> javax 
> .tools.ForwardingFileObject.openReader(ForwardingFileObject.java:74)
>     at  
> UnexistingResourceProcessor.process(UnexistingResourceProcessor.java"
> Not nice but may be still in line with spec because one could argue  
> that a FileObject for a non existing File does indeed not support  
> character access and therefore UnsupportedOperationException should  
> be thrown.
>
> Is wasn't able to find jdk releases older than build 36. Are they  
> available for download somewhere? If yes I could check in which  
> build the thrown exception changed. In b03 the DefaultFileManager  
> was renamed to JavacFileManager maybe also the exception was changed  
> around that time?
>
> "Bug"-Description:
> The spec for javax.annotation.processing.Filer.getResource() states  
> that
> IOException is thrown if the file cannot be opened.
>
> So 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.
>
> You may reproduce the behavior using following processor class:
>
> package tmp;
>
> import java.io.InputStream;
> import
>  java.io.Reader;
> import javax.annotation.processing.AbstractProcessor;
> import javax.annotation.processing.RoundEnvironment;
> import javax.annotation.processing.Filer;
> import javax.lang.model.element.TypeElement;
> import javax.lang.model.SourceVersion;
> import java.util.Set;
> import java.util.HashSet;
> import java.io.IOException;
> import javax.tools.StandardLocation;
>
> public class UnexistingResourceProcessor extends AbstractProcessor {
>     StandardLocation[] locations = {
>          StandardLocation.CLASS_OUTPUT, StandardLocation.SOURCE_OUTPUT
>     };
>
>     public Set<String> getSupportedAnnotationTypes() {
>         return new HashSet<String>() {{add("*");}};
>     }
>
>     public SourceVersion getSupportedSourceVersion() {
>         return SourceVersion.RELEASE_6;
>     }
>
>     public boolean process(Set<? extends TypeElement> annotations,  
> RoundEnvironment roundEnv) {
>
>  boolean passed = true;
>         if(roundEnv.processingOver()) {
>             Filer filer = processingEnv.getFiler();
>             for (StandardLocation location: locations) {
>                 try {
> // Opening for writing and then reading? No No No.
>                     Reader reader = filer.createResource(
>                             location, "", "foo/" + location +  
> ".unexisting").openReader(true);
>                     reader.close();
>                     System.out.println("location: " + location);
>                 } catch (IOException expected) {
>                 } catch (Exception e) {
>                     passed = false;
>                     System.out.println("location: " + location + ",  
> thrown: " + e);
>                 }
>             }
>         }
>         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: Mittwoch, den 10. Dezember 2008, 17:17:54 Uhr
> Betreff: Re: 651779, 6502392 & 6502395: Annotation processing bugs
>
> Emil,
>
> Thank you for your offer; I will check up on your SCA for you.
>
> The first bug number you gave is invalid; I'm guessing you mean
> 6517779.   I don't believe anyone is working on any of those issues.
>
> -- Jon
>
>
> On Dec 10, 2008, at 1:25 AM, Emil Siemes wrote:
>
>> Hi everyone,
>>
>> I thought it might be more important than ever to start
>> collaborating and supporting openjdk now.
>>
>> I would like to volunteer for fixing annotation processing
>> bugs like 651779, 6502392 & 6502395. Anyone already working
>> on them?
>>
>> I sent in a signed SCA by mail 10 days ago but haven't yet got any
>> feedback. Is that ok, or might the mail be lost?
>>
>> Thanks and best Regards
>>   Emil
>>
>>
>
>
>

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