##Fix data

the constructor generation is just not that useful as is. Consider generating a constructor with only all final variables.

## Fix Eclipse's HandleCleanup

Consider requiring an initializer and warn when the varname gets reassigned, if the declaration wasn't already final. Think about this more.

Right now exceptions thrown by the cleanup method will mask any exceptions thrown in the main body, which is not wanted. This does not appear to be doable without java 7 features or very extensive additions to the lombok framework.

A lot has been tried:

    Tried tactics, and why they won't work:
    
     - Replace every 'return', 'break', and 'continue' statement (for the latter 2, only if they break/continue out of the try block) with a block that first sets a uniquely named flag before doing the operation.
       Then, check that flag in the finally block to see if the cleanup call should be guarded by a try/catchThrowable. This doesn't work, because its not possible to instrument the 4th way out of a try block:
       just running to the end of it. Putting a 'flag = true;' at the end isn't safe, because that might be unreachable code.
    
     - Put catch blocks in for all relevant exceptions (RuntimeException, Error, all exceptions declared as thrown by the method, and all types of exceptions of the catch blocks of encapsulating try blocks.
       This doesn't work, partly because it'll fail for sneakily thrown exceptions, but mostly because you can't just catch an exception listed in the 'throws' clause of the method body; catching an exception
       that no statement in the try block can throw is a compile time error, but it is perfectly allright to declare these as 'thrown'.
    
     - Put in a blanket catch Throwable to set the flag. Two problems with this:
       First, sneaky throw can't be done. Thread.stop invokes a security manager and triggers a warning, Calling a sneakyThrow method creates a runtime dependency on lombok, constructing a sneakyThrow in-class
       requires either lots of "$1" classes that clog up permgen, or are slow and require reflection tricks to load live off of a byte array literal.
       Secondly, this would mean that any statements in the try body that throw an exception aren't flagged to the user as needing to be handled. Unacceptable.
    
    The Cleanup annotation now also calls the cleanup method for you, and will call it at the END of the current scope. The following plans have been tried and abandoned:
    
     - Cleanup right after the final mention. This doesn't work, because the final mention may not be the final use-place. Example:
       @Cleanup InputStream in = new FileInputStream(someFile);
       InputStreamReader reader = new InputStreamReader(in);
       reader.read(); //oops - in is already closed by now.
    
     - Require an explicit var.cleanup() call and consider that the cue to close off the try block.
       This doesn't work either, because now variables set in between the @Cleanup declaration and the var.cleanup() call become invisible to following statements. Example:
       @Cleanup InputStream in = new FileInputStream(someFile);
       int i = in.read();
       in.close();
       System.out.println(i); //fail - i is inside the generated try block but this isn't, so 'i' is not visible from here.
    
    By running to the end of visible scope, all these problems are avoided. This does remove the flexibility of declaring where you want a close call to be executed, but there are two mitigating factors availa
    
     1) Create an explicit scope block. You can just stick { code } in any place where you can legally write a statement, in java. This is relatively unknown, so I expect most users will go for:
    
     2) Just call close explicitly. I've yet to see a cleanup method which isn't idempotent anyway (calling it multiple times is no different than calling it once).
    
    During the course of investigating these options, the AST code has been extended to support live replacement of any child node, including updating the actual underlying system AST as well as our own.
    Unfortunately, this code has NOT been tested. It was rather a lot of work so I'm leaving it in, and at least for eclipse it even seemed to work.


## Fix eclipse's pointers

* We really need to do more work on setting positions properly.

## Eclipse insertion point for newly generated code

We need to figure out which of the bodyStart/bodyDeclarationStart/sourceStart blocks are used as where insertions happen, and set it to the entire line of a field and not just the annotation.

Don't forget to extend past the opening brace for @Data - so eclipse puts generated methods in the right place!

## javadoc

Either just let people run lombokc and javadoc that, -or-, hack javadoc.

Using either a taglet to cast our way into Javadoc's AST, or a doclet are both bad ideas:

It does not appear possible to get there from a taglet, and a doclet replaces most of javadoc's functionality -
exactly the functionality we DONT want. (Doclets convert a structural set of classes to HTML. We want to change
the classes offered, not how the HTML is generated!)

## lombokc

To keep comments, try:

com.sun.tools.javac.main.JavaCompiler.instance(context).keepComments = true;

## netbeans agent plugin

module: java.source
class: org.netbeans.modules.java.source.parsing.JavacParser

to instrument:

class: JavacTaskImpl

method1: public JCBlock reparseMethodBody(CompilationUnitTree topLevel, MethodTree methodBody, String newText, int annonIndex) {}
method2: public Iterable<? extends CompilationUnitTree> parse();

in either case, returned value could be null/empty. CompilationUnitTree are MethodTree are superinterfaces of JCCU and JCMD.

problem: the agent stops receiving requests to transform classes early in the netbeans load process.

Possible work-around: Rewrite the entire JavacTaskImpl.class file on disk. It's in:

/NetBeans 6.7 RC3.app/Contents/Resources/NetBeans/java2/modules/ext/javac-impl-nb-7.0-b07.jar

Some work has been done in the addNetbeans branch.