Having read this thread not much more than an hour ago, I'm already thinking, "Yes, javac should quietly fall by the wayside and be replaced with something like the JDT work that Andy has been looking at for Groovy".
I've just hit that wonderful point where I want to provide a callback on every IOException thrown from an InputStream... why should I have to write try/catch in every bloomin method... surely we need to be freed from Java being so often used entirely on it's own. I'm now awaiting the SpringSource demo of incremental compilation of Java, Groovy, Scala and AspectJ, all using the same JDT compiler ;-) On Thu, 23 Jul 2009 08:23 -0500, "Michael McCray" <[email protected]> wrote: I am most interested in: AspectJ or Java Groovy or Scala Clojure, JRuby, or other misc. In the above list, Java seems stuck in terms of closures for example, so this puts AspectJ in an adverse situation. So I look towards Scala for continued use. If we talk about Aspect* to support each of the other languages, then that would be a fork or an add on or something of the core AspectJ code. The ideal aspect solution would be for AspectJ to lead the multilanguage aspect compatibility. AspectJ is already a mixed language approach, ok, sure you can simply use AspectJ compiler, but I find that I tend to write aspect code separate from Java code that is non-aspect. In my head I feel that with AspectJ I am freed to write good clean Java code that isn't cluttered by all sorts of external concerns. So there is this split anyway. It would be really nice if these could be simply chosen as desired, some weird (bytecode oriented) any class can call any (other languages) class, can be advised by any language. The joint groovy compiler and aspectj compiler (aspectj or plain java) is a good example of this. I think this picture is complicated by these options: write pointcut in x language write advice in x language write aspect in x language (style of the language - scala syntax, vs, java style, vs. ()s clojure style). Maybe I am overgeneralizing, but It would seem that the parser that compiles the aspect would only have to parse the x new language, and transform into the existing AspectJ AST model. Mike References Visible links Hidden links: 1. http://twitter.com/seagullmike -- Neale Upstone [email protected]
_______________________________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users
