| Java 6 interfaces [message #229904] |
Thu, 18 May 2006 18:55  |
Eclipse User |
|
|
|
Originally posted by: wharley.bea.com
Java 6 adds a number of interfaces in the javax.* packages. Several such,
peripherally involved in the JSR269 annotation processing scheme and thus of
interest to me, are javax.tools.FileObject, javax.tools.JavaFileObject, and
javax.tools.JavaFileManager.
These interfaces are intended to provide a file abstraction layer for tools
(see e.g.
http://download.java.net/jdk6/docs/api/javax/tools/JavaFileM anager.html).
It looks like I'll need an implementation of these on top of the Eclipse
resource framework. (Yet another abstraction of the filesystem, just what
we need...)
Is there anyone already planning on implementing these interfaces, within
JDT or the Platform? I didn't see anything in Bugzilla and I don't know if
3.3 planning docs are published yet.
Thanks!
-Walter Harley
JDT APT team
|
|
|
|
|
|
|
|
|
| Re: Java 6 interfaces [message #230167 is a reply to message #230092] |
Thu, 25 May 2006 21:09  |
| Eclipse User |
|
|
|
Originally posted by: wharley.bea.com
"John Arthorne" <john@eclipsefaq.org> wrote in message
news:e51r8k$j07$1@utils.eclipse.org...
> Hi Walter,
>
> Can you briefly describe why you would need to implement these interfaces
> on top of the IResource API? Another option to consider is to implement
> those interfaces on top of the Eclipse file system API (in
> org.eclipse.core.filesystem plugin). The IResource framework itself is
> built on top of the EFS API. Since the EFS API is much closer to the file
> system level, it seems like a logical fit to bridge the APIs at that
> level. The fact that both javax.tools.FileObject and the EFS IFileStore
> both use URI as identifiers should make it easier.
Hi, John.
No good reason at present; I'm still just learning about the requirements.
Actually, I've just been digging into the code and it looks like when
generating Java files we actually sit on top of the Java Model, rather than
even on the IResource framework, in order to manage some resource-listener
issues: e.g., we call methods like
IPackageFragmentRoot.createPackageFragment(). Conversely, when generating
non-Java files it looks like we're using java.io.File, so I'm not sure how
we're coordinating with the workspace in that case.
The relevant JSR-269 APIs are just things like this:
JavaFileObject createSourceFile(CharSequence name)
Client code (specifically, a JSR-175 annotation processor) would call that
method to create a file, and would then write text into the file; the file
would then participate in further compilation.
|
|
|
| Re: Java 6 interfaces [message #230222 is a reply to message #230167] |
Fri, 26 May 2006 15:16 |
| Eclipse User |
|
|
|
Originally posted by: john.eclipsefaq.org
> Hi, John.
>
> No good reason at present; I'm still just learning about the requirements.
> Actually, I've just been digging into the code and it looks like when
> generating Java files we actually sit on top of the Java Model, rather than
> even on the IResource framework, in order to manage some resource-listener
> issues: e.g., we call methods like
> IPackageFragmentRoot.createPackageFragment(). Conversely, when generating
> non-Java files it looks like we're using java.io.File, so I'm not sure how
> we're coordinating with the workspace in that case.
>
> The relevant JSR-269 APIs are just things like this:
>
> JavaFileObject createSourceFile(CharSequence name)
>
>
> Client code (specifically, a JSR-175 annotation processor) would call that
> method to create a file, and would then write text into the file; the file
> would then participate in further compilation.
Generally using java.io.File when interacting with files in an Eclipse
workspace is not the best choice. Since this will go straight to disk,
you miss out on useful illusions created by the resource framework and
the Java model, such as linked resources, non-local files, etc. If you
are creating files and packages directly using either Java model or
resource API, you are better off. Generally the higher the level of
abstraction, the more you get for free. From a JDT perspective, the
order of preference would be Java Model > Resource model > EFS >
java.io.File. Many levels of indirection, indeed.
|
|
|
Powered by
FUDForum. Page generated in 0.06407 seconds
Home