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.
> > > >
> > > >
> > >
> >
>

Reply via email to