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.
