Lombok 1.12.2 has some regressions with NetBeans #626

Closed
lombokissues opened this Issue Jul 14, 2015 · 42 comments

Projects

None yet

1 participant

@lombokissues
Collaborator

Migrated from Google Code (issue 591)

@lombokissues
Collaborator

👤 michel.graciano   🕗 Oct 11, 2013 at 13:38 UTC

Hi guys,
I have found a issue when using Lombok 1.12.2 (I found it using the edge version) and NetBeans. I can reproduce it with NetBeans 7.3.1 and 7.4. It does not happens for previous Lombok version.

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

@lombokissues
Collaborator

👤 michel.graciano   🕗 Oct 16, 2013 at 14:36 UTC

Guys,
NetBeans has answered this and they will not fix it because it is considered a Lombok issue. You can see comments at issue https://netbeans.org/bugzilla/show_bug.cgi?id=236885 and https://netbeans.org/bugzilla/show_bug.cgi?id=237156. I agree with them mainly because there is no standard way to do the magic you do. There is any chance to you to consider the comments the developers did? Maybe some flag at generated source? I hope you can address it asap, or we will need to do not use Lombok in our project.

@lombokissues
Collaborator

👤 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

@lombokissues
Collaborator

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

@lombokissues
Collaborator

👤 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?

@lombokissues
Collaborator

👤 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;
import lombok.experimental.Wither;

@ NoArgsConstructor(access = AccessLevel.PRIVATE)
@ AllArgsConstructor(access = AccessLevel.PRIVATE)
@ Builder
@ Wither
@ Getter
public class Bean {

private Long id;
private String name;
private BigDecimal value;

}

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;
import lombok.experimental.Wither;

@ NoArgsConstructor(access = AccessLevel.PRIVATE)
@ AllArgsConstructor(access = AccessLevel.PRIVATE)
@ Builder
@ Wither
@ Getter
public class Bean1 {

private Long id;
private String name;
private BigDecimal value;Bean1rgsConstructor(access = AccessLevel.PRIVATE)

Bean1
Bean1 BBean1;
BBean1e;
}

B

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

@lombokissues
Collaborator

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

@lombokissues
Collaborator

👤 lennyprimak   🕗 Oct 21, 2013 at 04:57 UTC

I am hitting this bug as well. This makes NB 7.4 / lombok combination unusable.
I consider this a critical issue.

@lombokissues
Collaborator

👤 n.yovchev@synovite.nl   🕗 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.

@lombokissues
Collaborator

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

@lombokissues
Collaborator

👤 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
Collaborator

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

@lombokissues
Collaborator

👤 fabrizio.giudici@tidalwave.it   🕗 Oct 30, 2013 at 08:01 UTC

I see it too. Thanks for any support.

@lombokissues
Collaborator

👤 lennyprimak   🕗 Nov 23, 2013 at 20:47 UTC

Any progress on this? Anything I can do to help?
Thanks

@lombokissues
Collaborator

👤 aguiar.marcio   🕗 Nov 24, 2013 at 02:08 UTC

What about the javax.annotation.Generated annotation? I'll try to test this.

@lombokissues
Collaborator

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

@lombokissues
Collaborator

👤 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

@lombokissues
Collaborator

👤 robert@anahata-it.com.au   🕗 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.

@lombokissues
Collaborator

👤 pablo@anahata-it.com.au   🕗 Nov 28, 2013 at 01:26 UTC

Me too, would be really good to have it ready soon, Lombok is just great with nb

@lombokissues
Collaborator

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

https://projectlombok.org/download-edge.html

@lombokissues lombokissues removed the accepted label Jul 14, 2015
@lombokissues
Collaborator

