peichhorn / lombok-pg Goto Github PK

I guess this is low priority, since most of the time one does not write generic EventListener.
I happened to write some generic views lately along with the corresponding EventListener.class which also was generic.

example:

public interface MyEventListener<E, R> {
   public void somethingHappened(E someInfo, R someOtherStuff);
}

I'm getting some strange error messages when trying to implement the following snippet:

public static <T> Iterable<T> skip(@NotNull final Iterable<T> values, final int count)
{
    int i = 0;
    for(T item : values)
    {
        if(i++ < count)
            continue;

        yield(item);
    }
}

I'm not sure if I'm using this correctly, but

@Data
@BoundPropertySupport
@BoundSetter
public class Animal {
  private String name;
}

doesn't cause and property change events to fire, however

@Data
@BoundPropertySupport
public class Animal {
@BoundSetter
  private String name;
}

does cause property change events. I'm using lombok-pg-0.10.1-EDGE.jar.

When using the @Validate annotation and some other one beneath it, the one beneath it is not recognised when fixing imports. Example:

  @Validate
  @SneakyThrows
  public void test(@NotNull final String name) {
      System.out.println("Hi "+name);
  }

Workaround:

  @SneakyThrows
  @Validate
  public void test(@NotNull final String name) {
      System.out.println("Hi "+name);
  }

Fixing import works, I guess due to @SneakyThrows is above and as such not within the @Validate annotation scope... This has echoes of the @function auto-import bug #21

I'm not sure if this has already been asked before (I suspect yes), but will put it out there anyway. It would be nice to say in one go that a field is a property:

@getter
@Setter
private String name;

vs

@Property
private String name;

Note: I mean it with a capital, for some reason the at symbol mangles the text (github markup?)

The val keyword does not work with static final field declarations, it's not a big deal but would be nice to have ;)

Could the @DaTa(callSuper=true) also call the superconstructor?
@DaTa generates, I believe, an all args constructor, so it would be natural to do so for the subclass, calling the super constructor too in the beginning of the newer constructor, I should think.

Example:

@DaTa
class A {
private final String a;
}

class B {
private final String b;
}

// we should be able to do
A a = new A(a);
B b =new B(a, b);

Which means B() called A(a) then set: this.b = b;

You have mentioned this beforehand and I also got interest for this from another dev. team for this, so I'm creating an issue for it.

I'm getting incorrect (missing) values when using a yielder as such:

/**
 * Returns all values
*/
public Iterable<V> values()
{
  for (T key : map.keySet())
  {
    Map<K, V> subMap = map.get(key);
    for (K subkey : subMap.keySet())
    {
      V value = subMap.get(subkey);
      yield(value);
    }
  }
}

This is of a MultiMap<T, K, V> class, can provide more concrete code if necessary. Have a look what's going on when you have some time because this works OK if I put these in a list and return them rather than yield. Maybe nested fors are a bit buggy?

And here is why:
http://www.nesterovsky-bros.com/weblog/2011/01/27/WhyYieldIteratorShouldBeCloseable.aspx

Thx to Vladimir Nesterovsky for pointing me to the blog post.

I have another suggestion, how about a "retry" construct, only callable from a catch block, which would allow a try block to be repeated, as you may have provided some kind of solution within the catch block. Perhaps an overload with the number of retries would also be beneficial, when e.g. attempting to do some networking task, such as connecting to a database.

The implementation could be done using a goto jump in bytecode, or if you're attempting a set number of times, perhaps a for loop would be more appropriate...

In many instances when dealing with class inheritance, there is boilerplate in lombok annotations, because the @DaTa annotation cannot be used. The reason for this is that it does not allow for equals, hashcode and toString to specify whether to call super implementations of these methods or not. So end users have to use @DaTa in a superclass, then for any subclasses they have to use @EqualsAndHashCode and @tostring, with appropriate callSuper=T/F configuration.

It would be nice to be able in one go to say whether super should be called or not e.g. @DaTa(callSuper=true). This would create the relevant equals, hashcode and toString with this property set to the appropriate boolean value.

