Delombok leaves some vals behind

[Adrian Cox]

I'm having trouble building one of my larger projects (590 source
files) in Maven, which I think may be Lombok related. There are
several angles to the problem. The project builds correctly in
Eclipse, but standalone Maven builds fail with the following message:

[ERROR] Failure executing javac, but could not parse the error:
55 errors

That's it - setting the compiler option to verbose doesn't reveal any
more detail. The behaviour is the same with either OpenJDK or Oracle
Java 6. Lombok might be the cause, but there's no evidence,

I attempted to delombok the project using the lombok-maven-plugin in
order to track down the problem, but the delombok'ed code still
contains a few instances of val. For instance,

public abstract class AbstractRepeatingViewPanel<T> extends Panel {
public AbstractRepeatingViewPanel(String id, IModel<List<T>>
model) {
super(id);
val rv = new RepeatingView("rview", model);
add(rv);

Other classes in the same package have had val replaced correctly.

I'm at a bit of a loss to work out how to fix this - are there
debugging methods I can use to trace Lombok's actions, and understand
why some instances of val are treated differently? The output
currently is:

[INFO] --- lombok-maven-plugin:0.10.6.0:delombok (default-cli) @ Heron-
Web ---
Only processing java files (not copying non-java files) in /home/
adrian/test/Project/Project-Web/src/main/lombok/.svn because it's a
hidden directory.
.... (more messages about .svn directories)
[INFO] Delombok complete.

[Reinier Zwitserloot]

Two suggestions:

(A) Try java 1.7. Maybe you ran into issue 285: http://code.google.com/p/projectlombok/issues/detail?id=285 - something which looks like it'll be very hard to fix for us, and which works fine in javacs shipping with JDK1.7.

(B) The fact that delombok still spits out val is extremely strange. val's behaviour when it runs into problems determine the type of the RHS is to just go with 'Object'. In fact, it always first sets its own type to object, then resolves the RHS, then turns 'Object' into the RHS's type assuming the RHS's type is concrete and not a 'weird' unrepresentable type like a joined type or an unbound type var. If any of those things happen, the val processor just calls it a day for that instance of 'val', thus leaving it as Object. I have absolutely no idea how 'val' could possibly stay there, especially if you get no exceptions or other errors from delombok.

Any chance you can distill this one down to a manageable test case and report it at http://code.google.com/p/projectlombok/issues?

[Adrian Cox]

On Jan 7, 12:54 pm, Reinier Zwitserloot <reini...@gmail.com> wrote:
> Two suggestions:
>
> (A) Try java 1.7. Maybe you ran into issue
> 285:http://code.google.com/p/projectlombok/issues/detail?id=285-
> something which looks like it'll be very hard to fix for us, and which
> works fine in javacs shipping with JDK1.7.

Java 1.7 gives me error text, rather than a mystery failure. The error
text corresponds to the vals which delombok was unable to remove. For
example:

[ERROR] /home/adrian/test/Project/src/main/java/uk/co/humboldt/Project/
Web/Reporting/ParameterisedReportSelector.java:[26,6] error: Cannot
use 'val' here because initializer expression does not have a
representable type: Type cannot be resolved

val reportmodel = new UnversionedJpaModel<Report,
Long>(Report.class,
null);


It seems that in certain files, every val fails. I don't know what
marks out these files as special - they compile inside Eclipse. Also,
the list of files that fail is not consistent from run to run. I've
just made three attempts to build, removing the target directory in
between. The first attempt had 34 errors, the second 43, and the third
39.

> Any chance you can distill this one down to a manageable test case and
> report it athttp://code.google.com/p/projectlombok/issues?

I may try later - this application has 625 source files in it, and
won't shrink down easily. I have several smaller projects using Lombok
that build without problems.

[Reinier Zwitserloot]

We had another theory which would explain why 'val' sticks around (instead of being replaced by Object), but if you're seeing different result across compile runs that definitely can't be it either - in an older version of lombok, any usage of 'val' in a catch block was not rewritten at all because catch is kind of a special beast - it's neither a statement nor an expression, and in our tree visitor we screwed this up. Our theory was that you stumbled on another such construct, but if that was the case, the failure should be consistent, and you shouldn't be getting any errors from lombok at all. This:

Cannot use 'val' here because initializer expression does not have a 
representable type: Type cannot be resolved

is generated by lombok.