I was waiting for an answer from the lombok team before giving further feedback here.
I created this issue there: https://github.com/rzwitserloot/lombok/issues/1617 and this pull request: https://github.com/rzwitserloot/lombok/pull/1626 For me, this simple one-line fix solved the issue on lombok's side. At netbeans side, maybe testing if the retrieved URI before calling toURL() is a good idea. Victor Williams Stafusa da Silva 2018-03-13 4:59 GMT-03:00 Jan Lahoda <lah...@gmail.com>: > Hi Victor, > > Thanks for looking at this. Some comments inline. > > On Tue, Mar 13, 2018 at 12:02 AM, Victor Williams Stafusa da Silva < > victorwssi...@gmail.com> wrote: > > > 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 > > > > I believe the code in NetBeans expects that it will get JFOs which NetBeans > has constructed. Which apparently is not the case here. This is not a > completely wrong assumption: I am not aware about any API that would allow > to inject external JFOs into javac. I guess a solution here might be to > ignore unknown JFOs, which is what the standard file manager in javac is > doing, for better or worse. > > 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. > > > > I guess a good proposal to make this more efficient would be welcome. > > The goal here is to find out if a given file belongs to any of the given > source roots. So the file's path is inside a given root, so it is not easy > to just look into some map and get the output. As far as I know, there are > two solutions for this method: > -the one used here in NetBeans: iterate over the roots, and ask if the > given file is inside the root > -the one used in javac: look at parents of the given file, to find out if > some of them is the root. > > It is difficult to say which of these is better, but the NB implementation > does not seem necessarily bad: I'd expect the number of entries in the map > to be very small (and typically zero), so iterating through the map should > be fast. > > Jan > > > > 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. > > > > > > > > > > > > > > > > > > > >
