Home » Language IDEs » Java Development Tools (JDT) » 2.2 and JDT AST
| 2.2 and JDT AST [message #1812] |
Tue, 22 April 2003 13:02  |
Eclipse User |
|
|
|
Originally posted by: vranganath.cox.net
Hi,
Following is the list of items proposed in Eclipse 2.2 concerning JDT.
Since, I plan to work on a project heavily based on JDT. In particular,
the Java language and the representation of a Java program in memory
(AST). Is there any resolution as far as bullets 1 and 4 are
concerned? I am asking this as I see the development cycle with release
artifacts has started for v2.2. Also, could somebody elalorate the last
bullet? How rich/powerful will the Refactoring API be? What sort of
operations will it support to change/alter the AST?
Proposed Items (Eclipse JDT subproject)
*Add early support for J2SE 1.5 features.* The next feature release
of J2SE is version 1.5 ("Tiger"), targeted to ship in the first half
of 2004. While the contents of this release are still under
discussion (JSR-176 <http://jcp.org/en/jsr/detail?id=176>), this
release is expected to contain extensions to the Java language,
including generic types (JSR-014
<http://jcp.org/en/jsr/detail?id=014>), enumerations, autoboxing,
enhanced for loops, static imports (all JSR-201
<http://jcp.org/en/jsr/detail?id=201>), metadata facility (JSR-175
<http://jcp.org/en/jsr/detail?id=175>), and compiler APIs (JSR-199
<http://jcp.org/en/jsr/detail?id=199>). Supporting these new
language and compiler features will require major changes to the
Eclipse Java compiler, JDT Core APIs, and JDT UI. Although Eclipse
2.2 will likely ship before J2SE 1.5 does, Eclipse should contain
early support for J2SE 1.5 features wherever possible [JDT Core, JDT
UI, JDT Debug]
( new) *Improve support for Java-like source files.* JSP and JSQL
are two instances of languages that embed passages of Java language
code. Eclipse should provide better support for Java-like source
files. For instance, outline views should be able to show the
hierarchy of Java elements; it should be possible to index these
files so that Java search can find the Java declarations and
references within; it should be possible to use Java code assist on
the Java passages; refactoring should be able to take these files
into account; the debugger should be able to step through the Java
passages (JSR-045 <http://jcp.org/en/jsr/detail?id=045>); error
highlighting should be supported across sections; etc. [JDT Core,
JDT UI, JDT Debug]
( new) *Support Java references from non-Java files.* References to
Java elements in particular classes can show up in specific kinds of
non-Java files, such as plug-in manifest files (plugin.xml). These
references should also participate in Java operations like search,
move, rename, and other refactoring operations. JDT will surface
APIs that enable other plug-ins to contribute to and participate in
these operations. [JDT Core, JDT UI, JDT Debug]
( new) *Harmonize Java source manipulation.* The Java model is
currently implemented in terms of JDOM, an early precursor of the
AST facility added in 2.0. JDT will move to an AST- based
implementation of the Java model, and deprecate JDOM. [JDT Core]
( new) *Present **logical view of Java objects in debugger.* The
current debugger always presents the internal structure of Java
objects. For instances of standard data structures like
java.util.HashMap, the Java debugger should be able to present a
higher level logical view of the object (i.e., to show it as a table
of key-to value mappings). [JDT Debug]
( new) *Provide API for refactoring**.* JDT should allow other
plug-ins to contribute specialized refactoring operations, and
provide the infrastructure to make it possible for them to do so.
[JDT Core, JDT UI]
waiting for reply,
--
Venkatesh Prasad Ranganath,
Dept. Computing and Information Science,
Kansas State University, US.
web: http://www.cis.ksu.edu/~rvprasad
|
|
|
| Re: 2.2 and JDT AST [message #2665 is a reply to message #1812] |
Wed, 23 April 2003 13:38  |
| Eclipse User |
|
|
|
See my comments below.
Dirk
"Venkatesh Prasad Ranganath" <vranganath@cox.net> wrote in message
news:b83rsp$hs9$1@rogue.oti.com...
> Hi,
>
> Following is the list of items proposed in Eclipse 2.2 concerning JDT.
> Since, I plan to work on a project heavily based on JDT. In particular,
> the Java language and the representation of a Java program in memory
> (AST). Is there any resolution as far as bullets 1 and 4 are
> concerned? I am asking this as I see the development cycle with release
> artifacts has started for v2.2. Also, could somebody elalorate the last
> bullet? How rich/powerful will the Refactoring API be? What sort of
> operations will it support to change/alter the AST?
The idea behind this item is to open up refactoring for non Java languages
as well. This means:
- allow others to trigger Java refactorings by creating corresponding
refactoring objects (e.g.
enhance the already exisiting refactoring support provided in 2.1)
- allow others to participate in refactorings (for example renaming a Java
method updates references
in JSP files as well).
- allow others to use the refactoring infrastructure to implement
refactorings for JSP, HTML, ....
Currently it isn't planned to make JDT internal classes used to implement
Java refactorings
(like AST rewriting, precondition checking algorithms, ...) API.
>
> Proposed Items (Eclipse JDT subproject)
>
> *Add early support for J2SE 1.5 features.* The next feature release
> of J2SE is version 1.5 ("Tiger"), targeted to ship in the first half
> of 2004. While the contents of this release are still under
> discussion (JSR-176 <http://jcp.org/en/jsr/detail?id=176>), this
> release is expected to contain extensions to the Java language,
> including generic types (JSR-014
> <http://jcp.org/en/jsr/detail?id=014>), enumerations, autoboxing,
> enhanced for loops, static imports (all JSR-201
> <http://jcp.org/en/jsr/detail?id=201>), metadata facility (JSR-175
> <http://jcp.org/en/jsr/detail?id=175>), and compiler APIs (JSR-199
> <http://jcp.org/en/jsr/detail?id=199>). Supporting these new
> language and compiler features will require major changes to the
> Eclipse Java compiler, JDT Core APIs, and JDT UI. Although Eclipse
> 2.2 will likely ship before J2SE 1.5 does, Eclipse should contain
> early support for J2SE 1.5 features wherever possible [JDT Core, JDT
> UI, JDT Debug]
>
> ( new) *Improve support for Java-like source files.* JSP and JSQL
> are two instances of languages that embed passages of Java language
> code. Eclipse should provide better support for Java-like source
> files. For instance, outline views should be able to show the
> hierarchy of Java elements; it should be possible to index these
> files so that Java search can find the Java declarations and
> references within; it should be possible to use Java code assist on
> the Java passages; refactoring should be able to take these files
> into account; the debugger should be able to step through the Java
> passages (JSR-045 <http://jcp.org/en/jsr/detail?id=045>); error
> highlighting should be supported across sections; etc. [JDT Core,
> JDT UI, JDT Debug]
>
> ( new) *Support Java references from non-Java files.* References to
> Java elements in particular classes can show up in specific kinds of
> non-Java files, such as plug-in manifest files (plugin.xml). These
> references should also participate in Java operations like search,
> move, rename, and other refactoring operations. JDT will surface
> APIs that enable other plug-ins to contribute to and participate in
> these operations. [JDT Core, JDT UI, JDT Debug]
>
> ( new) *Harmonize Java source manipulation.* The Java model is
> currently implemented in terms of JDOM, an early precursor of the
> AST facility added in 2.0. JDT will move to an AST- based
> implementation of the Java model, and deprecate JDOM. [JDT Core]
>
> ( new) *Present **logical view of Java objects in debugger.* The
> current debugger always presents the internal structure of Java
> objects. For instances of standard data structures like
> java.util.HashMap, the Java debugger should be able to present a
> higher level logical view of the object (i.e., to show it as a table
> of key-to value mappings). [JDT Debug]
>
> ( new) *Provide API for refactoring**.* JDT should allow other
> plug-ins to contribute specialized refactoring operations, and
> provide the infrastructure to make it possible for them to do so.
> [JDT Core, JDT UI]
>
>
> waiting for reply,
>
> --
>
> Venkatesh Prasad Ranganath,
> Dept. Computing and Information Science,
> Kansas State University, US.
> web: http://www.cis.ksu.edu/~rvprasad
>
>
|
|
|
| Re: 2.2 and JDT AST [message #3779 is a reply to message #2665] |
Wed, 23 April 2003 23:00 |
| Eclipse User |
|
|
|
Originally posted by: vranganath.cox.net
Dirk Bäumer wrote:
>See my comments below.
>
>Dirk
>
>"Venkatesh Prasad Ranganath" <vranganath@cox.net> wrote in message
>news:b83rsp$hs9$1@rogue.oti.com...
>
>
>>Hi,
>>
>>Following is the list of items proposed in Eclipse 2.2 concerning JDT.
>>Since, I plan to work on a project heavily based on JDT. In particular,
>>the Java language and the representation of a Java program in memory
>>(AST). Is there any resolution as far as bullets 1 and 4 are
>>concerned? I am asking this as I see the development cycle with release
>>artifacts has started for v2.2. Also, could somebody elalorate the last
>>bullet? How rich/powerful will the Refactoring API be? What sort of
>>operations will it support to change/alter the AST?
>>
>>
>
>The idea behind this item is to open up refactoring for non Java languages
>as well. This means:
>
>- allow others to trigger Java refactorings by creating corresponding
>refactoring objects (e.g.
> enhance the already exisiting refactoring support provided in 2.1)
>- allow others to participate in refactorings (for example renaming a Java
>method updates references
> in JSP files as well).
>- allow others to use the refactoring infrastructure to implement
>refactorings for JSP, HTML, ....
>
>Currently it isn't planned to make JDT internal classes used to implement
>Java refactorings
>(like AST rewriting, precondition checking algorithms, ...) API.
>
>
So, does that mean that with the current JDT implementation I cannot
extract AST corresponding to a Java File, change the AST, and have the
changes reflected in Java File? I was under the impression that this
could be done. Also, to enable/expose such support is it possible to
open a feature request?
>
>
>
>>Proposed Items (Eclipse JDT subproject)
>>
>> *Add early support for J2SE 1.5 features.* The next feature release
>> of J2SE is version 1.5 ("Tiger"), targeted to ship in the first half
>> of 2004. While the contents of this release are still under
>> discussion (JSR-176 <http://jcp.org/en/jsr/detail?id=176>), this
>> release is expected to contain extensions to the Java language,
>> including generic types (JSR-014
>> <http://jcp.org/en/jsr/detail?id=014>), enumerations, autoboxing,
>> enhanced for loops, static imports (all JSR-201
>> <http://jcp.org/en/jsr/detail?id=201>), metadata facility (JSR-175
>> <http://jcp.org/en/jsr/detail?id=175>), and compiler APIs (JSR-199
>> <http://jcp.org/en/jsr/detail?id=199>). Supporting these new
>> language and compiler features will require major changes to the
>> Eclipse Java compiler, JDT Core APIs, and JDT UI. Although Eclipse
>> 2.2 will likely ship before J2SE 1.5 does, Eclipse should contain
>> early support for J2SE 1.5 features wherever possible
>>
>> ( new) *Improve support for Java-like source files.* JSP and JSQL
>> are two instances of languages that embed passages of Java language
>> code. Eclipse should provide better support for Java-like source
>> files. For instance, outline views should be able to show the
>> hierarchy of Java elements; it should be possible to index these
>> files so that Java search can find the Java declarations and
>> references within; it should be possible to use Java code assist on
>> the Java passages; refactoring should be able to take these files
>> into account; the debugger should be able to step through the Java
>> passages (JSR-045 <http://jcp.org/en/jsr/detail?id=045>); error
>> highlighting should be supported across sections; etc.
>>
>> ( new) *Support Java references from non-Java files.* References to
>> Java elements in particular classes can show up in specific kinds of
>> non-Java files, such as plug-in manifest files (plugin.xml). These
>> references should also participate in Java operations like search,
>> move, rename, and other refactoring operations. JDT will surface
>> APIs that enable other plug-ins to contribute to and participate in
>> these operations.
>>
>> ( new) *Harmonize Java source manipulation.* The Java model is
>> currently implemented in terms of JDOM, an early precursor of the
>> AST facility added in 2.0. JDT will move to an AST- based
>> implementation of the Java model, and deprecate JDOM.
>>
>> ( new) *Present **logical view of Java objects in debugger.* The
>> current debugger always presents the internal structure of Java
>> objects. For instances of standard data structures like
>> java.util.HashMap, the Java debugger should be able to present a
>> higher level logical view of the object (i.e., to show it as a table
>> of key-to value mappings). [JDT Debug]
>>
>> ( new) *Provide API for refactoring**.* JDT should allow other
>> plug-ins to contribute specialized refactoring operations, and
>> provide the infrastructure to make it possible for them to do so.
>> [JDT Core, JDT UI
>>
>>waiting for reply,
>>
>>--
>>
>>Venkatesh Prasad Ranganath,
>>Dept. Computing and Information Science,
>>Kansas State University, US.
>>web: http://www.cis.ksu.edu/~rvprasad
>>
>>
>>
>>
>
>
>
>
|
|
| | |
| Code formatting and CVS in/out triggers? [message #6380 is a reply to message #3779] |
Sat, 26 April 2003 01:07 |
| Eclipse User |
|
|
|
Is there anything being done on two fronts: One, Code Formatting along the
lines of Jalopy? And two, formatting when check in/out occurs? I am all in
favor of having all code in a given repository be formatted in one specific
manner, but allowing each developer to work on it with their own format.
What I would like to see happen, if at all possible, is the ability for any
check-in to be set up to format the code in a specific way, save the file,
then check it in, as well as when checked out, a specific format applied to
it before displayed in the editor.
But I really want to see Jalopy features added to the build-in formatting of
code. Probably seems like a stupid thing to want, but I am very picky about
the code I work with. Having it formatted the way I like makes it much
easier to work on than being stuck with whatever format was last saved.
When can we expect something along these lines in the 2.2 (or is it 3.0)
branch for testing?
|
|
|
| Re: Code formatting and CVS in/out triggers? [message #8526 is a reply to message #6380] |
Tue, 29 April 2003 11:08 |
| Eclipse User |
|
|
|
Originally posted by: KingD.TCE.com
"Kevin" <supreme_java_guru_1@yahoo.com> wrote in message
news:b8d4ak$6vv$1@rogue.oti.com...
> Is there anything being done on two fronts: One, Code Formatting along the
> lines of Jalopy? And two, formatting when check in/out occurs? I am all in
> favor of having all code in a given repository be formatted in one
specific
> manner, but allowing each developer to work on it with their own format.
> What I would like to see happen, if at all possible, is the ability for
any
> check-in to be set up to format the code in a specific way, save the file,
> then check it in, as well as when checked out, a specific format applied
to
> it before displayed in the editor.
>
> But I really want to see Jalopy features added to the build-in formatting
of
> code. Probably seems like a stupid thing to want, but I am very picky
about
> the code I work with. Having it formatted the way I like makes it much
> easier to work on than being stuck with whatever format was last saved.
>
> When can we expect something along these lines in the 2.2 (or is it 3.0)
> branch for testing?
Here is the request I submitted for this a year ago:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=12458
--
Dale King
|
|
|
Goto Forum:
Current Time: Fri May 02 09:35:57 EDT 2025
Powered by FUDForum. Page generated in 0.06651 seconds |
Home