AW: AW: AW: AW: 6502395: Is not a bug
Emil Siemes
digitalemil at yahoo.de
Mon Jan 19 18:16:46 PST 2009
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 openedI'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/20090120/ad9c4e0f/attachment.html
More information about the compiler-dev
mailing list