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
_______________________________________________
mylar-dev mailing list
mylar-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mylar-dev
|
