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