github/lombok.git/src/utils/lombok/javac/java6, branch feat/memoize

eliminate ‘you are using private API’ warnings by streamlining all reflective access via a class that uses sun.misc.Unsafe to arrange access. From the nqzero permit-reflect library.

2018-10-29T22:13:59+00:00

Finished refactor of FieldAugment; there's no longer a separate variant for boolean and references, and the code no longer blows up with a bunch of NPEs if you try to use the reference variant (which is now the only variant) with a primitive type.

2014-06-05T21:45:43+00:00

Should have zero effect on features or bugs, 100% refactor.

[#590][refactor] Fix for deadlock in WeakHashMap. Refactored all code that used a

2014-03-17T20:56:49+00:00

WeakHashMap to fake a field.

[jdk8support] ... and javadoc copying support is back for javac8. Also fixed some copyright headers.

2013-09-25T21:04:04+00:00

Pre-emptive fix for the anticipated removal of ListBuffer.lb() in javac8

2013-09-25T19:38:37+00:00

Getting the java8 compiler remember the comments

2013-08-12T22:24:51+00:00

A lot of refactoring on how javadoc is handled, to prepare for copying javadoc from field to setter/getter in javac.

2013-07-08T02:58:00+00:00

more work on the tricky Context hack to make 'ant compile' not emit warnings.

2013-07-07T20:05:41+00:00

FINALLY! Found the cause of a really weird eclipse bug,

2013-07-07T19:49:47+00:00

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.

Renamed Comment to CommentInfo.

2011-12-12T22:24:58+00:00