aboutsummaryrefslogtreecommitdiff
path: root/src/lombok/eclipse/handlers/HandleData.java
AgeCommit message (Collapse)Author
2009-11-25Refactored the source folders.Reinier Zwitserloot
2009-10-31Made the utility methods previously located in package private 'PKG.java' in ↵Reinier Zwitserloot
lombok.eclipe.handlers and javac.eclipse.handlers public. Renamed them to more useful names, made all methods public, added some javadoc, and renamed one or two methods to be more consistent. Talked about in google groups thread http://groups.google.com/group/project-lombok/browse_thread/thread/52085a345e77c086
2009-10-17Fix: getters and setters for $foo fields (including our own $lock!) are now ↵Reinier Zwitserloot
no longer generated.
2009-10-16Switched all use of <code></code> in javadoc to {@code}.Reinier Zwitserloot
2009-10-16Fixed issue #24 by refactoring the AST.Node class - taken it out, and in the ↵Reinier Zwitserloot
process fixed a lot of type annoyance by adding more generics. Also changed coding style from for/while/if/switch/catch/do ( expr ) {} to for (expr) {}, hence the changes _everywhere_.
2009-09-23Massive change to the eclipse handlers: They now set the 'generatedBy' flag ↵Reinier Zwitserloot
which we can use to patch eclipse in specific places to ignore generated nodes.
2009-09-01More work on fully addressing the David Lynch bug (issue #41) - the ↵Reinier Zwitserloot
annotation @NotNull/@NonNull/@Nullable that is copied over by @Getter should no longer be causing the David Lynch bug.
2009-08-28null checks are no longer generated if you put @NonNull on primitives.Reinier Zwitserloot
2009-08-27Merge branch 'nonnull'Reinier Zwitserloot
Conflicts: src/lombok/eclipse/handlers/HandleData.java src/lombok/eclipse/handlers/HandleEqualsAndHashCode.java src/lombok/eclipse/handlers/HandleSetter.java src/lombok/javac/handlers/HandleData.java src/lombok/javac/handlers/HandleEqualsAndHashCode.java src/lombok/javac/handlers/HandleSetter.java
2009-08-27Now @Nullable is also copied over.Reinier Zwitserloot
2009-08-27Made all parameters of all generated methods 'final'.Reinier Zwitserloot
2009-08-01The constructors will now also add non-final fields if they have a NonNull ↵Roel Spilker
annotation The constructor will test for null-values The constructor and static constructor will copy the NonNull annotations from the fields
2009-07-27Split off generation of equals() and hashCode() methods form @Data into a ↵Reinier Zwitserloot
new annotation, @EqualsAndHashCode. Addresses issue #8
2009-07-27Added support for @ToString annotation. The code for generating toStrings ↵Reinier Zwitserloot
has now moved from HandleData to the new HandleToString.
2009-07-26[TYPOS]Reinier Zwitserloot
2009-07-26Addresses issue #5:Reinier Zwitserloot
hitting 'find callers' on a @Data annotation should find callers of the (static) constructor. Right now it'll find callers to the *static* constructor ONLY. Letting it find callers of the public constructor if there is no static constructor just doesn't work.
2009-07-18No constructor entry should be made for assigned final fieldsRoel Spilker
2009-07-14Fixed a problem where @Data with a static constructor and generics params on ↵Reinier Zwitserloot
the class would generate errors regarding IllegalArgumentException in setSourcePosition in ASTNode.
2009-07-11'fixed' data up a bit by including only the final fields for the constructor.Reinier Zwitserloot
Also fixed a bug in javac's toString() generation for the @Data constructor. It did not include the transient fields.
2009-07-06Last massive documentation dump. All basic javadoc is now done, though ↵Reinier Zwitserloot
especially the docs on the lombok annotations in the lombok package need far more massaging. Also added a feature to HandleSynchronized to not auto-generate the locker fields if a specific name is provided (because, imagine you typoed those. You'd never find it!)
2009-07-01Pretty big fix for reparse() - now uses rebuild(), which also received a ↵Reinier Zwitserloot
pretty big fix in making the loop detection algorithm far more robust. Still not sure what was the problem, but the robustificationization helped.
2009-06-28Preparating for java 1.5-ification. All stuff that isn't specific to javac ↵Reinier Zwitserloot
should run in java 1.5, so that an eclipse started on a 1.5 JVM will still run lombok.
2009-06-25trivialReinier Zwitserloot
2009-06-25Removed adding the statement: 'final int PRIME = 31;' in the HandleData's ↵Reinier Zwitserloot
createHashCode method when there are 0 fields in the type (it would generate a local variable never used warning!)
2009-06-23fixed a bug where the auto-generated constructors (actual or static) would ↵Reinier Zwitserloot
throw eclipse errors if you had 0 non-static fields.
2009-06-23HandleData for eclipse now seems to work 100%. Also updated toString to use ↵Reinier Zwitserloot
deepToString, and added @Override in case people have warnings for missing @Override annotations on.
2009-06-23@Data's generation of the equals() method now works!Reinier Zwitserloot
2009-06-23Fixed some bugs in copyType(), and now the static constructor is generated ↵Reinier Zwitserloot
without any raw generics warnings - it is effectively done.
2009-06-23Figured out that our previous act of just assigning TypeReference objects ↵Reinier Zwitserloot
directly to other nodes (e.g. from a FieldDeclaration's type to a method argument) is NOT a good idea, as this screws up when the TypeReference object represents a generic type (like 'T') - each instance of a generic type has a different resolution, but 1 TypeReference object can only hold 1 resolution. Thus, a copyType() method has been written, and the Handle* classes have been updated to use it. Also, generateEquals() is half-finished in HandleData.
2009-06-23This is a 3-day bughunt that ended up being something extremely simple:Reinier Zwitserloot
** DO NOT REUSE TYPEREFERENCE OBJECTS ** because that makes the binding process go pearshaped - after hte first run, that TypeReference object's binding parameter is set, and as its set, the resolver won't bother re-resolving it. However, each parse run starts with new scope objects, and any 2 bindings created by different scopes aren't equal to each other. urrrrrrgh! Fortunately, a lot of code that 'fixed' methods by adding bindings and scope have all been removed, as the parser patch point is well before these bindings are created. Thus: ** NEVER CREATE YOUR OWN BINDINGS AND SCOPE OBJECTS ** because if it comes down to that, you're doing it entirely wrong. That's eclipse's job. We're patching where we are so you don't have to do this.
2009-06-21More work on the HandleData annotation. Constructor seems to work fine, ↵Reinier Zwitserloot
static constructor not so much.
2009-06-21Due to a java bug, constants in enums don't work, so instead the default ↵Reinier Zwitserloot
access level for @Getter and @Setter have now just been hardcoded in GetterHandler and SetterHandler. Added ability to look up the Node object for any given AST object on Node itself, as you don't usually have the AST object. Added toString() method generating to @Data, and this required some fancy footwork in finding if we've already generated methods, and editing a generated method to fill in binding and type resolutions. HandleGetter and HandleSetter have been updated to use these features. Exceptions caused by lombok handlers show up in the eclipse error log, but now, if they are related to a CompilationUnit, also as a problem (error) on the CUD - those error log entries are easy to miss! Our ASTs can now be appended to. When you generate a new AST node, you should add it to the AST, obviously. Getter/Setter have been updated to use this.
2009-06-19Added initial support for the @Data annotation. Currently produces getters ↵Reinier Zwitserloot
and setters only, not yet a constructor, toString, hashCode, or equals. HandleGetter and HandleSetter have been updated to handle static (theoretic; you can't put annotations on static fields normally). You can now make AnnotationValue objects using just an annotationNode and a target type, as well as check if a given annotationNode is likely to represent a target annotation type. This is in Javac and Eclipse classes. HandleGetter and HandleSetter can now be asked to make a getter/setter, and will grab access level off of a Getter/Setter annotation, if present.