I don't think there is a need for super-fine-grained control here, e.g. callSuperEquals and callSuperToString, because the subclass would typically behave uniformly in this respect.

Yield generates a field for caught exceptions that could potentially be annotated with @SupressWarning("unused") to prevent eclipse to emit a warning about its lack of use:

Warning: The value of the field $YielderOfType.cce is not used

Code:

public static <TSource, TDest> Iterable<TDest> ofType(final Iterable<TSource> values, final Class<TDest> destinationClass)
{
    for(TSource item : values)
    {
      TDest temp = null;
        try
        {
            temp = destinationClass.cast(item);
        }
        catch(ClassCastException cce)
        {
        }

      yield(temp);
    }
}

A nice to have: Ability to have @DaTa configurable somehow so null is not accept as argument in the generated @requiredargsconstructor. So a way to combine @NotNull with @DaTa is what I'm basically asking, as this is a fairly common use-case, which at the moment necessitates the explicit creation of a constructor, despite using @DaTa...

Now that we have @Action and @Function why not add Predicate.
Since this is a no-brainer, maybe cleaning up the code base of HandleFunction and HandleAction is a good way to start.

Using similar functional goodness along the lines of @function, one can envisage a construct which allows for matching to be made easier in Java. For example instead of having messy if-then-else branches nesting deeply and becoming unreadable, you could have something leveraging some construct like 'switch' (or its syntax), like this:

match(code) {
case success(): return "Success";
case notFound(): return "Page not found";
default: return "Unknown";
}

Matchers could simply be defined as such:

@function
private boolean success(int code) {
return code==200;
}

@function
private boolean notFound(int code) {
return code==404;
}

What do you think?

I'd like to use @Builder. Would be nice to use it on generic types if even possible.

import lombok.Builder;

@Builder()
 public class ViewHolder<E> {
    private final List<E> list;
}

Since yield iterators are Closeable now, it only makes sense to use @cleanup with them, simple example:

@Cleanup final Iterable<String> lines = Lines.in(file); // implemented with yield, closes Stream if exception occurs
for (String line : lines) {
  // something
}

For now this wouldn't work since Iterable itself has no "close" method, but what if we spice up the generated code. If the cleanup method name is "close" and the type of the annotated local declaration has not method "close", add this logic:

if (lines instanceof Closeable) {
  ((Closeable)lines).close();
}

1. Once a method is used, chaining further methods (in a fluent API style) does not give you code completion.
   You can continue chaining things, but you need to remember the API to do e.g:

names.map(toUpperCase()).filter(isNotNullOrEmpty()).etc.etc.

2. Would it be possible to have the compiler warn you when you're forgetting to pass arguments to methods? e.g:
   names.filter(); // compiles but throws verifyError at runtime, because filter expects a function argument

Thankfully when you chain more than one call forgetting parameters:
names.map().filter(); // does not compile

It says:
Internal compiler error: java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.ast.MessageSend.analyseCode(MessageSend.java:60)

I think the @action annotation does not correctly generate Action0 actions:

Action0 action = doNothing() // compilation error

@action
public static void doNothing() {
}

This works with Functions and at the moment the workaround is to re-write the method as such:

public static Action0 doNothing()
{
   return new Action0()
   {

      @OverRide
      public void apply()
      {
      }
   };
}

I don't know if you have noticed before, but the SUPER-useful annotation @SneakyThrows, affects the coloration of the Eclipse code editor in the code immediately after it. Somehow, eclipse believes that portions of the file are what seems to be text (instead of code). I have uploaded a screenshot... here: http://i54.tinypic.com/2ivbkzk.png

The right colors can be seen near the end of the code in the screenshot.

Using @Validate and @function on a method gives you a compiler warning: duplicate @SuppressWarnings annotation. Hopefully they can be made to detect when this annotation has already been emitted and avoid doing so in this case.

