I think the Posse, Joe, and Alex were a bit hard on Lombok. You can do a lot with a system like Lombok. My own pet project, https://pec.dev.java.net/nonav/compile/index.html, adds many language like features by using bytecode manipulation, e.g. multiple dispatch. For method delegates I think that Bruce Chapman has demonstrated method delegates using annotations for example.
On Sep 24, 7:22 am, Reinier Zwitserloot <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
