This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 155796 - Use annotations for bytecode patching
Summary: Use annotations for bytecode patching
Alias: None
Product: platform
Classification: Unclassified
Component: Module System (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: apireviews
Depends on:
Reported: 2008-12-18 21:14 UTC by Jesse Glick
Modified: 2009-02-19 22:53 UTC (History)
3 users (show)

See Also:
Exception Reporter:

Proposed patch, no apichanges yet, processor to verify syntax would be nice to add (99.25 KB, patch)
2008-12-18 21:15 UTC, Jesse Glick
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2008-12-18 21:14:08 UTC
Bytecode patching is still in use for a handful of modules: editor.lib, editor.settings, and java.source. All of these
just set some methods to be public.

Rather than the current rather complex infrastructure which relies on build-time postprocessing of classes, I propose a
simpler technique: use an annotation to indicate the member you want to be public, and have PatchByteCode just set its
ACC_PUBLIC when loading.

The current impl does not support method renaming, change of superclass, etc. Those things could be added, but at the
expense of a more complex bytecode analyzer. If we ever needed these things, I think it would be better to use ASM.

Only known limitation of the current impl is that it does not support mixing @PatchedPublic with other annotations.
Could be solved if desired, but probably unnecessary.

Would be nice to also add an annotation processor for @PatchedPublic that verifies that it is being used on a private
method (and, currently, that the method has no other annotations).
Comment 1 Jesse Glick 2008-12-18 21:15:19 UTC
Created attachment 75156 [details]
Proposed patch, no apichanges yet, processor to verify syntax would be nice to add
Comment 2 Jesse Glick 2008-12-18 21:23:00 UTC
Please review this proposed API change.

Note that an alternate resolution is to simply remove the bytecode patching for these modules and assert that they have
been incompatibly changed. Last used in Apr 2007. Perhaps we would rather not try to offer this kind of binary
compatibility. (For the java.source case, source compatibility was retained, since the new overloads take a more general
type. For the editor.* cases, source compatibility was intentionally broken - no one should be calling these constructors.)
Comment 3 Jaroslav Tulach 2008-12-19 22:57:56 UTC
Y01 Perfect, I was thinking about this as well, but afraid to propose it.
Y02 The annotation could also be useful on classes
Y03 Now when this becomes easy to use feature I'd suggest to expand to 
incorporate it
Comment 4 Jesse Glick 2008-12-19 23:16:10 UTC
Y02 - yes, it could. I figured to defer implementing that and other possible features unless and until we need it.
Currently all we use is making methods public. It would be a compatible change to just add a new target ElementType.TYPE.
Comment 5 Vitezslav Stejskal 2008-12-22 09:42:36 UTC
Nice, thank you.
Comment 6 Jesse Glick 2008-12-22 16:54:55 UTC
Still need to measure the overhead of the patch(byte[]) method in the profiler. Unlike the old system, which could just
check for a "nb" suffix in the byte array, this has to scan the constant pool and at least some parts of the field and
method lists to see if an annotation is present. It is possible this scanning is expensive enough to matter. If so, a
possible optimization would be to have the annotation processor not only verify syntax but also touch a marker resource
(e.g. build/classes/.bytecodePatched), in which case JarClassLoader would only try to patch bytecode for a class in case
its code source contained this resource.
Comment 7 Jesse Glick 2009-01-07 00:55:15 UTC
Bytecode patching overhead in Basic IDE seems to be around 50msec, based on System.nanoTime. Not much but probably worth
Comment 8 Jesse Glick 2009-01-07 02:00:21 UTC
Can use META-INF/.bytecodePatched (generated by the AP) to avoid inspecting most class files.

For reference, annotations in bytecode are described here:
Comment 10 Jesse Glick 2009-01-07 02:19:48 UTC
core-main #bef62bdad026
Comment 11 Quality Engineering 2009-01-07 16:57:32 UTC
Integrated into 'main-golden', will be available in build *200901071401* on (upload may still be in progress)
User: Jesse Glick <>
Log: #155796: @PatchedPublic for easy bytecode patching.