👤 robert@anahata-it.com.au   🕗 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'.
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'.
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'.
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'.
Caused: java.lang.AssertionError
at com.sun.tools.javac.util.Assert.error(Assert.java:126)
at com.sun.tools.javac.util.Assert.check(Assert.java:45)
at com.sun.tools.javac.util.Bits.incl(Bits.java:205)
at com.sun.tools.javac.comp.Flow$AssignAnalyzer.visitMethodDef(Flow.java:1739)
at com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:778)
at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
at com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:402)
at com.sun.tools.javac.comp.Flow$AssignAnalyzer.visitClassDef(Flow.java:1704)
at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:692)
at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
at com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:402)
at com.sun.tools.javac.comp.Flow$AssignAnalyzer.analyzeTree(Flow.java:2328)
at com.sun.tools.javac.comp.Flow$AssignAnalyzer.analyzeTree(Flow.java:2309)
at com.sun.tools.javac.comp.Flow.analyzeTree(Flow.java:215)
at com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1362)
at com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1326)
at com.sun.tools.javac.api.JavacTaskImpl.analyze(JavacTaskImpl.java:469)
at com.sun.tools.javac.api.JavacTaskImpl.analyze(JavacTaskImpl.java:448)
at org.netbeans.modules.java.source.parsing.JavacParser.moveToPhase(JavacParser.java:664)
at org.netbeans.modules.java.source.parsing.JavacParser.getResult(JavacParser.java:521)
at org.netbeans.modules.java.source.parsing.JavacParser.getResult(JavacParser.java:174)
at org.netbeans.modules.parsing.impl.TaskProcessor.callGetResult(TaskProcessor.java:615)
at org.netbeans.modules.parsing.impl.SourceCache.getResult(SourceCache.java:247)
[catch] at org.netbeans.modules.parsing.impl.TaskProcessor$CompilationJob.run(TaskProcessor.java:727)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1432)
at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2042)

@lombokissues
Collaborator

👤 robert@anahata-it.com.au   🕗 Dec 04, 2013 at 01:43 UTC

🔗 Quote_2.dump

@lombokissues
Collaborator

👤 robert@anahata-it.com.au   🕗 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.

@lombokissues
Collaborator

👤 lennyprimak   🕗 Dec 18, 2013 at 19:53 UTC

What's the status on this? Can anybody confirm whether this fix works or not?
Or is it time to release 1.12.3?
Thanks

@lombokissues
Collaborator

👤 simtec@bluewin.ch   🕗 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.
Thanks for any help!!!

@lombokissues
Collaborator

👤 simtec@bluewin.ch   🕗 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)

@lombokissues
Collaborator

👤 simtec@bluewin.ch   🕗 Dec 19, 2013 at 12:48 UTC

🔗 Test.dump

@lombokissues
Collaborator

👤 lennyprimak   🕗 Dec 19, 2013 at 16:40 UTC

Wow… What's unfortunate

@lombokissues
Collaborator

👤 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 lombokissues reopened this Jul 14, 2015
@lombokissues
Collaborator

👤 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!

@lombokissues
Collaborator

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

@lombokissues
Collaborator

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

@lombokissues
Collaborator

👤 lennyprimak   🕗 Dec 27, 2013 at 15:54 UTC

Thanks, Email sent to Jan also.

@lombokissues
Collaborator

👤 lennyprimak   🕗 Dec 27, 2013 at 20:26 UTC

Amazingly enough (and fast!), I just got an email from Geertjan Wielenga <geertjan.wielenga@ oracle.com>
who is the Product Manager for NetBeans, and he is willing to help / facilitate this.
Please E-mail him with the details. He knows about this issue now.

@lombokissues
Collaborator

👤 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 lombokissues removed the accepted label Jul 14, 2015
@lombokissues
Collaborator

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

@lombokissues
Collaborator

👤 robert@anahata-it.com.au   🕗 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
com/anahata/lomboktester/EnumTest.java:[11,40] error: an enum annotation value must be an enum constant

Enum looks like this:

@ AllArgsConstructor(access = AccessLevel.PROTECTED)
@ Getter
public enum EnumTest {
FIRST("First"),
SECOND("Second");

private final String displayValue;

}

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.

@lombokissues
Collaborator

👤 robert@anahata-it.com.au   🕗 Jan 09, 2014 at 02:13 UTC

🔗 LombokTester.zip

@lombokissues
Collaborator

👤 robert@anahata-it.com.au   🕗 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.

@lombokissues
Collaborator

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

@lombokissues
Collaborator

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

@lombokissues
Collaborator

End of migration

@archenroot archenroot added a commit to archenroot/grep4j that referenced this issue Oct 19, 2015
@archenroot archenroot Revised original 2 years old version by lanwen, set of current changes:
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 - rzwitserloot/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.
bd89814
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment