toolisticon/aptk

A toolkit project to enable you to build annotation processors more easily

toolisticon

Organizational stats

aptk's Issues

Records not properly detectable

Although APT creates TypeElement instances for Java records, the wrapper APIs of APTK do not properly handle those as they do not consider the element kind RECORD. Thus, for example, AptkCoreMatchers.IS_TYPE_ELEMENT filters out TypeElement instances created for records.

It would be nice if TypeElementWrapper exposed a getRecordComponents() that would internally defensively inspect whether the APT runs on Java 16 or above (presence of getRecordComponents() on TypeElement).

Does it make sense to rather implement ….isTypeElement() on ElementWrapper by doing a type check of the underlying Element rather than inspecting the element kind?

Simplify fluent apis for validation and filtering

API for validation and filtering currently is not very intuitive.
Need to establish a proper API.

Lombok compatibility

By default, execution order of annotation processors is random.

So in some cases we need to check for lombok annotations.

An example the CoreMatcher.HAS_NOARG_CONSTRUCTOR might detect the default noarg constructor at a class annotated with RequiredArgsConstructor or AllArgsConstructor leading to a false positive result...

Add support for class creation

The toolkit should provide an API to create classes easily.

This could be done by using some kind of templating engine.

That templating engine should support the following features:

• control blocks (if, loop)
• templating processors (insert variable/text, insert block)
• handle imports, packages and class names

Enhance documentation

Documentation is kind of outdated since it only describes the usage of the fluent type validator.

There are already a lot more features included in the toolkit which need to be described.

It will be a good opportunity to do that not in the README.MD file but to use github pages with jekyll instead.

Java >= 9 compatibility

The APTK internally uses the google compile test library.

But we are in a kind of dilemma. Only versions <= 0.9 are compatible with Java versions 6 and 7.
But these versions are using the tools.jar and are therefore incompatible with Java >= 9.

We need to replace the library by some custom code. We can use the existing Fluent api and just replace the implementation.

Stop supporting Java 6

Extended support for java 6 ended in december 2018.
With Java 12 the source and target compatibility with java 6 was removed.

So i guess it's time to drop support for Java 6.

It also allows the use of SafeVarArgs annotation to get rid of some annoying warning messages when using varargs.

Better Support of incremental builds by CompilerMessagesProcessor

Some IDES like Intellij are just doing incremental compilation of changed classes.

With current Compiler mesaage processors implementation this could lead to IDE internal build issues because of missing enum values.
To fix this the compiler should collect the package names of annotated messages and then scan for all annotations in processingOver flagged phase. By doing this it wopuld pick up even the precompiled classes from classpath.

Add elsif and else cases to if statements in template engine

Complex if statements with elseif and else cases make life a lot easier and templates far more readable.

Switch to Java 8 Source level

Extended support of Java 7 will end soon, so it's definitly time to get rid of it and switch to source level 8.

Additionally further support of Java 8 streaming API should be added.
This mainly affects AptkCoreMatchers and FluentFilter FluentValidator API.

Fix issues related with generic types

The method matchers aren't working 100% correctly when generic parameters are used.

Additionally getting the FQN of a TypeMirror is broken in this case.

Decouple testhelper module from annotationprocessor

Testhelper can be internally used for tests if internal dependencies to annotationprocessor module are removed

Add enhanced support for Repeatable annotations

Java 8s Repeatable annotations are reducing boilerplate code on user side.

But they are complicating writing of annotation processors, since you have to process both annotation marked as repeatable and its wrapper annotation.

It should be great to provide a method in AbstractAnnotationProcessor with allows getting all elements marked with either of the the two annotations.

Additionally there should be an enhancement of annotation wrappers to access all value.

Need to add support to handle generic types

Handling generic types in classes and interfaces is really tricky to realize. Usually have to handle multiple Type Elements in the type hierarchy to find the correct type for return types and parameters. Otherwise it's impossible to create a valid implementation of a type.

Add support for changing classes

