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