D-oh! Just separated out lombok's patching aspects into a separate project that's a bit more flexible. Still, I'll have a look. Thanks, Peter.
On Oct 2, 2:49 pm, phausel <[email protected]> wrote: > Hi Reiner, > the new Scala Eclipse plugin is using Equinox Aspects > (http://www.eclipse.org/equinox/incubator/aspects/) to replace certain parts > of the JDT real time. Equinox Aspects is also getting some official > support in eclipse > 3.6http://download.eclipse.org/eclipse/downloads/drops/S-3.6M2-200909170... > > thought you might find it useful. > > Peter > > 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 -~----------~----~----~----~------~----~------~--~---