Not sure how feasible this would be, but many times a final class needs to mocked. So what do you do? You can remove the final keyword (which breaks your design), you can create an interface and use that (which is more work and proliferates class count) or you can either use something like PowerMock to re-write the classes for you (which forces you to migrate your tests if you're using something else). So I wonder if it would be possible to annotate a class with @Final and that would disallow everyone to subclass it, except e.g. Mockito classes. You could pass the allowed package e.g. "Mockito.class.getPackage()" or even specify a string e.g. "org.mockito.*" so that it is not hardcoded to work with a single framework.

In your experience, how hard would it be to create a method annotation that wraps said method within a specific anonymous class?

I am using a LINQ re-implementation for Java (that I wrote, link: https://github.com/nicholas22/jpropel/blob/master/src/propel/core/utils/Linq.java#L2519) and I think this would make the use of most things like selectors and filters much more concise.

So this annotation would hide the annotated method (e.g. rename it, perhaps with synthetic semantics) and replace it with another method that creates an anonymous class, let's call it for example FunctionWithOneArgument<TResult, T> where type parameter TResult is the function result and T is the argument.

That would allow one to use:
Linq.select(people, nameSelector)

...if given the following function...
@FunctionWithOneArgument
String nameSelector(Person person) { return person.getName(); }

...instead of e.g.
Linq.select(people, new FunctionWithOneArgument<String, Person>() {
String operateOn(Person person) {
return person.getName();
}
});

This is because it would wrap the anonymous class creation in a method within the code. Currently this has to be done manually for any code that accepts a "function", but this process could be automated, plus there would be no need for all this boilerplate.

If this would be possible I could then re-write portions of the LINQ library with support for this and in combination to your extension method annotation and yield operator this would bring a lot of the functional programming stuff of .NET to Java, much before Java 8...

I'm running a continuous integration server which is Ant-based and the javac compiler does not work with @ExtensionMethod. How difficult would it be to port the ecj implementation to javac for this particularly cool annotation?

Formatting the source code as part of saving in eclipse (SaveAction) seems not to be working anymore, if lombok did his magic in a class. Organizing the imports still works btw and also, manually formatting(ctrl+f) works as well.

the following sample does not formatting anyhting on saving

import lombok.AllArgsConstructor;

@AllArgsConstructor
public class NoEclipseAutoFormatting {
    private void test() {
        int x     =        1   +   2  ;//i just pressed ctrl+s
    }
}

.. without lombok in a similar class ..

public class NoLombokAndFormattingWorks {
    private void test() {
        int x = 1 + 2;//i just pressave ctrl+s
    }
}

Using @Validate and @NotNull in e.g. a single arg constructor. If the constructor has to call super (in its first line of code of course) there is a problem with javac/Ant due to first call not being to super constructor! This is not a problem with eclipse though. My suggestion (which is not ideal) is that for javac a check could be made to emit the code after the call to the super constructor.

For now it is not possible to throw checked Exceptions inside a method annotated with @Function.
The known workaround for this issue is the usage of @SneakyThrows.

One way to support checked Exceptions would be to copy list of thrown Exceptions to the 'apply' method.
But for this to work we need to change the interface signature like this:
public R apply(T1 t1, T2 t2, ..., TN tn) throws Exception;
with the issue now being that I have to handle the Exception everywhere I use 'apply'.

So how to deal with checked exceptions?

Hi Philipp, the latest edge release causes an auto-completion error (observed on a static method call on a class not imported yet). This does not appear to be happening for instance methods. Reverting to Friday's release for now.

!MESSAGE java.lang.NullPointerException
!STACK 0
java.lang.NullPointerException
at org.eclipse.jdt.internal.compiler.parser.Parser.getMethodBodies(Parser.java:8689)
at lombok.eclipse.agent.Patches.completeNode(Patches.java:115)
at lombok.eclipse.agent.PatchFunction.onClassScope_buildFieldsAndMethods(PatchFunction.java:59)
at org.eclipse.jdt.internal.compiler.lookup.ClassScope.buildFieldsAndMethods(ClassScope.java)
at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.buildFieldsAndMethods(CompilationUnitScope.java:64)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:208)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:233)
at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.accept(CompilationUnitProblemFinder.java:121)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:150)
at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:183)
at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:487)
at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleImport(CompilationUnitScope.java:541)
at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInImports(CompilationUnitScope.java:369)
at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInTypes(CompilationUnitScope.java:466)
at org.eclipse.jdt.internal.compiler.Compiler.resolve(Compiler.java:906)
at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:194)
at org.eclipse.jdt.internal.core.CompilationUnit.buildStructure(CompilationUnit.java:195)
at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:258)
at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:518)
at org.eclipse.jdt.internal.core.CompilationUnit.makeConsistent(CompilationUnit.java:1079)
at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.makeConsistent(ReconcileWorkingCopyOperation.java:170)
at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.executeOperation(ReconcileWorkingCopyOperation.java:89)
at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:788)
at org.eclipse.jdt.internal.core.CompilationUnit.reconcile(CompilationUnit.java:1244)
at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:126)
at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.access$0(JavaReconcilingStrategy.java:108)
at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy$1.run(JavaReconcilingStrategy.java:89)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:87)
at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:151)
at org.eclipse.jdt.internal.ui.text.CompositeReconcilingStrategy.reconcile(CompositeReconcilingStrategy.java:86)
at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconcile(JavaCompositeReconcilingStrategy.java:104)
at org.eclipse.jface.text.reconciler.MonoReconciler.process(MonoReconciler.java:77)
at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:206)

