Re: Netbeans 9.0 is very unstable with lombok in JDK 9

[Victor Williams Stafusa da Silva]

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 :

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

Re: Netbeans 9.0 is very unstable with lombok in JDK 9

[Jan Lahoda]

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

Re: Netbeans 9.0 is very unstable with lombok in JDK 9

[Victor Williams Stafusa da Silva]

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

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

Re: Netbeans 9.0 is very unstable with lombok in JDK 9

[Gili T.]

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

Re: Netbeans 9.0 is very unstable with lombok in JDK 9

[Josh Juneau]

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

Re: Netbeans 9.0 is very unstable with lombok in JDK 9

[William L. Thomson Jr.]

On Fri, 9 Mar 2018 19:44:08 -0300
Victor Williams Stafusa da Silva  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=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.


pgpBjKvHOymfb.pgp
Description: OpenPGP digital signature

Re: Netbeans 9.0 is very unstable with lombok in JDK 9

[Victor Williams Stafusa da Silva]

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

> On Fri, 9 Mar 2018 16:11:23 -0500
> cowwoc  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-.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/
> 

Re: Netbeans 9.0 is very unstable with lombok in JDK 9

[William L. Thomson Jr.]

On Fri, 9 Mar 2018 16:11:23 -0500
cowwoc  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-.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-.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.


pgp_Gasar9pt2.pgp
Description: OpenPGP digital signature

Re: Netbeans 9.0 is very unstable with lombok in JDK 9

[cowwoc]

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.


Gili

On 2018-03-09 4:09 PM, Victor Williams Stafusa da Silva wrote:

Hi, I download latest Netbeans 9.0 beta last week and I'm using with JDK 9.
My lombok projects makes Netbeans really unusable.

Those are the steps for reproducing it:

1. Create a new project.
2. Set the properties of the project to ensure that it is using JDK 9.
3. Download lombok-1.16.20.jar and put it in the project libs folder,
adding it in the project properties page.
4. Create the following class:

import lombok.NonNull;

public class NetbeansLombokBugTest2 {
 public static void main(@NonNull String[] args) {
 }
}

5. Save the file (Ctrl+S). Modify it by adding a blank space somewhere and
save it again (Ctrl+S).

Netbeans will start to spam repeatedly the error "IllegalArgumentException:
URI is not absolute". This bug makes Netbeans almost unusable to work with
lombok on JDK 9. Whenever you touch anything in the project, even other
java source files that have nothing to do with lombok, you'll get the
spamming error screen popping up regardless of anything.

The bug seems to not be reproducible if the project uses JDK 8 is used
instead.

I am already getting some occasional other further errors when I insist in
using the IDE regardless of prior errors, however I was still unable to
isolate them so far.

I already reported something similar a few months ago, but I weren't able
to isolate the bug at that time and due to many real-life issues I had not
enough time to research it much further.

Is anyboby able to reproduce it?

Victor Williams Stafusa da Silva




-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists