NPE while compiling with javac

26 views
Skip to first unread message

latchkey

unread,
Aug 6, 2009, 6:39:10 PM8/6/09
to Project Lombok
Just using @Getter and @Setter with soylatte. Any ideas?


[69][ ~/checkout/foo ]% ant compile
Buildfile: build.xml

init:
[svn] info /Users/me/checkout/foo

biz-jar:
[javac] Compiling 41 source files to /Users/me/checkout/foo/target/
biz/classes
[javac]
[javac]
[javac] An annotation processor threw an uncaught exception.
[javac] Consult the following stack trace for details.
[javac] java.lang.NullPointerException
[javac] at lombok.javac.apt.Processor.toUnit(Processor.java:143)
[javac] at lombok.javac.apt.Processor.process(Processor.java:86)
[javac] at
com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor
(JavacProcessingEnvironment.java:624)
[javac] at
com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs
(JavacProcessingEnvironment.java:553)
[javac] at
com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing
(JavacProcessingEnvironment.java:698)
[javac] at
com.sun.tools.javac.main.JavaCompiler.processAnnotations
(JavaCompiler.java:981)
[javac] at com.sun.tools.javac.main.JavaCompiler.compile
(JavaCompiler.java:727)
[javac] at com.sun.tools.javac.main.Main.compile(Main.java:353)
[javac] at com.sun.tools.javac.main.Main.compile(Main.java:279)
[javac] at com.sun.tools.javac.main.Main.compile(Main.java:270)
[javac] at com.sun.tools.javac.Main.compile(Main.java:69)
[javac] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
[javac] at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
[javac] at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
[javac] at java.lang.reflect.Method.invoke(Method.java:597)
[javac] at org.apache.tools.ant.taskdefs.compilers.Javac13.execute
(Javac13.java:56)
[javac] at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:
997)
[javac] at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:
820)
[javac] at org.apache.tools.ant.UnknownElement.execute
(UnknownElement.java:288)
[javac] at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown
Source)
[javac] at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
[javac] at java.lang.reflect.Method.invoke(Method.java:597)
[javac] at org.apache.tools.ant.dispatch.DispatchUtils.execute
(DispatchUtils.java:105)
[javac] at org.apache.tools.ant.Task.perform(Task.java:348)
[javac] at org.apache.tools.ant.Target.execute(Target.java:357)
[javac] at org.apache.tools.ant.Target.performTasks(Target.java:
385)
[javac] at org.apache.tools.ant.Project.executeSortedTargets
(Project.java:1329)
[javac] at org.apache.tools.ant.Project.executeTarget
(Project.java:1298)
[javac] at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets
(DefaultExecutor.java:41)
[javac] at org.apache.tools.ant.Project.executeTargets
(Project.java:1181)
[javac] at org.apache.tools.ant.Main.runBuild(Main.java:698)
[javac] at org.apache.tools.ant.Main.startAnt(Main.java:199)
[javac] at org.apache.tools.ant.launch.Launcher.run(Launcher.java:
257)
[javac] at org.apache.tools.ant.launch.Launcher.main
(Launcher.java:104)

BUILD FAILED
/Users/me/checkout/foo/build.xml:91: Compile failed; see the compiler
error output for details.

Total time: 2 seconds
[70][ ~/checkout/foo ]% javac -version
javac 1.6.0_03-p3
[71][ ~/checkout/foo ]% java -version
java version "1.6.0_03-p3"
Java(TM) SE Runtime Environment (build 1.6.0_03-p3-
landonf_19_aug_2008_15_52-b00)
Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_03-p3-
landonf_19_aug_2008_15_52-b00, mixed mode)

Reinier Zwitserloot

unread,
Aug 6, 2009, 6:47:47 PM8/6/09
to Project Lombok
When I have an actual computer and not just a mobile phone again
(vacation) I'll have a look :) can you file a ticket with that
stacktrace and the source that triggered it? Thanks!

latchkey

unread,
Aug 6, 2009, 6:58:33 PM8/6/09
to Project Lombok
Darn. Happens with osx javac 1.6 too.

I just changed two of my classes over, so I'll try to isolate a
testcase.

jon

latchkey

unread,
Aug 6, 2009, 7:39:02 PM8/6/09
to Project Lombok
One more update. I removed all the @Getter/@Setter and the problem
still exists. Just having lombok.jar in the ant javac classpath causes
failures for me. Even tried fork="true". Another guy in the office on
a mac doesn't see this. Also, our hudson server (running ubuntu)
doesn't have this problem either.