For now this does not work, which is pretty sad:

@ExtensionMethod(Objects.class)
class Test {
  void test() {
    String s = getFoo().orElse("anotherValue");
  }
}

class Objects {
  public static <T> T orElse(T value, T orElse) {
    return value == null ? orElse : value;
  }
}

I'm trying to use @VisibleForTesting, so I annotate a private/internal method with it, but do not get public access to it. Surely I must be doing something wrong because I'm not sure how to use it properly. Many thanks!

When using multiple classes with @ExtensionMethod, the time taken for Ecilpse auto-completion to appear is increasing in what seems to be exponential rate. Could you have a look if there is any bottleneck which causes this?

It would follow that as you add more classes, the time taken for the auto-completion list to populate would increase linearly. But this is definitely not the case... With basically 3 classes (~200 methods) used with @ExtensionMethod, the auto-completion becomes unusable, where-as removing 1 seems to improve performance quite a bit, hence the conclusion made above...

Project lombok recently upgraded to a 0.10.2 release, fixing some (and few IIRC) issues on it way. It would be nice to have lombok-pg synchronised to that new release.

Thanks for such a great library BTW!!

Hi there!

I have been using the vanilla lombok project with much success and when stumbled upon this I immediately decided to test it out, as it has further facilities. Unfortunately, if I replace the lombok.jar in my project and Eclipse home with your jar, I lose Eclipse auto-completion.

I get the following popup:
Problems during Content Assist
The 'org.eclipse.jdt.ui.JavaAllCompletionProposalComputer' proposal computer from the 'org.eclipse.jdt.ui' plugi-in did not complete normally. The extension has thrown an exception.

