You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Joerg Heinicke <jo...@gmx.de> on 2005/08/19 12:29:07 UTC
[jci][fyi] JSR 199: Sun's JCI?
http://www.cafeaulait.org/oldnews/news2005August17.html
JSR 199 seems to be nearly three years old. Not much result to see :-)
Their analogy to the CompilationProblem handling: a DiagnosticListener (like our
CompilationProblemHandler) with just one method problemFound(DiagnosticMessage)
with DiagnosticMessage being really similar to CompilationProblem. Instead of
isError() it has a getKind() which allows finer handling.
Another interesting interface might be JavaFileObject hiding the details of
accessing resources. Though JCI has ResourceReader and ResourceStore it is not
really detached from file system.
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: resource names vs. file names (was: [jci][fyi] JSR 199: Sun's JCI?)
Posted by Torsten Curdt <tc...@apache.org>.
Sorry, for the late feedback.
>> These are converting between class names
>> and resource names! Which is fine!
>>
>
> Ah, ok. I should not talk that loud before looking exactly ;-) I
> had again a
> look into the sources. One naming that might give wrong impression
> is the
> parameter name of the methods in ResourceReader: "final String
> filename".
Sure ...things "evolve" ;)
> Another point is the FileResourceStore. The patch I sent in to get
> "rest of Java
> world"-filenames was a step in the wrong direction. The stores
> should store the
> resources by their resource name, not the class name. This would
> also solve the
> inconsistency for non-to-be-compiled resources I mentioned in the bug
> description. This needs some adaptions in certain places
> (ResourceStoreClassLoader, compilers), but the handling would be
> consistent
> afterwards.
>
> WDYT?
Yes, makes sense.
TBH I wanted to look into it when
doing the matching (see TODO)
cheers
--
Torsten
resource names vs. file names (was: [jci][fyi] JSR 199: Sun's JCI?)
Posted by Joerg Heinicke <jo...@gmx.de>.
Torsten Curdt <tcurdt <at> apache.org> writes:
> >> Huh? Why not? The memory implementations
> >> don't care much of the file system :-P
> >> That was one of the main goal of JCI.
> >
> > Yes and that's fine. But search for the String.replace(char, char)
> > method and
> > you know what I mean There are many places where class names
> > are converted
> > to file names and back. It's not only the FileResourceStore.
>
> These are converting between class names
> and resource names! Which is fine!
Ah, ok. I should not talk that loud before looking exactly ;-) I had again a
look into the sources. One naming that might give wrong impression is the
parameter name of the methods in ResourceReader: "final String filename".
Another point is the FileResourceStore. The patch I sent in to get "rest of Java
world"-filenames was a step in the wrong direction. The stores should store the
resources by their resource name, not the class name. This would also solve the
inconsistency for non-to-be-compiled resources I mentioned in the bug
description. This needs some adaptions in certain places
(ResourceStoreClassLoader, compilers), but the handling would be consistent
afterwards.
WDYT?
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jci][fyi] JSR 199: Sun's JCI?
Posted by Torsten Curdt <tc...@apache.org>.
>> Huh? Why not? The memory implementations
>> don't care much of the file system :-P
>> That was one of the main goal of JCI.
>>
>
> Yes and that's fine. But search for the String.replace(char, char)
> method and
> you know what I mean :-) There are many places where class names
> are converted
> to file names and back. It's not only the FileResourceStore.
These are converting between class names
and resource names! Which is fine!
...well, it should not bed done in so many
places. It should go into a utils class.
This can be done when while fixing the
matching (see TODO). And I also admit some
variable names do not reflect that difference.
But only the FileResourceStore and the
the FileResourceReader combine them
with a base dir to get the absolute
file on the disk.
cheers
--
Torsten
Re: [jci][fyi] JSR 199: Sun's JCI?
Posted by Joerg Heinicke <jo...@gmx.de>.
Torsten Curdt <tcurdt <at> apache.org> writes:
> > Another interesting interface might be JavaFileObject hiding the
> > details of
> > accessing resources. Though JCI has ResourceReader and
> > ResourceStore it is not
> > really detached from file system.
>
> Huh? Why not? The memory implementations
> don't care much of the file system :-P
> That was one of the main goal of JCI.
Yes and that's fine. But search for the String.replace(char, char) method and
you know what I mean :-) There are many places where class names are converted
to file names and back. It's not only the FileResourceStore.
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jci][fyi] JSR 199: Sun's JCI?
Posted by Torsten Curdt <tc...@apache.org>.
On 19.08.2005, at 12:29, Joerg Heinicke wrote:
> http://www.cafeaulait.org/oldnews/news2005August17.html
>
> JSR 199 seems to be nearly three years old. Not much result to see :-)
I know ...I heard we might get compilation
in java 1.6 ...but not necessarily compiler
abstraction *shrug*
> Another interesting interface might be JavaFileObject hiding the
> details of
> accessing resources. Though JCI has ResourceReader and
> ResourceStore it is not
> really detached from file system.
Huh? Why not? The memory implementations
don't care much of the file system :-P
That was one of the main goal of JCI.
cheers
--
Torsten