Was the Reflection API that difficult?
Yes, easy to forget its low-level minutia. Anyway, you create more value
writing code specific to your application domain, rather than plumbing
with the compiler.
Oracle describes common problems encountered using
the Reflection API in troubleshooting sections of its tutorials: Fields
- Don't test private methods.
- Give the methods package access.
- Use a nested test class.
- Use reflection.
Explain, what's going on?
dp4j analyses method blocks annotated with JUnit
annotations and just before the compiler generates the bytecode for the
tests it replaces every privileged access with the equivalent Java
Reflection API calls (in the AST).
Does it work with Eclipse?
Kinda. Eclipse use its own Java Compiler, while dp4j interacts with javac internal APIs. But if you use Maven/m2eclipse
then you can specify to use the javac compiler. dp4jmaventest.zip
demonstrates. IntelliJ uses Oracle's Java Compiler, just as NetBeans does.
Does it really work?
course, but this is the earliest release of "release early, release
often". Not all Java syntax is covered, especially the most complicated
(it's not a bug, it's a feature =) ) and only the Singleton and Template
Method (partially) are validated.
You shouldn't use this in production code yet, but do we consider testing code production code?
And you are welcome to contribute patches, it's an open-source project
Do you need help?
Sure, contributions extending syntax coverage and patterns validation are welcome and duely acknowledged in this open-source project
What other boilerplate busters are there?
@Data injects getters, setters, a toString, hashcode, equals, and a constructor for the annotated class; It compromises 12 annotations;
- Juast: Use primitive arithmetic operators (+/-*) with
BigDecimals without even using annotations;
- SqlWrapper: Vendor-dependant SQL is wrapped in
stmt.executeQuery(SqlWrapper.selectId(ordersTable, customerColumn, "John Smith");
Know of another? Announce it