| Age | Commit message (Collapse) | Author |
|---|
|
try and keep up with the complete rewrites of the doc comment parser from java6 to java7 to java8. Still doesn't actually work in jdk8, but only because of a last-mile issue. (we communicate the doc comment via compilationUnit.docComments but that changed types in jdk8, we just need to make a wrapper to make that work).
|
|
|
|
don't want it!"
|
|
|
|
it has major refactorings to make JDK6-8 support
possibly with much prettier code.
|
|
to program handlers that are not cross javac6-8 compatible?
|
|
still a looooong way to go.
|
|
Conflicts:
src/core/lombok/javac/handlers/JavacHandlerUtil.java
src/utils/lombok/javac/CommentCatcher.java
src/utils/lombok/javac/Javac.java
|
|
coming up in autocomplete dialogs when guava's was intended.
|
|
javadoc from field to setter/getter in javac.
|
|
|
|
where _ANY_ mention of com.sun.tools.javac.tree.TreeMaker,
anywhere in a source file, would disable pretty much every
intelligent part of what makes the 'I' in IDE in eclipse:
No auto-complete, no 'go to declaration', etcetera, but only
since Eclipse Juno (not fixed in Kepler either). It's the
presence of src/stubs/com/sun/tools/javac/util/Context.java.
I've moved Context to a special stubs directory that's only used
for javac (so that we still get the benefit of getting some
warnings and such when making command line builds), and removed
the @Override annotations for where the stubbing is relevant
(for methods that exist in javac7 but not in javac6 on interfaces
we create implementations of). Furthermore, I did some extremely
tricky work in making our version actuall compatible with the
exact class signatures of both javac6- and javac7+'s versions;
generation of synthetic methods for reified type parameters was
causing havoc.
A big stack of 'here be voodoo' comments unfortunately added to
explain it all; necessary evil.
|
|
javac1.7. (The wrapper uses reflection). Need for: javac @Builder impl.
Also added some utilities to JavacHandlerUtil.
|
|
|
|
reason... now I'm just confused. Do we need it or not?
|
|
including docs and changelog.
|
|
and updated ECJ version detection.
|
|
AST/LombokNode. Tests updates to honour these with //version X at the top
of any test file (now also in eclipse, which until now always said it was v6)
|
|
platform and implemented it for javac BUT NOT FOR ECJ!
|
|
|
|
|
|
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.
|
|
that JDK8 behaves similar to JDK7.
|
|
getCtcInt calls into constants as defined in Javac.
|
|
annotations including @NonFinal and @PackagePrivate, and some refactors. No tests yet.
|
|
|
|
|
|
will use the getter for delegation
|
|
have an asm dependency and now due to lacking the jarjar treatment all sorts of VerifyError hell breaks loose if you put both lombok.jar and lombok-utils.jar of 0.10.6 in the classpath while compiling with javac.
|
|
|
|
on a per Compilation Unit basis. The old way involved making reflective calls and detecting whether you need the 1.6 or the 1.7 variant to do this. These shenanigans are now hidden behind a nice API (lombok.javac.CommentCatcher).
|
|
|
|
|
|
|
|
in java7 is now completely broken but we'll fix that next.
|
|
See issues 43, 271, and 287.
|
|
is) separately compilable, i.e. has no deps on any of the others.
This is preparation work for being able to access some of these from lombok.ast without creating a cyclic dependency nightmare.
|