The eclipse log contains the following:
!ENTRY org.eclipse.jdt.ui 2 0 2011-09-07 11:11:02.863
!MESSAGE The 'org.eclipse.jdt.ui.JavaAllCompletionProposalComputer' proposal computer from the 'org.eclipse.jdt.ui' plug-in did not complete normally. The extension has thrown a runtime exception.
!STACK 0
java.lang.NullPointerException
at lombok.eclipse.agent.PatchExtensionMethod.getClassScope(PatchExtensionMethod.java:260)
at lombok.eclipse.agent.PatchExtensionMethod.getExtensionMethods(PatchExtensionMethod.java:181)
at lombok.eclipse.agent.PatchExtensionMethod.getJavaCompletionProposals(PatchExtensionMethod.java:169)
at org.eclipse.jdt.ui.text.java.CompletionProposalCollector.getJavaCompletionProposals(CompletionProposalCollector.java:342)
at org.eclipse.jdt.internal.ui.text.java.JavaCompletionProposalComputer.internalComputeCompletionProposals(JavaCompletionProposalComputer.java:257)
at org.eclipse.jdt.internal.ui.text.java.JavaCompletionProposalComputer.computeCompletionProposals(JavaCompletionProposalComputer.java:206)
at org.eclipse.jdt.internal.ui.text.java.JavaTypeCompletionProposalComputer.computeCompletionProposals(JavaTypeCompletionProposalComputer.java:61)
at org.eclipse.jdt.internal.ui.text.java.CompletionProposalComputerDescriptor.computeCompletionProposals(CompletionProposalComputerDescriptor.java:318)
at org.eclipse.jdt.internal.ui.text.java.CompletionProposalCategory.computeCompletionProposals(CompletionProposalCategory.java:267)
at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.collectProposals(ContentAssistProcessor.java:283)
at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.computeCompletionProposals(ContentAssistProcessor.java:243)
at org.eclipse.jface.text.contentassist.ContentAssistant.computeCompletionProposals(ContentAssistant.java:1830)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeProposals(CompletionProposalPopup.java:556)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup.access$16(CompletionProposalPopup.java:553)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup$2.run(CompletionProposalPopup.java:488)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup.showProposals(CompletionProposalPopup.java:482)
at org.eclipse.jface.text.contentassist.ContentAssistant$2.run(ContentAssistant.java:377)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4140)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3757)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2696)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2660)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2494)
at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:674)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:667)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
at org.eclipse.equinox.launcher.Main.run(Main.java:1410)

Hopefully this will help you fix this issue.

Something along the lines of functional programming, @Runnable would be a nice addition to avoid anonymous inner classes being sprinkled all over the place for small tasks that do not require a dedicated class. Example:

 @Runnable
 public void performMyCoolTask() {
 // do stuff here
 }

Then it would be nice to be able to do:

 Executors.newSingleThreadExecutor().execute(performMyCoolTask());

This would probably be quite easy given your knowledge of @function ;)

I'm getting a minor bug, when a type is unused in a file and you use it within a @function block, the Eclipse IDE Ctrl-Shift-O (auto-import) does not discover it. In fact, if you have imported it and do auto-import as above, it is actually removed from imports!!! Workaround at the moment is to not use Ctrl+Shift+O... Idea: have a look at how @SneakyThrows does it (you mentioned some fixed position info...)

This is similar to the @SneakyThrows coloration issue #7 but for @function. It would be quite nice to somehow correct this is possible, as the code effectively becomes similar (but thankfully not identical) to when you open a text file in eclipse (colors are lost).

As the val keyword is now implemented, how hard would it be to implement a var keyword, which does not mark the field as final? This would bring parity to Scala's operators val and var.

Update the documentation and commit it in the gh-pages branch

Anonymous classes cannot be annotated with Java annotations. This prevents extension methods from being used in anonymous classes, because annotating the 'parent' with @ExtensionMethod does not do the trick. Is there a way around this? Thanks.

With all this auto-construction goodness, many times you want to initialise a field that depends on a field that is not yet initialised. For example:

 @RequiredArgsConstructor
 public final class SimpleProperty
 {
   private final String typeName;
   private final String propertyName;

   @LazyField
   private String name = typeName+"."+propertyName;
 }

A construct as the above would allow for this kind of post-construction processing, as at the moment this obviously is not possible. I think Getter(lazy=true) may be doing something like this on a property level...

Error
Wed Oct 12 20:16:06 CEST 2011
Errors running builder 'Java Builder' on project 'metadataassistant'.

