Mik Kersten wrote:
Could you
elaborate what you mean by
“Eclipse Way”? They’re not being exploited much in
Eclipse yet because APT integration and JavaModel support for
annotations
won’t really be there until 3.2. I think that annotations are a
great mechanism for specifying metadata that should be inline with the
source
and consumable by compiler, VM, or IDE tool. For example, one
annotation
that we use internally is @MylarWebRef, which brings web pages into
your degree
of interest, e.g. if you got an example from a doc source or blog.
Another is to be able to explicitly state that something is of
landmark
interest no matter what context it’s in. But this is still very
experimental, and won’t expose any of these annotations mechanisms
until
the mechanism for having a workspace-wide aggregate context is there,
since
there is overlap. And we will soon be able to do the web ref stuff
implicitly by monitoring Internal Browser navigation. Either way,
thanks
to the fact that backport175 is starting to work really well (my
experience
from AspectJ) we will be able to support any annotation stuff with 1.4
syntax
transparently.
Mik, you are right that
there is not really
much of de facto standards in this area. However if you think about it,
it is
more dev-time only metadata. Since there are lot of code that can't use
java5
annotations for one or another reason it doesn't really make sense to
use
annotatations just yet. Note that backport175 intended to be used to
produce run-time
annotations, so they would only available in the code and I guess only
in case
if code does not have any build errors, which is potentially big
limitation.
So, it seems that special java-doc based annotations for pre-Java 5
targets is a way to go, but Mylar should work with AST directly and do
own
source scanning for annotations. Shouldn't be that difficult. because
Alex's
backport175 plugin already does all the work, you just need to hook-up
Mylar's
monitor in there. And in case of Java 5 project you can use standard
AST
processing tool (e.g. Sun's or Eclipse plugin from BEA that just
released
recently).
Regarding
other Java5 features, we only
rely on them to ease development. I just counted and we have thousands
of
generic type usages, and so we haven’t seen a ClassCastExceptoin for
months. We also have dozens of enums. These and the other
small Java 5 features save us substantial development and defect time,
and some
I’m hoping that the retroweaver approach will mean that we can avoid
lowering the quality of the code in the process of supporting 1.4.
We’ll know soon!
Right.
It is just with
retroweaver you are making Mylar build more complicated. You are saying
it
worth it...
regards,
Eugene
Mik Kersten wrote:
In the
near-term my main concern is that
1.5 only compatibility will prevent some from contributing to Mylar.
In
the longer term yes, this tool should not be limited to the masses who
are
still stuck on 1.4. Also, the fact that there is no 1.5-based free
software stack bothers me.
Next week
we’ll try to set up a 1.4
compatible retroweaver/backport build and document progress on https://bugs.eclipse.org/bugs/show_bug.cgi?id=104601.
Also, removing the 1.5 stuff from mylar.tasklist and mylar.bugzilla is
not out of the question if that results in contribution to those
components,
but since that will be a pain we’ll wait to see what happens with
Retroweaver.
Mik,
you've
mentioned another day that you are using annotation to specify degree
of
interest. I think that it is not exactly an "Eclipse way" isn't it?
Is there are any other Java5 features besides annotations that
actually
important for Mylar?
Thanks
Eugene
