Anyway, independent of how much lombok finger-pointing, blaming or flaming we have, there seems to be something indeed problematic in Netbeans side. If I use Maven or Gradle to build a non-modular lombok project in Java 9, it builds correctly afterall, but Netbeans chokes with that.
Looking at the source, the problems comes from line 113 of PatchModuleFileManager, which is this: final URL url = fo.toUri().toURL(); This is the link: https://github.com/apache/incubator-netbeans/blob/master/java.source.base/src/org/netbeans/modules/java/source/parsing/PatchModuleFileManager.java#L113 That "fo" is a javax.tools.JavaFileObject instance probably provided by lombok or by something else related. The toUri() method provides a java.net.URI object which is then converted to a java.net.URL. However, the toURL() method throws an exception for URIs that aren't absolute. Although I can go on to the lombok source trying to understand how and why the heck the non-absolute URI is generated and also talk with them about the issue, I first want to know if JavaFileObject instances should be allowed to have non-absolute URIs, since the toUri() method javadocs are silent about that. The Netbeans code clearly and strongly assumes that whichever instance of JavaFileObject received will always provide an URI which can be derived to a URL (and so, the URI has to be absolute). The URL is compared with many URL keys of a Map to see if it is a child of some of those accordingly to the toExternalForm() method (which produces a String). The keys to the Map are produced by the parseModulePatches(Iterator<? extends String>) method of the org.netbeans.modules.java.source.parsing.FileObjects class. My first tought is that the URI indeed must be absolute in order to clearly be able to refer to a unambiguously identifiable resource. But on a second thought, it might (or might not) make sense that code-generating tools provides URIs that aren't absolute. On a third tought, even if non-absolute URIs make no sense, Netbeans could try to provide some defense against that (i.e: if the URI is a "file://" or "jar://", but is not absolute, normalize it before proceeding). This would not only serve the purpose of defending from questionable practices on lombok side, but on any other weird code-generation-on-the-fly tool that will come around in the next corner tomorrow. Since there is no clear and explicit requirement that the toURI() method shoudl provide an absolute URI, trying something to remedy the situation if that occurs might be a good idea. On a forth thought, as I said in this list in a moment last year (looking for that very same issue, but had not enough time to chase it deeper), using URLs instead of URIs seems to be dangerous because the equals method of the URL class sucks, making it a poor choice as a key to a map. However (as someone also said at that time), we are still in the safe side because the URL's equals method delegates the work to the StreamHandler which have no problems when the protocol is "file://" and "jar://", which are the ones produced from java.util.File by the inner guts of the parseModulePatches method (if we ever change that by producing an "http://"; URL somewhere, we would be screwed, so I consider this approach fragile and questionable at least). But, thinking about the code, I see a loop bruteforcing a bunch of URLs trying to match the JavaFileObject with any of them, for every JavaFileObject that eventually comes along. This doesn't seems to be an efficient approach for this problem on the Netbeans side. Anyway, this code at least explains why we have no problem in JDK 8. It is part of the code which handle modules which do not exist prior to Java 9. My conclusion is that the bug is probably lombok's fault, since it generates a JavaFileObject without an absolute URI. But on lombok's defense, there is nothing in the specification of javax.tools.FileObject saying that the URI must be absolute. Also, regardless of this fact, perhaps Netbeans could fix the issue on its side as well. Victor Williams Stafusa da Silva 2018-03-10 16:06 GMT-03:00 Gili T. <cow...@bbs.darktech.org>: > Josh, > > Try JDK 9 specifically. > > The fact that they use bytecode injection makes their library very > unstable. > > Gili > > On Sat, Mar 10, 2018, 11:59 Josh Juneau <juneau...@gmail.com> wrote: > > > I will chime in to mention that I utilize Lombok with NetBeans 8.2 and it > > works most of the time. There are some annoyances that I've noticed, but > > it is most certainly due to the fact that Lombok is a compile-time > > process...not a library, as mentioned in a previous thread. Typically > if I > > change my Maven POM file at all, I need to clean my project, deleting > > "target", and recompile twice...a priming compile to download the Lombok > > dependency and then another to compile. Sometimes I need to change my > > Lombok dependency between 1.16.16 and 1.16.18 to force a re-download of > the > > Lombok dependency. Annoying...but not really NetBeans' fault and I still > > prefer the cleaner code that does not become cluttered with getters and > > setters. > > > > I'll test with JDK 8 and Apache NetBeans 9 to see how it works, although > I > > know it is not part of the NetCAT official testing. > > > > Josh Juneau > > juneau...@gmail.com > > http://jj-blogger.blogspot.com > > https://www.apress.com/index.php/author/author/view/id/1866 > > > > > > On Fri, Mar 9, 2018 at 5:57 PM, Christian Lenz <christian.l...@gmx.net> > > wrote: > > > > > I have to use lombok in our Company, so it works ok but is not that > > > Feature rich unfortunately. I can’t refactor the getter and setter, > when > > I > > > added @Getter and @Setter and Change the private variable. There is an > > > Option while refactoring: „Refactor getter and setter too“. But it > seems > > > not working. > > > > > > Find usages of the private fields (where the getter and setter created) > > is > > > not working, it will not search for the getter and setter, it searches > > for > > > the private fields. But IntelliJ can resolve this part, which is very > > > Handy. Go to declaration on a getter or setter getId() which was > > generated > > > from private long id, is also not working. > > > > > > I use lombok with NetBeans 8.2. I know that this is not the right > thread, > > > I only wanted to mention it. Will create tickets for this „Problem“. > > > > > > Didn’t test it with NB 9 > > > > > > > > > Cheers > > > > > > Chris > > > > > > Von: William L. Thomson Jr. > > > Gesendet: Samstag, 10. März 2018 00:22 > > > Cc: dev@netbeans.incubator.apache.org > > > Betreff: Re: Netbeans 9.0 is very unstable with lombok in JDK 9 > > > > > > On Fri, 9 Mar 2018 19:44:08 -0300 > > > Victor Williams Stafusa da Silva <victorwssi...@gmail.com> wrote: > > > > > > > > So, what you are telling me seems to be more-or-less a great > > > > misunderstanding. > > > > > > Mostly for others, that miss I am building everything from source. I > > > care more about compile time than runtime dependencies. I am making > > > jars, not using others. Quite many things have different runtime > > > dependencies than compile time. Which is why I run into many issues > > > others do not. > > > > > > Like this one for Netbeans > > > https://github.com/apache/incubator-netbeans/pull/392 > > > > > > > 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. > > > > > > They have their own dependency issues to address. Almost a year old I > > > have zero hope for movement there. > > > https://github.com/rzwitserloot/lombok.patcher/issues/2 > > > > > > Not to mention new compile time ones that show up in patch versions... > > > https://github.com/rzwitserloot/lombok/issues/1437 > > > > > > If you read that, they make illogical excuses on why they cannot > > > properly version releases of Lombok. They get upset when you give them > > > some details on what your doing so they can understand. > > > > > > Really broken down best by the points in this comment. > > > > > https://github.com/rzwitserloot/lombok/issues/ > 1437#issuecomment-339757312 > > > > > > > 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. > > > > > > I do not make such statements lightly and it was not my first > > > interaction with them. The amount of open issues, etc Make the entire > > > project clearly a mess. > > > > > > 21 issues related to Netbeans > > > > > https://github.com/rzwitserloot/lombok/issues? > utf8=%E2%9C%93&q=is%3Aissue+ > > > is%3Aopen+netbeans > > > > > > My first experience with it was saying it was a terrible package and > > > one of the maintainers commented a fix. > > > https://github.com/Obsidian-StudiosInc/os-xtoo/commit/ > > > dc0aa4cfc834ac598810a7db59ddcac5a8a0dbfc#commitcomment-22235501 > > > > > > Before I went to package Netbeans from source. Lombok had more Java > > > dependencies than anything else I came across short of Spring. The need > > > for all that mess was for hibernate, which never finished. Had I tried > > > to remove lombok from byte-buddy before I may have made more progress > > > on hibernate from source. Which I need to get back to someday. > > > > > > I got lucky Netbeans also needed byte-buddy to make that previous > > > effort worth while. I have spent, or more like wasted so much time with > > > packaging Lombok just to build other stuff that needed it. I really > > > really dislike it for valid reasons. > > > > > > > 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. > > > > > > You have more faith in them than I do in that regard. I do not see the > > > being flexible or open to changes per a few interactions. I have made > > > reasonable requests, most all denied but the circular deps one. > > > > > > > But, this is no excuse to not attack the problem on Netbeans side. > > > > > > I am not attacking the Netbeans side. I see it as a Lombok problem, > > > that IMHO Netbeans should not be bothered with. Lombok has many issues > > > with Netbeans per other open issues. > > > > > > > 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? > > > > > > Not sure but IMHO I think anything Path/File related seems like it will > > > use the Javac9BaseFileObjectWrapper, and given issues with that. I am > > > not sure how any of it works at all on Java 9. If it can't build, I > > > cannot see how it can run. Much if it was last touched long before 9 > > > was released. > > > https://github.com/rzwitserloot/lombok/commits/ > > > master/src/core/lombok/javac/apt/Javac9BaseFileObjectWrapper.java > > > > > > None of that IMHO has anything to do with Netbeans, more Lombok's crazy > > > code. > > > > > > -- > > > William L. Thomson Jr. > > > > > > > > >