jon

Reinier Zwitserloot

unread,
Aug 9, 2009, 9:25:47 AM8/9/09
to Project Lombok
I just compiled a test class with soylatte's javac and I did not run
into this problem.

Line 143 in Processor.java is this:

return (JCCompilationUnit) trees.getPath(element).getCompilationUnit
();

I'm guessing that 'trees' is null, which would happen if the compiler
you're using isn't a variant of javac. That's kind of a bug (it should
give you a sensible error message instead of a random NPE, and I fixed
this in trunk by generating a warning if this is detected).

Still, this is kind of weird, as soylatte's javac *IS* a javac v1.6
variant.

Jeff Schnitzer

unread,
Aug 12, 2009, 3:43:39 PM8/12/09
to Project Lombok
I have started to experience this exact same problem (same
stacktrace).

My Java version, on OSX 10.5:

java version "1.6.0_13"
Java(TM) SE Runtime Environment (build 1.6.0_13-b03-211)
Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02-83, mixed mode)

I'm running it from ant. I've compiled with lombok before, although
this might be the first clean build I've done since integrating it
into the project. One of the devs here is trying to build the lombok
master so I can try that out. BTW he mentions that the buildfile
seems slightly broken, you have to create a couple dirs by hand (lib/
lombok and deps/eclipse.agent).

Jeff

Jeff Schnitzer

unread,
Aug 12, 2009, 3:48:22 PM8/12/09
to Project Lombok
The latest jar ("lombok-0.8.3-HEAD.jar") produced the exact same
stacktrace and NPE.
(Javac.java:820)
[javac] at org.apache.tools.ant.UnknownElement.execute
(UnknownElement.java:288)
[javac] at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown
Source)
[javac] at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
[javac] at java.lang.reflect.Method.invoke(Method.java:597)
[javac] at org.apache.tools.ant.dispatch.DispatchUtils.execute
(DispatchUtils.java:105)
[javac] at org.apache.tools.ant.Task.perform(Task.java:348)
[javac] at org.apache.tools.ant.Target.execute(Target.java:
357)
[javac] at org.apache.tools.ant.Target.performTasks
(Target.java:385)
[javac] at org.apache.tools.ant.Project.executeSortedTargets
(Project.java:1329)
[javac] at org.apache.tools.ant.Project.executeTarget
(Project.java:1298)
[javac] at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets
(DefaultExecutor.java:41)
[javac] at org.apache.tools.ant.Project.executeTargets
(Project.java:1181)
[javac] at org.apache.tools.ant.Main.runBuild(Main.java:698)
[javac] at org.apache.tools.ant.Main.startAnt(Main.java:199)
[javac] at org.apache.tools.ant.launch.Launcher.run
(Launcher.java:257)
[javac] at org.apache.tools.ant.launch.Launcher.main
(Launcher.java:104)



On Aug 12, 12:43 pm, Jeff Schnitzer <jeff-goo...@infohazard.org>
wrote:

Reinier Zwitserloot

unread,
Aug 12, 2009, 4:20:17 PM8/12/09
to Project Lombok
Hey Jeff,

sorry, I just noticed I forgot to push that change up to github. Can
you git pull and try it again, see if you get that warning I added?

If not, just for my own sanity, can you split up that oneliner in
toUnit, and see if it's trees that's null, or the result of
trees.getPath(element)? One of them would have to be null for this
exception to occur.

On Aug 12, 9:48 pm, Jeff Schnitzer <jeff-goo...@infohazard.org> wrote:
> The latest jar ("lombok-0.8.3-HEAD.jar") produced the exact same
> stacktrace and NPE.
>
>     [javac] An annotation processor threw an uncaught exception.
>     [javac] Consult the following stack trace for details.
>     [javac] java.lang.NullPointerException
>     [javac]     at lombok.javac.apt.Processor.toUnit(Processor.java:
> 143)
>     [javac]     at lombok.javac.apt.Processor.process(Processor.java:
> 86)
>     [javac]     at
> com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor
> (JavacProcessingEnvironment.java:624)
>     [javac]     at
> ...
>
> read more »

Jeff Schnitzer

unread,
Aug 12, 2009, 4:34:45 PM8/12/09
to Project Lombok
Ok, got the updated version and split the lines. There was no
warning, and the result of trees.getPath(element) is null.

Jeff
> ...
>
> read more »

