Well, lombok is filled with eclipsy stuff because it is a parasitic compiling tool, not a library. Keep that in mind, since many people misses that: LOMBOK IS NOT A LIBRARY. In javac, it does its black magic by invading javac's inner AST's. For eclipse, it is worse because it replaces some of eclipse's compiler classes (or something like that, I'm not really sure about all the gory details).
However, it is somewhat common to see preople adding lombok as a runtime dependency. By being a build tool, like javadoc/ant/javac, you shouldn't add it as a runtime dependency. It is a compile-time-only dependency and should never be added to runtime classpaths, so the produced JAR/classfiles should not have any dependency with lombok ever. So, by being a tool that is plugged onto the compiler and never be used at runtime, it would benefit little from stronger modularization. As I said, it is not a library and should not be used as such, it is solely a build tool. But then you have byte-buddy that generates things at runtime and uses lombok for that. But lombok should not be used at runtime as a library, so we have a contradiction here. The problem here is that to do it's black magic, byte-buddy needs to use parts of lombok as a library, but lombok was not built to be a library afterall. So, what you are telling me seems to be more-or-less a great misunderstanding. We could use the case of byte-buddy to persuade lombok guys to better modularize it by actually seeing some valor in doing so, since now, lombok (or at least part of it) would be a library afterall and not just some weird part of the compiler toolchain. However, by opening up a ticket at their github to say that you have some trouble compiling it and that "*I have filed a bug with byte-buddy-dep, requesting they stop using lombok. It is really the worst Java package I have ever come across.*" you immediatelly thrown away any hope to get some collaboration out of those guys and also failed to explain them what was the real issue you were trying to solve. However, flaming that over here would be unproductive. I can go and submit a bug report to lombok guys asking for better modularization by providing a clear reason for that. But, this is no excuse to not attack the problem on Netbeans side. So, what is wrong with PatchModuleFileManager.getLocationForModule and ProxyFileManager.getLocationForModule? The PatchModuleFileManager.getLocationForModule method seems to be the one that tries to produce a bad URL. If the problem is solely lombok's fault afterall (dunno), what types of defenses can Netbeans use to avoid that some weird tool messing around with compiler's internal stuff breaks everything? Victor Williams Stafusa da Silva 2018-03-09 18:54 GMT-03:00 William L. Thomson Jr. <wlt...@o-sinc.com>: > On Fri, 9 Mar 2018 16:11:23 -0500 > cowwoc <cow...@bbs.darktech.org> wrote: > > > I gave up using Lombok with JDK 9 months ago. Yes, it is far more > > unstable under Netbeans than with other IDEs but it is generally a > > mess under JDK9 regardless of which IDE you use. > > I am not a fan of Lombok either. > > I reported a build issue under 9, and their recommendation was to use > ant to build it... > https://github.com/rzwitserloot/lombok/issues/1562#issuecomment-363549169 > > Which I fail to see how that would solve the issue. > > src/core/lombok/javac/apt/Javac9BaseFileObjectWrapper.java:38: error: > Javac9BaseFileObjectWrapper is not abstract and does not override > abstract method getSibling(String) in PathFileObject > class Javac9BaseFileObjectWrapper extends > com.sun.tools.javac.file.PathFileObject { > > Compiler errors like that are not resolved by ant/maven/gradle. Unless > they are doing something I could as well, modifying files, options, > etc. I run into stuff like that a lot and requires code fixes. I do not > believe they implemented that class properly in the first place. > Something is very odd there per my comments and attempts to fix. > https://github.com/rzwitserloot/lombok/issues/1562 > > I have filed another issue with byte-buddy to eventually move away from > Lombok. It requires a massive amount of Eclipse to build from source. > If your building Netbeans from source. You end up with a lot of Eclipse > dependencies, just because of Lombok. > https://github.com/raphw/byte-buddy/issues/397 > https://github.com/apache/incubator-netbeans/blob/master/spi.java.hints/ > nbproject/project.properties#L24 > > I was able to switch over to Google AutoValue in byte-buddy for > Netbeans 9 using sed in a crude manner. > https://github.com/Obsidian-StudiosInc/os-xtoo/blob/ > master/dev-java/byte-buddy-dep/byte-buddy-dep-9999.ebuild#L47 > > Not sure if that was successful or not. It allows byte-buddy to build, > and I can build the pieces of Netbeans that need byte-buddy, like > spi-java-hints. If it works at runtime I cannot confirm 100% yet. But I > haven't seen any issues just the same. > https://github.com/Obsidian-StudiosInc/os-xtoo/blob/ > master/nb-ide/netbeans-spi-java-hints/netbeans-spi-java- > hints-9999.ebuild#L9 > > Sent a PR to byte-buddy, but since they want to keep legacy support and > AutoValue is 8+, they have to keep Lombok. > https://github.com/raphw/byte-buddy/pull/400#issuecomment-361006248 > > -- > William L. Thomson Jr. >
