Discussions

News: First look at Java 5 support in AspectJ, and other new features

  1. Now in its second milestone build, a major focus of AspectJ 5 is on providing support for the new Java language features introduced in Java 5, including annotations and generics. AspectJ 5 also contains new features not tied to Java 5, such as an annotation-based development style, improved load-time weaving, and a new aspect instantiation model.

    In the latest article in DeveloperWorks' AOP@Work series, Adrian Colyer provides an overview of both AspectJ 5 the language and the AspectJ 5 release containing the AspectJ compiler and associated tools.

    Threaded Messages (9)

  2. Why not source ?[ Go to top ]

    I do not understand why they insist of producing bytecode from aspects and do not give a very useful option (used to be present in ver 1.1 if I remember well) to generate source so that I can use whatever compiler I wish.
  3. Why not source ?[ Go to top ]

    Why do you care which compiler you use? Java compilers don't do much. It would also be slower and more difficult to implement.
  4. Why not source ?[ Go to top ]

    Why do you care which compiler you use? Java compilers don't do much. It would also be slower and more difficult to implement.

    I think the concern is the other way round. People trust code more that they know is valid.

    If you have a source intermediate that you can compile you can feel reasonably safe. If you just have a bytecode compiler you run a higher risk for the quality of your ultimate deliverable (the byte code).
  5. and more[ Go to top ]

    Agree. Moreover..
    1)If I have the source I can compile with another compiler which *might* have been designed to use optimization better than ajc. I said might...but I would like to have the option of choosing..
    2) Decompile the .class does not always give you back valid source and you guys should know that too.
    3) Generating bytecode, ajc has always to play the "catch up" game with the SUN's newer Java compiler

    I am NOT saying bytecode injection is bad. I am saying I would like to have the option to generate the source IF I need it.
  6. Cuz it's hard[ Go to top ]

    I would guess that the source generation option was dropped for a few reasons.

    1. This is a preview release, internals are in flux.
    2. When a product is focused on bytecode and weaving, producing compatible source code is an additional enhancement that is difficult to keep up with. In certain cases it may be very difficult or impossible to generate appropriate source. There have been a number of language changes over the years, each reflected by differences in compatible source. Bytecodes being much slower to evolve, are easier to work with and you don't have to worry about how to take a particular bytecode block and emmit clean 1.3, 1.4, 1.5 code.

    In short, it's much easier to output bytecode that your JVM can process, than it is to take that bytecode and turn it into source your given compiler can process.

    My guess is that's why you don't see source generation. But that said, it doesn't mean that it can never come back. I'd wait for the bytecode generation and weaving to settle down a bit and then ask again. Maybe on an AspectJ developer forum (not TSS).
  7. compiler plugin[ Go to top ]

    I think someone with some influence should introduce a JSR for compiler plugins, so multiple language addons can be used simultaniously (if compatible) and even with multiple compiler.
  8. Why not source ?[ Go to top ]

    ajc 1.0.x used to have a -preprocess option that would produce source code.

    We dropped the option (a long time ago) because it did more harm than good, not because it was hard. Remember when early C++ compilers used to generate C code, and very many people reasoned about their C++ programs in terms of the genenerated code? But C++ compilers moved beyond that phase and this helped people to think in terms of the abstraction that the C++ language offered (objects) rather than structs and function pointers.

    When ajc moved from version 1.0.x to 1.1, it was rebased from being a full "home-grown" implementation of a Java compiler to being an extension of the Eclipse JDT compiler. With a solid Java compiler behind the implementation, the need to replace the Java compiler used by AspectJ was greatly reduced (the Eclipse Java compiler gets a very good hammering from a very broad user base).

    With the "I want to look at what the compiler does in order to learn AOP" rationale being a harmful one (it leads to thinking in terms of words that begin with "i", such as "injection", rather than thinking in terms of the abstraction that the AspectJ language offers - aspects), and the need to replace the Java compiler greatly reduced, the option was removed from the compiler. [A Java program compiled from source generated by AspectJ would also have horrible debugging characteristics.]

    For the determinedly curious, you can always dissassemble the .class files that AspectJ creates of course.
  9. Why not source ?[ Go to top ]

    Remember when early C++ compilers used to generate C code, and very many people reasoned about their C++ programs in terms of the genenerated code?
    Oh no, I don't want to remember that. I totally agree with the point about the abstraction.
  10. I think AspectJ 5 will be a significant advance in the AOP space. As the first major release following the merger with AspectWerkz it adds important new functionality (especially annotation support, enhanced load-time weaving), within the mature, well-thought out model you would expect from AspectJ. From what I've seen, the tooling is also coming on impressively.

    It's just a pity that the annotation support is only going to be available--obviously--if you're using Java 5. Although I know AspectWerkz, JBoss AOP and various other projects have "backport" type annotation support below 1.5, without true native support in the language, annotations are a hard sell. (We've had support for Commons Attributes--a nice little library--in Spring forever for things like transaction attributes, but only a small number of users seem to have used it.)

    I think the JRockit integration is particularly interesting, especially as BEA are planning to get JRockit on a wider range of processor architectures.

    Congratulations to Adrian and team!

    Rgds
    Rod