You cant extend ByteBuffer and thanks God for.
You cant extend b/c there are no protected c-tors. Why thank god part? Well, having only 2 real subclasses ensures that the JVM can Heavily optimizes any code involving ByteBuffer.
Last, if you need to extend the class for real, edit the byte code, and just add protected attribute the c-tor and public attribute to DirectByteBuffer (and DirectByteBufferR). Extending the HeapBuffer serves no purposes whatsoever since you can access the underlying array anyways
use -Xbootclasspath/p
and add your own classes there, extend in the package you need (outside java.nio). That's how it's done.
Another way is using sun.misc.Unsafe and do whatever you need w/ direct access to the memory after address()
.
I would want to do that for
performance reasons - getInt for
example has about 10 method
invocations, as well as quite a few
if's. Even if all checks are left, and
only method calls are inlined and
big/small endian checks are removed,
tests that I've created show that it
can be about 4 times faster.
Now the good part, use gdb and check the truly generated machine code, you'd be surprised how many checks would be removed.
I can't imagine why a person would want to extend the classes. They exist to allow good performance not just OO polymorph execution.
edit:
How to declare any class and bypass Java verifier
On Unsafe: Unsafe has 2 methods that bypass the verifier and if you have a class that extends ByteBuffer you can just call any of them. You need some hacked version (but that's super easy) of ByteBuffer w/ public access and protected c-tor just for the compiler.
The methods are below. You can use 'em on your own risk. After you declare the class like that you can even use it w/ new keyword (provided there is a suitable c-tor)
public native Class defineClass(String name, byte[] b, int off, int len, ClassLoader loader, ProtectionDomain protectionDomain);
public native Class defineClass(String name, byte[] b, int off, int len);
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…