Lombok 1.12.2 has some regressions with NetBeans #626
Comments
|
👤 michel.graciano 🕗 Oct 11, 2013 at 13:38 UTC Hi guys, The NetBeans issue that is tracking it is https://netbeans.org/bugzilla/show_bug.cgi?id=236885. I haven't yet listen from NetBeans side if it is a Lombok or NetBeans issue, but since it will escalate now with the new stable version, I think you deserve to know about it. The NetBeans issue already has a sample project and steps to reproduce it. If you need anything I can help, just let me know. Regards |
|
👤 michel.graciano 🕗 Oct 16, 2013 at 14:36 UTC Guys, |
|
👤 michel.graciano 🕗 Oct 16, 2013 at 16:23 UTC I want to add some more comments why IMHO this issue should have its priority increased. Due to this issue happens with Lombok 1.12.2 even in NetBeans 7.3.1, it is a regression which should be addressed asap. Users which wishes to use the just released NetBeans 7.4 will have no other choice as to upgrade to Lombok 1.12.2. Thanks in advance |
|
👤 pangalz 🕗 Oct 16, 2013 at 16:26 UTC I've the same issue with NetBeans 7.4. Apparently it was a regression of 1.x version which had broken the annotation processor. |
|
👤 reinierz 🕗 Oct 17, 2013 at 03:52 UTC I'm having a hard time assessing the priority on this. From the reports on netbeans' bugzilla tracker, it looks like invoking reformat actions on code with lombok annotations in them causes the source to go haywire. This is extremely low priority, simply because that'll always be a problem. IDEs fundamentally do not understand the concept of code that is really there, but takes up no characters. So, we HAVE to choose. Either we break the auto-formatter, or we break lookup features (because for 'jump to declaration' to work right, the constructor has to use the start/end position of the @ RequiredArgsConstructor annotation, and not the random whitespace anywhere where the generated constructor could have been legally written). For example, this doesn't work in eclipse either. If it ever did work in netbeans in a previous lombok version, I'm loathe to just say this is a regression; we probably fixed other broken things, and, as I said, often there is no way to always do the right thing in all circumstances. We could eventually get into agent-based hacking of netbeans to essentially patch it to understand the concept of generated code, but that's a huge undertaking. Same goes for generating code. Lombok should be doing the code generation for you; source insertion operations like 'create constructor' are not expected to work right if lombok is also making constructors. This is somewhat of a gray area; if usage of any lombok anywhere in a source file breaks, for example, the 'rename method' refactor script, that would warrant a much higher priority (there is no reason for lombok to break that, and we can probably fix it). So, what, exactly goes wrong? |
|
👤 michel.graciano 🕗 Oct 17, 2013 at 11:32 UTC Take this as a simple example:package lombok; import java.math.BigDecimal; import lombok.experimental.Builder; @ NoArgsConstructor(access = AccessLevel.PRIVATE) }Now I gonna try to rename the class name to Bean1, and this is what I got: package lombok; import java.math.BigDecimal; import lombok.experimental.Builder; @ NoArgsConstructor(access = AccessLevel.PRIVATE) Bean1 BBasically anything that the IDE do is broken now. Any refactoring that I do is broken. Sometimes it is 'simpler', just the last } is missing, but always I have some kind of issue. Basically Lombok broke every NetBeans code assistant. |
|
👤 michel.graciano 🕗 Oct 17, 2013 at 11:40 UTC For example, sometimes I want Lombok to do just some things for me, as builder for example, but the getters/setters, constructors or something else sometimes I want to do by myself, and just some annotations will break the code at all. I know that some operations could be problematic, but I talking here about simple tasks as renaming a class or field names. If you try to rename the field 'name' in the previous example, the resulting class will be even more broken. |
|
👤 lennyprimak 🕗 Oct 21, 2013 at 04:57 UTC I am hitting this bug as well. This makes NB 7.4 / lombok combination unusable. |
|
👤 [email protected] 🕗 Oct 21, 2013 at 14:59 UTC To me is also somewhat critical, albeit it can easily be remedied by using Nb 7.3 for the time being. |
|
👤 pangalz 🕗 Oct 21, 2013 at 15:12 UTC @ n.yovchev I don't think so. This regression also affects Nb 7.3 in the newest lombok version. |
|
👤 r.spilker 🕗 Oct 22, 2013 at 10:58 UTC Be assured: this has our attention. However, currently we are very busy, both personal and professional. Reinier and I do have fulltime jobs, and developing Lombok is in our spare time. We are also very busy preparing presentations about Lombok for a JUG in Germany and for Devoxx, so our time is very limited. But I might have a pointer for someone willing to chase this down. IIRC Petr Jiricka or Jan Lahoda submitted some patches in the early stages of lombok using some magic constant like -1 to signal to Netbeans that a certain node has been generated. Due to the change in the way we generate code, this information might have been lost, and possibly now we use approximate positions instead to improve error reporting. Also, we have some code, probably in the SynchronizedHandler and the SneakyThrowsHandler, to suppress the generation of code when the code generator is triggered from within Netbeans for editing purposes. I think we can/should combine this information to use the magic values for positions when then code is compiled inside Netbeans for editing purposes and the approximate positions when it is an actual compilation. Pull requests are highly appreciated since we ourselves don't have the time to work on this right now, and it is a real and important problem. |
lombokissues
added
the
accepted
|
👤 michel.graciano 🕗 Oct 22, 2013 at 11:15 UTC Thanks guys. I really appreciate your attention and sincerity. Lets see if someone here, maybe I can help too, have time to work on this. Thank you very much. |
|
👤 [email protected] 🕗 Oct 30, 2013 at 08:01 UTC I see it too. Thanks for any support. |
|
👤 lennyprimak 🕗 Nov 23, 2013 at 20:47 UTC Any progress on this? Anything I can do to help? |
|
👤 aguiar.marcio 🕗 Nov 24, 2013 at 02:08 UTC What about the javax.annotation.Generated annotation? I'll try to test this. |
|
👤 aguiar.marcio 🕗 Nov 24, 2013 at 03:22 UTC I'm narrowing this down. It seems that netbeans refactoring breaks whenever there is a combination of lombok annotations and a reference to itself in a class. For example, a constructor, instanceof statement (in the equals method), and so on. And that happens in all netbeans operations that generates code. Generate Equals and HashCode, Override Method, Generate To String... |
|
👤 aguiar.marcio 🕗 Nov 24, 2013 at 19:28 UTC Ok. Found the problematic line. Removed it and lombok works again on Netbeans < 7.4. Still have fixes to make it work on 7.4. Anyway, I created a pull request: #39 |
|
👤 [email protected] 🕗 Nov 28, 2013 at 01:25 UTC Hi what's the progress on getting this working in NetBeans 7.4? Just wondering if you have an ETA for it. |
|
👤 [email protected] 🕗 Nov 28, 2013 at 01:26 UTC Me too, would be really good to have it ready soon, Lombok is just great with nb |
|
👤 reinierz 🕗 Dec 03, 2013 at 20:29 UTC The pull requist from aguiar.marcio was a bit too simplistic, but it did show us the source of the issue. We've taken the concept and fixed things so that it should now work as well as it can on all platforms: IF on netbeans, then we don't set position. But if not, we do (and this is for example important otherwise errors occur when compiling with javac8). Also, setting the position gives nicer error reporting when compiling code with syntax errors near or on lombok generated code (can happen, if you for example instruct lombok to create a synchronized lock based on a field that doesn't exist). Best of both worlds... hopefully! Feel free to test away; we just uploaded an edge release with this fix, here: |
lombokissues
removed
the
accepted
|
👤 [email protected] 🕗 Dec 04, 2013 at 01:43 UTC I'm getting an error in NetBeans 7.4 after installing the latest snapshot (1.12.3): Annotation: An error occurred during parsing of 'C:\Development\Anahata\JobTracking\JobTracking-common\src\main\java\com\anahata\jobtracking\domain\model\quote\Quote.java'. Please report a bug against java/source and attach dump file 'C:\Users\Robert\AppData\Roaming\NetBeans\7.4\var\log\Quote_2.dump'. |
|
👤 [email protected] 🕗 Dec 04, 2013 at 01:43 UTC |
|
👤 [email protected] 🕗 Dec 04, 2013 at 02:06 UTC FYI further to this, my NetBeans 7.4 is now sometimes hanging when trying to save a Java file like the attached above. |
|
👤 lennyprimak 🕗 Dec 18, 2013 at 19:53 UTC What's the status on this? Can anybody confirm whether this fix works or not? |
|
👤 [email protected] 🕗 Dec 19, 2013 at 11:49 UTC No the fix does NOT work. Netbeans 7.4 hangs mostly (always) if I try to save a file with @ Getter and @ Setter. |
|
👤 [email protected] 🕗 Dec 19, 2013 at 12:48 UTC The attached file hangs Netbeans 7.4 on a save (everything is locked, I have to kill the Netbeans with the task manager) |
|
👤 [email protected] 🕗 Dec 19, 2013 at 12:48 UTC |
|
👤 lennyprimak 🕗 Dec 19, 2013 at 16:40 UTC Wow… What's unfortunate |
|
👤 r.spilker 🕗 Dec 19, 2013 at 22:12 UTC Status update: @ simtec, thanks for the good testcase. I can confirm the problem. We've been analysing the code for the past few hours but can't find the root cause. The fact that the NetBeans compiler code slightly differs from the available java8 source we have doesn't help. We did confirm that we correctly seem to detect the NetBeans IDE (and the other way around) and that we set the correct flags (well, we forgot two, but adding them didn't fix the problem). For now, we're out of energy and ideas... If someone else can help us find the cause: you're very welcome! |
lombokissues
added
the
accepted
|
👤 r.spilker 🕗 Dec 19, 2013 at 22:26 UTC To solve these kind of problems, we really need to run NetBeans in a debugger, preferably Eclipse. Can someone tell us how to set this up? Preferably using a standard NetBeans install and a select few jars or zip files for setting breakpoints and getting line-by-line source view in the debugger. Any help is appreciated! |
|
👤 lennyprimak 🕗 Dec 27, 2013 at 15:35 UTC Anybody have an "in" with the NetBeans team? Maybe this way we can get them to look at this or at least suggest a course of action. I have have contacts with an ex-member of NB team in the past, and I will send him an e-mail. |
|
👤 michel.graciano 🕗 Dec 27, 2013 at 15:48 UTC AFAIK the main javac developer at NB team is Jan Lahoda <jlahoda@ netbeans.org>. I think you can contact him and ask for some help on this. The NB repository for Javac changed is http://hg.netbeans.org/main/nb-javac/. I will contact some internal people to know if they can help on this. Thanks for your effort. |
|
👤 lennyprimak 🕗 Dec 27, 2013 at 15:54 UTC Thanks, Email sent to Jan also. |
|
👤 lennyprimak 🕗 Dec 27, 2013 at 20:26 UTC Amazingly enough (and fast!), I just got an email from Geertjan Wielenga <geertjan.wielenga@ oracle.com> |
|
👤 r.spilker 🕗 Jan 08, 2014 at 23:11 UTC Jan Lahoda supplied a patch/pull request. We just tested in against NetBeans IDE 7.4 (Build 201310111528) and is seems to work. We'll ship a new version soon, but you can already use the edge release: https://projectlombok.org/download-edge.html |
lombokissues
removed
the
accepted
|
👤 michel.graciano 🕗 Jan 09, 2014 at 00:31 UTC Thanks guys. I will test it tomorrow and post feedback soon. Thanks Jan about the patch too. |
|
👤 [email protected] 🕗 Jan 09, 2014 at 02:13 UTC Hi, I've been using the 1.12.3 edge version and it seems to be working a lot better, but I'm getting an error with enums. In NetBeans and also running a Maven build, it sometimes gets this error: COMPILATION ERROR :com/anahata/lomboktester/EnumTest.java:[11,29] error: cannot find symbol Enum looks like this: @ AllArgsConstructor(access = AccessLevel.PROTECTED) } The error comes and goes - in both the Maven build, also in the IDE highlighting files with error. I've attached a Maven project to reproduce this. |
|
👤 [email protected] 🕗 Jan 09, 2014 at 02:13 UTC |
|
👤 [email protected] 🕗 Jan 09, 2014 at 02:16 UTC Note the AccessLevel is normally PACKAGE for us, but setting it to anything (like public) produces the error. Removing access seems to work. |
|
👤 reinierz 🕗 Jan 15, 2014 at 20:45 UTC Thanks to Tumi (serverperformance on github), it got a little better. We'll spin off an official release tonight. This isn't quite done yet, but 1.12.4 should be a lot better. |
|
👤 reinierz 🕗 Jan 15, 2014 at 21:25 UTC Official release 1.12.4 has just been pushed for download and to maven central. It includes lots of fixes for netbeans. |
|
End of migration |
1. While working on SFTP connection pool I realized some old bug due to grep4j dependency on lombok-0.11.6 in Netbeans, some details available here - projectlombok/lombok#626 2. While updating lombok dependency I updated all of the dependency libraries to: - commons-io-2.4.jar - commons-lang-2.6.jar - commons-lang3-3.4.jar - commons-pool-1.6.jar - guava-19.0.rc2.jar - jsch-0.1.53.jar - jsr305-2.0.1.jar - new - lambdaj-2.3.3.jar - lombok-1.16.6.jar - cglib-nodep-2.2.jar - hamcrest-all-1.1.jar - objenesis-1.1.jar 3. I have found some bug relevant to Test cases especially done on Windows, so will update them, for now build with `mvn -Dmaven.test.skip=true install` for now. 4. Source code is now targeted to Java 1.7 version.
Migrated from Google Code (issue 591)
The text was updated successfully, but these errors were encountered: