On 4/24/06, Don Brown <[EMAIL PROTECTED]> wrote: > > So... is that a +1? :) > > As for annotations, I'd imagine we'd keep the XML as override so most > anything you can do with annotations, you could > also do in XML. This would give Java 1.4 users mostly the same > capabilities.
I think he was expressing a technical concern :-). And, depending on how you want to use annotations, it's an important one. It is straightforward to see how one could use annotations at build time, even if the ultimate target platform is 1.4. You can do things like run the "apt" tools, generate new code (or maybe generate config files that correspond to what the annotations signify) as part of the build process -- as long as the build process itself was running on Java SE 5, of course. Even this might be too much of a leap for some organizations, however. But the annotations facility also provides *runtime* mechanisms to examine a Class instance and determine what annotations are present. I do not see how that can be done with something like Retroweaver, for two reasons: * The annotations themselves can't be stored in the compiled class, because there is nowhere to put them. * The APIs to do the reflective checks (added to the Class class in 1.5) don't exist in the 1.4 runtime. This would be a pretty serious limitation on what you might otherwise want to do with annotations -- but, again, it depends on the intended usage patterns. Because of the above issues, I'm -0 on this, (it's not reasonable for me to vote -1 since I'm not the one that is wanting to do the work). I think a better strategy would be to have the core framework depend solely on 1.4, but provide an optional layer on top which leverages 1.5 things for those who actually do have a 1.5 runtime environment. That's the approach taken by the "Tiger Extensions" to Shale[1]. And, the first two features of these extensions (use annotations instead of configuration files, and use annotations instead of implementing interfaces) are *very* similar to the sorts of things that would make 1.5 attractive in [action2]. Don Craig [1] http://struts.apache.org/struts-shale/features-tiger-extensions.html Alexandru Popescu wrote: > > This looks quite nice. I cannot figure out what means support for > > annotations. Even if they are left inside the classbytecode, you will > > not have access to the API to use them (except the case they are > > weaving the Class.class, but I really don't think so). > > > > ./alex > > -- > > .w( the_mindstorm )p. > > > > > > On 4/24/06, Don Brown <[EMAIL PROTECTED]> wrote: > >> There has been a lot of discussion on Java 5 support for Struts Action > 2, and from my reading of the comments, we have > >> settled on a path, but I want to formalize it in a vote to ensure we > are all on the same page. > >> > >> I vote we develop Struts Action 2 with Java 5, taking advantage of it > where ever we can. At the same time, we should > >> use Retroweaver to build jars that will run in a 1.4 JVM. For those > that aren't familiar, Retroweaver supports > >> conversion of an impressive amount of Java 5 features and language > changes. In summary, Retroweaver supports [1]: > >> > >> * generics > >> * extended for loops > >> * static imports > >> * autoboxing/unboxing > >> * varargs > >> * enumerations > >> * annotations > >> > >> Therefore, our development philosophy will be to take _full_ advantage > of Java 5, but provide a working jar for Java > >> 1.4, however, we can't guarantee every Struts Action 2.0 feature will > be available to Java 1.4 users. > >> > >> ------------------------------------------------------------------ > >> [ ] +1 Make Java 5 the target > >> [ ] +0 I am fine with this move, but I'll still mainly interested in > 1.4 > >> [ ] -0 I am not too keen, because ... > >> [ ] -1 I am against this move, because ... > >> ------------------------------------------------------------------ > >> > >> I'll tally the votes after at least 72 hours and include the count in > our STATUS file. The vote is open to anyone. > >> > >> Don > >> > >> [1] http://retroweaver.sourceforge.net/documentation.html > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