Reinier Zwitserloot

unread,
Aug 12, 2009, 5:23:46 PM8/12/09
to Project Lombok
Okay. Huh. I wasn't expecting getPath() to EVER return null. Can you
pull and retry once more? I can't reproduce this bug. It should print
some diagnostic messages that should help me figure this out. Thanks,
Jeff!

On Aug 12, 10:34 pm, Jeff Schnitzer <jeff-goo...@infohazard.org>
> ...
>
> read more »

Jeff Schnitzer

unread,
Aug 12, 2009, 5:39:53 PM8/12/09
to Project Lombok
This produces the following warning:

[javac] warning: LOMBOK DIAGNOSTIC: no TreePath returned for
element of type: class com.sun.tools.javac.code.Symbol
$PackageSymbolwith toString: com.similarity.entity

...and doesn't produce an NPE. com.similarity.entity is a package
that contains a couple entity classes that use the @Getter, @Setter,
and @ToString annotations.

If you want, email me an IM contact (any service is fine) and we can
iterate faster. I should be around for another hour.

Jeff
> ...
>
> read more »

Reinier Zwitserloot

unread,
Aug 12, 2009, 6:29:45 PM8/12/09
to Project Lombok
No, it doesn't throw NPEs because I coded in a potential fix. Does
lombok seem to work normally now? If so, it's probably an errant
symbol which has no further impact on compilation, and therefore the
current fix I guessed at is the right one. The fix is: If a given
Element does not have an JCCompilationUnit associated with it, then
just ignore it, vs the old action, which was: Throw an NPE and give
up. In fact, I'm 99% sure this (ignoring elements with no
JCCompilationUnit) is the right thing to do.

If, other than a bunch of diagnostics warnings, everything seems to
work for you, I'll take out the diagnostic warnings and leave the fix
in. I'll then roll out 0.8.3, I think its time to push some of these
fixes through.

The other project lead (Roel) is on vacation and I'm knee-deep in work
related stuff, hence the current slow going. Should change in 2 weeks.
Thanks for your patience and testing my flailing attempts at figuring
out why this is happening :)

On Aug 12, 11:39 pm, Jeff Schnitzer <jeff-goo...@infohazard.org>
> ...
>
> read more »

latchkey

unread,
Aug 14, 2009, 3:57:44 PM8/14/09
to Project Lombok
No more NPE. Now I just see this when I added a @Getter to a single
field in a class with the latest trunk...

[javac] warning: LOMBOK DIAGNOSTIC: no TreePath returned for
element of type: class com.sun.tools.javac.code.Symbol
$PackageSymbolwith toString: [my.package.path]

Using the apple jdk:

java version "1.6.0_13"
Java(TM) SE Runtime Environment (build 1.6.0_13-b03-211)
Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02-83, mixed mode)

jon
> ...
>
> read more »

latchkey

unread,
Aug 14, 2009, 4:07:51 PM8/14/09
to Project Lombok
Here is another hint. If I make a change to the class (ie: add another
@Getter to another field) and then I re-run my ant compile target
(which doesn't delete the class file first), it doesn't output that
warning. So, it must be something that only happens on the first
compile of the .class file.

jon
> ...
>
> read more »

Reinier Zwitserloot

unread,
Aug 14, 2009, 5:26:57 PM8/14/09
to Project Lombok
That helps a lot. I think I know why that's happening now, and the
current action is indeed the proper way to fix it. diagnostic messages
have been removed.
> ...
>
> read more »

Jeff Schnitzer

unread,
Aug 17, 2009, 8:00:47 PM8/17/09
to Project Lombok
The latest version seems to be working as advertised.

Btw, I suspect the problem had to do with having a package-info.java
file in the package containing hibernate entities. Unless something
changed since I worked at the same company, Jon/latchkey's project has
one too with very similar contents:

-----
@org.hibernate.annotations.TypeDefs({
@org.hibernate.annotations.TypeDef(
name="anyImmutable",

typeClass=com.similarity.entity.util.AnyImmutableType.class
)
})

package com.similarity.entity;
-----

Jeff
> ...
>
> read more »

Reinier Zwitserloot

unread,
Aug 17, 2009, 9:14:37 PM8/17/09
to Project Lombok
YES! That explains everything. Such a file is a compilation unit that
isn't really a compilation unit. Explains everything. Thanks, Jeff!
> ...
>
> read more »
Reply all
Reply to author
Forward
0 new messages