val within a parameterized (generic) inner class causes a NullPointerException upon compilation #434
Comments
|
👤 [email protected] 🕗 Apr 11, 2012 at 21:01 UTC What steps will reproduce the problem?
What is the expected output? What do you see instead? error: Lombok visitor handler class lombok.javac.handlers.HandleVal failed: java.lang.NullPointerException What version of the product are you using? On what operating system? Please provide any additional information below. I'm not absolutely sure what the conditions are to produce the error, but when I use the concrete type instead of val, it works. Also, if the inner class does not involve a parameterized class, it seems to be fine, too (i.e. change the class to a Runnable instead of a Comparable). |
|
👤 [email protected] 🕗 Apr 11, 2012 at 21:01 UTC |
|
👤 [email protected] 🕗 Apr 11, 2012 at 21:03 UTC I meant 0.11.0, not 0.11.2. Sorry! Also, I used this with the 0.10.4 of the lombok-pg version. |
|
👤 r.spilker 🕗 Apr 11, 2012 at 23:21 UTC Hypothesis: When we encounter a 'val', we need to do something calling 'attr'ing the entire block that contains the val statement. This basically assigns types to each expression in it. In order to 'attr', javac needs to have a table with names in them; otherwise it wouldn't know what "new MyOwnClass();" meant. The problem is this: When annotation processors (and thus, lombok) are called by javac, javac has done the minimum necessary work to make the public API of annotation processors work. This involves creating the aforementioned symbol table (because you can ask for i.e. the method members of a type), but NOT the attr stuff (because that's for statements inside a method, and you can't get to statements with the public annotation API. Lombok actually can, but that's the hacky part of what lombok does). That's why we 'fake' attr by creating a copy of the method or initializer block and then calling attr on that. The problem is that we made the assumption that javac FULLY fills in the symbol table. Now we get to the actual hypothesis: Our hypothesis is that javac only fills in those symbols which it must to support the public annotations API. When you have a local class declaration (these come in 3 variants: An anonymous inner class on a field declaration, an anonymous inner class in a block, and a method local class), then there is NO WAY for a user of the public annotations api to get there, and thus javac decides NOT to create a symbol for the methods in such a class (and possibly not for the class itself either). This means the method that we end up wanting to 'attr' does not have a symbol. No symbol means 'attr' cannot work. In practice we could just start the 'attr' process from the deepest node that DOES have a symbol (which would be the field itself), but this doesn't work; maybe we can make that work but I somewhat doubt it. If we dig 'deeper', down to the compareTo method in the TestVal example, we've moved into territory that's invisible with the public annotation API, and therefore there are no symbols here, and therefore we can't attr here. We don't know of an easy solution to this dilemma. Presumably it'll be one of the following two strategies:
I have significantly more faith in option 2. Also, option 2 is effectively how it works now, but, when generics are on the anonymous inner class, this will fail. The fail condition should be easy to explain: ANY use of 'val' ANYWHERE in ANY local class, if the local class has generics, will fail with an NPE. NB: It is trivial to generate an error on the usage of 'val' with some sort of message saying that, unfortunately, we can't support val inside type parameterized local classes. |
lombokissues
added
accepted
|
👤 Eric6iese 🕗 Jun 01, 2012 at 14:50 UTC Hi, I ran into this issue in my ant build on a regular basis. I love using comparators, functions, predicates and that stuff from time to time... Solving the issue is easy after the second time, but it was real pain in the first build, and it had lessened my trust in the val feature. It's not that i restrain from using it now - far from it! However, i am concerned that other people who start to use val could get frustrated pretty fast by this, since there is no clue at all in the compiler output where the problem occured, and why. I would make a suggestion for this one: Is there a way for lombok to find out that it is in a hidden inner class? If so, could it just emit an error and tell the user that val does not work here, much like in traditional for-loops? That is a step back, but it might help until a real solution to this compiler dilemma is out. And this is really an edge case were I don't care if I can't use val for now. |
|
👤 amanic 🕗 Aug 29, 2012 at 03:14 UTC I just hit this with 0.11.4 |
|
👤 askoning 🕗 Oct 08, 2013 at 10:01 UTC Issue #578 has been merged into this issue. |
|
End of migration |
|
Reproduces on Lombok 1.16.14 Oracle javac 1.8.0_112 Apache Maven 3.3.9 |
|
Can this please be fixed? I'm still getting the exception using I don't know which piece of code causes it. Sometimes it goes through without the exception though which is odd. Why is this error non-deterministic as well? The |
|
Lombok Plugin on IntelliJ has an issue with members has comments /* */. When members have a comment, it cannot build. |
|
I am also getting this issue with lombok v1.18.12 |
|
Update I'm not even using an inner class. The piece of code is this:
Dependency: |
|
This may be very hard to fix and not worth fixing, given that instead we'd like to migrate |
|
@rzwitserloot I think I fixed this one in #2840, at least the stacktrace is similar |
Migrated from Google Code (issue 361)
The text was updated successfully, but these errors were encountered: