Try JDK 9 specifically.
The fact that they use bytecode injection makes their library very
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
> 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
> On Fri, Mar 9, 2018 at 5:57 PM, Christian Lenz <christian.l...@gmx.net>
> > 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
> > 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)
> > not working, it will not search for the getter and setter, it searches
> > the private fields. But IntelliJ can resolve this part, which is very
> > Handy. Go to declaration on a getter or setter getId() which was
> > 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: firstname.lastname@example.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.
> > > 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
> > 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.