Annotation processors usually aren't allowed to alter or overwrite existing classes.

Nevertheless it's possible to do that by using loopholes in the JDK.
Lombok is a prominient example for that.

So it would be nice to provide such support as well because it extends the possibilities of things can do with annotation processors drastically.

Enhance testhelper to check for compiler notes.

At the moment it's possible to check for warnings and error messages.

It would be nice to be able to check for notes / info messages too.

ElementWrapper.filterFlattenedEnclosedElementTree is broken

There's an issue with that method. It internally uses filtering for enclosing Elements instead of Enclosed Elements.

Simplify API by removing FrameworkToolWrapper from API

We should remove the FrameworkTooWrapper from the API to be able to simplify the API drastically.

This can be done by using a ThreadLocal ToolingProvider class. This must be initialized / cleaned up in the AbstractProcessor base class.

By doing this most Utiity classes can the be accessed in a static way.

Enhance templating by include command

It would be good to to support an include command to provide reusable templates without the need to copy and paste them. It also may help to make template creation more structured.

The command has to take two parameters:

1. the template resource
2. the access path that will be used as "model" for template

Enable Checkstyle Checks

Base functionality is working right now.
So it's time to polish the code a bit by enabling checkstyle checks and by fixing existing checkstyle violations.

Provide utility functions to determine mandatory and optional annotation attributes

Add support for writing resources

The toolkit should provide some kind of API to allow creation of resources easily.

Add line/column numbers to template related error messages

We need column/line numbers in error messages to make bugfixing of template releated issues easier.

Create utility class for reading AnnotationValues

We need some kind of utility class to ease reading of annotation attribute values.
This can become quite handy if we want to read encapsulated annotations in annotation attributes.
It's also useful to read class (Array) values.

MessagerUtils: Support ValidationMessage as parameter

We need to support ValidationMessage as parameter to be able to move message generation based on code and message in a more centralized way.

This has several benefits like

• code output can be enabled by MessagerUtils.setPrintMessageCodes
• reduces complexity of Message enums
• ...

Increase variation in tests

Test do need some more variation since there are a lot of special cases for different kind of types.

This especially affects all atomic types, arrays and classes that are using generics. (Mainly all type that are not extending Object)

Test coverage might be misleading here. Because it doesn't describe if all special cases are handled coorectly

Plans for a new release?

I'm using and enjoying this toolkit, but I'd really like to pick up the new TypeMirror helpers, so I can completely drop auto-common. Do you plan on doing an official release soon? Thanks!

Polishing for 1.0.0 release

Enhanced Support for Kotlin

Some things are not working properly in Kotlin

• AnnotationWrapper annotation can just be placed on PACKAGES which can't be annotated in Kotlin => Workaround via Class

remove testhelper submodule

The compiletesting framework was created based on the testhelper code.

Therefore the testhelper submodule can be removed when all tests are migrated to use compiletesting framework.

This has also other benefits:

• compiletesting framework configuration is simpler and far more readable
• compiletesting framework is quite mature right now - extended support during failing tests,...
• No more paramerterized tests

Fix FuentElementValidator

The FuentElementValidator class was accidentally committed and does not work at all.
This must be fixed.

move repo to toolisticon

would be a good candidate for the toolisticon - suite

Use spiap in examples

Get rid of manually created META-INF/services files in examples for registering annotation processors to allow annotation processing in annotation processor projects.

This allows us to use annotation processor based tools like lombok.

Add transitions to FluentElementFilter

It might be nice to have the possibility to do transitions on FilterElements.

For example you could access all child elements from within the fluent filter.

transition results must replace the current Element filter base (internal Element list).

Add getBinaryName to TypeElementWrapper and TypeMirrorWrapper

use maven-oss-parent

after moving to toolisticon, consider using the common mavn parent

Add Autoclosable to Writer classes provided by FilerUtils

Support for java 6 and 7 is long gone, so it's encouraged and possible to add Autoclosable to those Writers