java.lang.NullPointerException
       at org.eclipse.jdt.internal.compiler.lookup.MethodBinding.getAnnotations(MethodBinding.java:510)
       at lombok.eclipse.agent.PatchVisibleForTesting.handleVisibleForTestingOnMethod(PatchVisibleForTesting.java:86)
       at lombok.eclipse.agent.PatchVisibleForTesting.onFindMethod(PatchVisibleForTesting.java:70)
       at org.eclipse.jdt.internal.compiler.lookup.Scope.getMethod(Scope.java:2306)
       at org.eclipse.jdt.internal.compiler.ast.CastExpression.checkAlternateBinding(CastExpression.java:260)
       at org.eclipse.jdt.internal.compiler.ast.CastExpression.checkNeedForArgumentCasts(CastExpression.java:174)
       at org.eclipse.jdt.internal.compiler.ast.ASTNode.checkInvocationArguments(ASTNode.java:347)
       at org.eclipse.jdt.internal.compiler.ast.MessageSend.resolveType(MessageSend.java:493)
       at lombok.eclipse.agent.PatchVal.skipResolveInitializerIfAlreadyCalled2(PatchVal.java:60)
       at org.eclipse.jdt.internal.compiler.ast.LocalDeclaration.resolve(LocalDeclaration.java:210)
       at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolveStatements(AbstractMethodDeclaration.java:463)
       at org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.resolveStatements(MethodDeclaration.java:252)
       at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve(AbstractMethodDeclaration.java:422)
       at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1148)
       at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1258)
       at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:538)
       at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:763)
       at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137)
       at java.lang.Thread.run(Thread.java:662)

eclipse.buildId=I20110613-1736
java.version=1.6.0_26
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=de_DE
Command-line arguments:  -os win32 -ws win32 -arch x86

----

Error
Wed Oct 12 20:16:06 CEST 2011
Errors running builder 'Java Builder' on project 'metadataassistant'.

java.lang.NullPointerException
       at org.eclipse.jdt.internal.compiler.lookup.MethodBinding.getAnnotations(MethodBinding.java:510)
       at lombok.eclipse.agent.PatchVisibleForTesting.handleVisibleForTestingOnMethod(PatchVisibleForTesting.java:86)
       at lombok.eclipse.agent.PatchVisibleForTesting.onFindMethod(PatchVisibleForTesting.java:70)
       at org.eclipse.jdt.internal.compiler.lookup.Scope.getMethod(Scope.java:2306)
       at org.eclipse.jdt.internal.compiler.ast.CastExpression.checkAlternateBinding(CastExpression.java:260)
       at org.eclipse.jdt.internal.compiler.ast.CastExpression.checkNeedForArgumentCasts(CastExpression.java:174)
       at org.eclipse.jdt.internal.compiler.ast.ASTNode.checkInvocationArguments(ASTNode.java:347)
       at org.eclipse.jdt.internal.compiler.ast.MessageSend.resolveType(MessageSend.java:493)
       at lombok.eclipse.agent.PatchVal.skipResolveInitializerIfAlreadyCalled2(PatchVal.java:60)
       at org.eclipse.jdt.internal.compiler.ast.LocalDeclaration.resolve(LocalDeclaration.java:210)
       at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolveStatements(AbstractMethodDeclaration.java:463)
       at org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.resolveStatements(MethodDeclaration.java:252)
       at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve(AbstractMethodDeclaration.java:422)
       at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1148)
       at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1258)
       at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:538)
       at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:763)
       at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137)
       at java.lang.Thread.run(Thread.java:662)

eclipse.buildId=I20110613-1736
java.version=1.6.0_26
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=de_DE
Command-line arguments:  -os win32 -ws win32 -arch x86

to reproduce

public class TestFile {
       public static void main(String[] args) {
               File[] test = new File("x").listFiles(null);
       }
}

Getting a successful compilation but then a run-time verify error when doing this:

 if("abc.def".toCharArray().box().count('.')==1)

Workaround:

 if(Linq.count(ArrayUtils.box(value.toCharArray()), '.') == 1)

The idea is make lombok-pg more accessible to all the maven folks.

This still might need some investigation, but this should be a good place to start: http://nexus.sonatype.org/oss-repository-hosting.html

