Er, forgot the footnote:
The pinnacle of making language changes easy as a developer of those changes seems to be to simply fork javac. This is the route KSL and Kijaro have taken, as well as e.g. the BGGA prototype. There is nothing stopping us from doing a similar trick, and then shipping this modified java inside lombok's own jar. lombok then uses the same trick shown in the disableCheckedExceptions.jar proof-of-concept to pretty much replace whatever javac you are using with its own internal version. You'd be using a custom javac, but you'd just be calling: javac -cp useEntirelyDifferentJavac.jar MyCode.java with the javac executable that you're calling being the plain jane vanilla version. Read: maven, ant, and many other tools will continue to work just fine. This is NOT what lombok does at the moment, but it's one strategy we could use. A similar trick can be used in eclipse (or any other IDE): Clone the JDT (the java-specific bits of eclipse), ship it as a new module that one needs to first install, then use the agent load mechanism to 'fix' the OSGi loader architecture in eclipse to load our own forked JDT instead of eclipse's. Again, not what lombok does at the moment, but we could go there if that ends up being more convenient and scalable. It would be rather spectacularly bad at dealing with updates of the host platform - the moment lombok stops being actively supported, you can't update again, which is the main reason for holding off. However, there are tricks that can help here as well: Instead of forking everything, you can just fork those bits and pieces that really need replacing. Fork a module/javac, then run a diff to see what actually changed, and only replace those class files. This principle can be applied even further - store the diff between the original class and the replacement, and then use a smart system that attempts to apply this diff to whatever is actually found at runtime. Such a system would be able to cope with sizable version updates to the host environments before things truly start breaking down. We've already seen this happen in eclipse: lombok worked without any modifications on eclipse 3.4 even though we designed it only for 3.5. Unfortunately, javac5 and javac6 are very different, and javac7 appears to again be introducing a big stack of changes, but presumably this new codebase of javac will stabilize out after that. On Sep 24, 4:26 am, Reinier Zwitserloot <[email protected]> wrote: > I heard some disparaging remarks on the interview regarding the > potential for lombok to tackle such complex jobs as closures. > > Make no mistake about this. We're going to go there. > > We've got a gazillion tricks still up our collective sleeves. If > you're interested, scroll down to the footnote[1] for a rough sketch > on how we can make anything happen, at a relatively modest complexity > level. > > Here's the big difference between lombok's view of how new language > features ought to work, and Joe's: > > Joe thinks the programmer needs to jump through hoops. Lombok thinks > (and I am of the opinion that lombok is in the right, and Joe is > entirely in the wrong) that the software ought to be doing the > jumping. > > So, Joe's proposal of implementing a @Getter-esque boilerplate buster > via a standard annotation processor makes YOU jump through hoops: You > blow up your object hierarchy, as the getter methods neccessarily need > to go in a super or subclass. Joe blamed tool integration of > annotation processors at some point, but please look into your own > house first and address netbeans' _abysmal_ support for the processing > API! Netbeans doesn't support it _at all_ - you get your annotation > processors run solely because a 'full build' will trigger ant or > maven, which, using the vanilla javac (and not the slightly tweaked > one that's inside netbeans. One of the tweaks is to just turn all > processors off, completely!), will run annotation processors. Eclipse > has done a much better job on this: There they are run everytime you > save. (For the IntelliJ fans, intellij sucks as much as netbeans in > this regard. No support whatsoever, and like netbeans, the fact that > full builds shell out to maven/ant doesn't count). > > This is quite in opposition to lombok, where @Getter *just* *works*, > and does so transparently; people using your class will never know > you're using lombok, and it works instantaneously, and not only after > saving your file (or in netbeans/intellij: doing a full build). > > There's a theme here: We'll do _whatever_ it takes to make the > features work well from the perspective of the developer. > > Speaking of the interview: Joe and Alex: You're _entirely_ correct > about the openJDK: If javac had not been open source lombok would > never have happened. There's hope for netbeans, but IntelliJ folks: If > you're reading this, lombok is never going to go to IntelliJ unless > you integrate it yourself or get in touch with us to give us some > help. Without sources, we can't do our thing. So, thanks sun, and the > eclipse foundation, for making such fine open source products we can > (ab)use :) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
