Whoa, okay - I'll answer all questions: QUESTION: Where's the source? It's not hosted on code.google.com
ANSWER: No, it isn't, because googlecode doesn't support git. Click the 'fork me on github!' thingie on the top-right of http://projectlombok.org/ for the source repo, and clone away! QUESTION: How does it work? ANSWER: On javac: With an annotation processor that casts the RoundEnvironment and TypeElement variables you get to javac's implementation classes (yes, that's non public API. This cannot be done without breaking SOME rules, obviously!). From those objects, you can change the entire AST well before javac generates the bytecode. On eclipse, annotation processors run far too late, so a java agent is used. Java agents allow you, amongst other things, to on-the-fly rewrite any classes that the system is about to load. We change eclipse's Parser class, which turns raw source characters into an Abstract Syntax Tree. We change it to simply call lombok's code first the moment it finishes building an AST. Then we do our thing. QUESTION: Advantages over groovy? ANSWER: Start with every advantage java has over groovy (static typing, etcetera), and add to this that unlike e.g. scala, you don't have to learn a new language, and you can continue to use the tools you use today. I know the scala eclipse and netbeans plugins are getting better every day, but they still can't hold a candle to the java development environments of those IDEs. Also, personally, I'm still partial to java. Except for the boilerplate. Which lombok gets rid of. Joy. QUESTION: Does it work in netbeans? ANSWER: No. We're working on it, sort of. Neither of the core developers use netbeans, so for serious support that keeps up with netbeans releases, we really need to get a netbeans fan to help us out. Netbeans uses javac internally, so *ALL* you need to do is 'hack' netbeans so it hands ASTs off to lombok's internals first thing. That's it - once you can do that, netbeans support is completed. If you're a bit familiar with netbeans this can't be too difficult. Because of netbeans internal javac tree usage, you won't have to write another version of all the transformation code - in other words, the JavacAnnotationHandler version of each transformation will work for netbeans as well. Of course, IDEA, being closed source, is a hopeless cause unless someone from jetbrains wants to help. That's the price you pay for not using open source, I guess. QUESTION: Is lombok extensible? ANSWER: *YES!* - it is! You can trigger a transformation off of an annotation, or off of any old node you want, such as for example a special method call. You do have to write every transformation twice (once for eclipse's AST and once for javac's. Those AST designs are sufficiently different to make an abstraction layer a major undertaking). QUESTION: Can this be used for closures? ANSWER: Yes and no. To add closures, you probably want to change the java grammar, which is not possible with the hook we use to instrument javac (annotation processors) - because the processors run AFTER javac has already tokenized and tree-ified the source into an AST. However, if you're willing to run javac with "javac - Jjavaagent:lombok.jar *.java", -OR- if you're willing to construct your closure proposal so its parser-legal, you can do it with lombok. On eclipse you can do whatever you want - the possibilities with a javaagent are limitless. Example parser-legal closure syntax: Collections.sort(list, new Comparator(Integer, Integer) {{ return $1 - $2; }}); The parser sees that as a new raw comparator (not generified), with 2 arguments passed to a non-existent constructor, both arguments named 'Integer', which isn't a variable name that exists, with no methods (including no compare method, which is required), but with an instance initializer, that includes a return statement which isn't even legal there. However, ALL of those issues are resolved in the binding stage, and lombok operates before that stage, so before this code ever gets to binding, lombok would be able to turn it into: Collections.sort(list, new Comparator<Integer>() { public int compare (Integer $1, Integer $2) { return $1 - $2; }}); Lombok would have to be able to do its own type-binding (for example, to figure out the return type and method name of the one abstract method in the type you're building a closure around), which it currently cannot do. It's planned, though. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
