| Age | Commit message (Collapse) | Author |
|---|
|
other lombok plugin developers.
|
|
Instead they are retrieved
dynamically, with a pinch of caching during runtime. We already had some
fixes to make sure that compile time constanst were not inlined, but we
need to take into account that a lot of the Integer-based enums have
been replaced with actual enums.
Also, certain TreeMaker methods needed to be invoked dynamically with
reflection.
This needs to be reviewed, and if it turns out that these changes are too
dramatic, we should fork out a larger part of our code for specific JVM
versions.
|
|
|
|
because it is a lot more work than anticipated, but this code is prettier and slightly more bugfree so worth checking in.
|
|
are abstract classes.
|
|
fixes the issue where delombok would leave lombok annotations in the file if that annotation had no actual effect (such as @Getter on a field if there is an explicit getX method for that field).
issue #443: delombok would screw up @SneakyThrows on methods or constructors with empty bodies. Now we generate warnings for this.
|
|
would fail with VerifyError when that code is executed in eclipse.
|
|
Also fixed a bug where eclipses installed in user.home weren't found automatically on windows.
Also fixed a bug where STS installed in C:\Program Files (X86) wasn't found automatically.
|
|
|
|
After this was finalized I realize that we might consider moving entirely
to String based options, instead of inferring the options from the
provided enum. This setup does have the benefit of throwing exceptions when
options are not present.
|
|
that JDK8 behaves similar to JDK7.
|
|
a few or no withers at all, and adding them is a lot simpler than
removing them. This is a breaking change, but then that's why @Value
was in experimental in the first place.
|
|
|
|
* re-introduction of onMethod/onConstructor/onParam
* tests checking error/warnings rewritten to be more heuristic, in order to accomodate difference in messaging between java6 and java 7
* Ability to eliminate java's own output of erroneous error messages (heh); i.e. those messages that are invalidated by lombok's actions. This mechanism is used for onMethod/onConstructor/onParam
* First steps to unifying a billion setGeneratedBy calls into a single visitor traversal for eclipse' HandleGetter/Setter/Constructor/Wither
* To simplify 'zooming in' the tests on just a few files, added an 'accept' mechanism.
* Updated copyright headers of website to 2013.
|
|
Now to actually write the feature (Well, rescue it from the onX-removal tag).
|
|
* Removed most documentation and instead put in a link to the much more up to date and extensive documentation at http://projectlombok.org/features
* Getting ahead of ourselves a little, added notes on onConstructor/onParam/onMethod which we are about to add in the next few commits.
* Updated copyrights to 2012.
|
|
(With thanks to Bart Enkelaar)
|
|
getCtcInt calls into constants as defined in Javac.
|
|
|
|
|
|
|
|
eclipse for fields with @Deprecated on them.
|
|
javac if generated constructors are involved.
|
|
seems to just remove these from the AST entirely.
|
|
org.eclipse.jdt.internal.compiler.lookup.MethodBinding.sourceMethod(MethodBinding.java:1108)
|
|
|
|
in our tests, the tests are in the unfortunate scenario where we always compile against a given javac (lib/build/javac6.jar), and always run the tests against a given javac, but that javac tries to use the bootclasspath of the host JRE, and if that is JRE7, you get all sorts of errors.
I fixed it by still compiling against a given javac (we can only ship one lombok.jar after all), but having the test task run with a given bootclasspath and a given javac.jar.
There are 2 tasks that download both rt.jar and javac.jar for either OpenJDK6 or OpenJDK7, and it writes a properties file with those locations. The test task will use this property file, and explain what you need to do if it is not there.
Incidentally, this brought to light issue 422: Delombok in java7 produces VerifyErrors.
|
|
IllegalArgumentExceptions in certain cases, but with no message, thus making it very hard to figure out what went wrong. The patch throws the same exceptions in the same cases, but gives the exception a useful error message.
|
|
|
|
See issue 411.
|
|
both eclipse/ecj and javac operations.
|
|
setting the annotation you handle for an XAnnotationHandler<T>;
default behaviour still extracts the T part out of the signature.
|
|
|
|
|
|
in eclipse for @ExtensionMethod, resulting in VerifyErrors in the emitted class files.
|
|
This also meant delombok would not emit the changed code if that's all that changed, because it thought nothing changed.
|
|
the handlers in the next priority level need it.
|
|
|
|
system for javac and ecj.
* @Value now makes the class itself final by default.
|
|
annotations including @NonFinal and @PackagePrivate, and some refactors. No tests yet.
|
|
|
|
|
|
Conflicts:
src/core/lombok/javac/handlers/JavacHandlerUtil.java
|
|
refactors to HandleSetter
|
|
0.11.2 due to a fix involving WeakHashMaps for lazy getters of type boolean.
|
|
declarations of said annotations when running in Netbeans. This solves another batch of usability issues in Netbeans.
|
|
parameters did not work in javac.
|
|
@XxxArgsConstructor is present means it gets ignored, but until now lombok didn't warn you about this.
|
|
'pilot' to see if we cause any problems with this approach. It does generate nicer error messages!
Example: Using @Synchronized with named lock on a static method, naming a non-existent or instance lock. That used to error on line -1.
|
|
because attrib adds them even in places where that's wrong).
Also split up the SynchronizedName test into separate cases for each expected failure mode.
|
