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.
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).
Created attachment 75156 [details] Proposed patch, no apichanges yet, processor to verify syntax would be nice to add
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.)
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 http://wiki.netbeans.org/CompatibilityPolicy to incorporate it
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.
Nice, thank you.
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.
Bytecode patching overhead in Basic IDE seems to be around 50msec, based on System.nanoTime. Not much but probably worth avoiding.
Can use META-INF/.bytecodePatched (generated by the AP) to avoid inspecting most class files. For reference, annotations in bytecode are described here: http://java.sun.com/docs/books/jvms/second_edition/ClassFileFormat-Java5.pdf
Y03: http://wiki.netbeans.org/CompatibilityPolicy#section-CompatibilityPolicy-SourceIncompatible
core-main #bef62bdad026
Integrated into 'main-golden', will be available in build *200901071401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/bef62bdad026 User: Jesse Glick <jglick@netbeans.org> Log: #155796: @PatchedPublic for easy bytecode patching.