[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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jci][fyi] JSR 199: Sun's JCI?
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 PGP.sig Description: This is a digitally signed message part
Re: [jci][fyi] JSR 199: Sun's JCI?
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jci][fyi] JSR 199: Sun's JCI?
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 PGP.sig Description: This is a digitally signed message part
resource names vs. file names (was: [jci][fyi] JSR 199: Sun's JCI?)
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
