Details
-
Type:
New Feature
-
Status:
Reopened
-
Priority:
3 Minor
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: Build & Test
-
Labels:None
-
Terracotta Target:Pending
Description
Because it's adding an additional build step, it will be critical that it be as simple as possible to use. An idea would be to expose a simple post-processing compiler that scans all of the classfiles in a given directory or jarfile to find the ones that match DSO metadata (either from a config or from annotations embedded in the classfiles themselves). The tool would then simply munge the classfiles in place to add the necessary DSO instrumentation.
The tool could be exposed as a custom ant task that users would simply run after <javac>.
For example:
<target ...>
<javac srcdir='.' destdir='/classes'/>
<dso-compile classdir='/classes' />
</target>
Reasons
- App startup time reduced since instrumentation doesn't have to happen at runtime
- Some amount of static error and consistency checking becomes possible, improved dev experience
- Simplified deployment: conceivably could allow us to eliminate bootjar/-Xbootclasspath requirement
This could be a very helpful feature. I meet in my project quit significant slowdown of application startup, because of big amount of classes. Where can I find the implementation of this issue?