I've spent the last 3/4 hours trying to track what's going on with a very serious compile-time bug, I hope this can be resolved in the near future. The reason I spent so much time is that this somehow causes the javac compiler to report an error (Compile failed; see the compiler error output for details) but the 'great' thing about it, there is not freaking compiler output, it just crashes or something so I had to narrow it down by trial and error across a large code-base. Fun times. Atleast ECJ is not affected by it thankfully. Anyhow, here's how to reproduce:

public static void addHandler(Function1<Object, Void> handler)
{
}

public static void main(String[] args) throws Exception
{
    val handler = Object.class.getDeclaredMethods()[0];
    addHandler(invokeMethod(new Main(), handler));
}

Ugly workaround which must be purged from this earth:

 import lombok.ExtensionMethod;
 import lombok.Functions.Function1;
 import lombok.val;
 import static propel.core.functional.projections.InvokeOneArg.invokeMethod;
 import propel.core.functional.projections.InvokeOneArg;

 public static void addHandler(Function1<Object, Void> handler)
 {
 }

 public static void main(String[] args) throws Exception
 {
   val handler = Object.class.getDeclaredMethods()[0];
   addHandler((Function1<Object, Void>)InvokeOneArg.invokeMethod(new Main(), handler));
 }

They both use this method:

@Validate
public static <T> Function1<Object, Void> invokeMethod(@NotNull final Object obj, @NotNull final Method method)
{
  return new Function1<Object, Void>() {

  @SneakyThrows
  public Void apply(Object arg)
  {
    try
    {
      method.invoke(obj, arg);
      return null;
    }
    catch(InvocationTargetException e)
    {
      // get rid of wrapper exception
      throw e.getCause();
    }
  }
};
}

public java.util.Iterator<ELEMENT_TYPE> iterator() {
  if ($state == 0) {
    $state = 1;
    return this;
  } else return new $YielderMETHODNAME;
}

This guarantees that the yielder will be initialized only once and not twice if possible.
For this make sure to also add a new initial state:

case 0:
  $state = 1;

Thx again to Vladimir Nesterovsky for pointing this out.

Before I go and rename all my methods to avoid clashes with built-in methods in String class etc. I wonder if this is expected behaviour or a regression:

I think I used to be able to use methods such as split, compareTo, etc. as extension methods without a problem on e.g. String classes i.e. extension methods side-by-side with methods inherited by the class and eclipse seemed to work fine. Even if it inherited a split() method and an extension method was called split() as well, eclipse would select the right one (I believe I remember saying to myself that this is too cool to be true, but I may be imagining things...).

This is not the case anymore so I think its a regression...

How many times do we have to check for NPE, just so that we catch the null reference early on? Wouldn't it be nice to have an annotation that is applicable to method such as:

@nullcheck
void test(String first, String second) {
}

It could throw a new NullPointerException("first") or new NullPointerException("second"), provided the argument named can be captured...

The @NotNull validation error message is a bit vague, so you have a function with like (say) 10 arguments and whichever one fails throws an "IllegalArgumentException: The validated object is null."

Firstly I wonder if it would be possible to throw a NullPointerException instead? It is after all a null reference and people expect that as an exception. This is only for @NotNull, the other @Validate correctly in my opinion don't do that. And secondly would it be possible to include the argument name or if that's not discoverable, perhaps its index e.g. #1, #2...#n? In other words: "NullPointerException: The argument in position 1 is null" or something along these lines...

When a method that is annotated with @Validate throws an exception, the exception stack trace is not correct (in particular the line number). This could make debugging extremely tricky, because it points to the @Validate annotation always, instead of the actual line number. I wonder if there is some sort of magic we can pull to make line numbers work as expected...

Using dom4j library and that has some raw type usage, so I do this:

  for(val attribute : propElement.attributes())
  {
    val attr = (Attribute)attribute;

The attributes() method call returns a raw List, but I'm getting an error "propElement cannot be resolved or is not a field". Workaround: Changing the val to Object