Create Interface (not class) about byte-buddy

[raphw]

Hi David, your aproach is correct. If it throws a NullPointerException, you found a bug. ByteBuddy should never do this. I will test it later and might ask for a more detailed description. Expect a bugfix realease at the end of next week.

For creating a root interface, you would subclass Object and define the modifier to represent an interface, on the byte code level, interfaces are represenred as Object subclasses. I will add a specific DSL element for that.

Thanks for using Byte Buddy and for your feedback. I am working on additional documentation and hope to make Byte Buddy easier in the future.

[raphw]

Interfaces do not add the super flag which, until now, were always added to subclasses, including interfaces. Also, the default implementations of ConstructorStrategy did not consider the possibility of interfaces where the super classes are considered null. Both was fixed.

[raphw]

Byte Buddy 0.5.2 is released and it fixes the bug you found. Note that interface methods must be public. Also, implementations are only allowed on from Java 8.

[DALDEI]

Could you explain the last bit "Also, implementations are only allowed on from Java 8." ?
For various reasons I need to stay on Java 7 for a while more.

[raphw]

I mean a default method implementation. When you define an interface method, it needs to be abstract as long as the byte code version is not 52 (Java 8) where you can optionally provide an implementation (also for static methods).

[DALDEI]

Ah yes of course ! Cant create bytecode for a JVM version thats compatible with the running one.
Just tried the new code, works perfect !
Took a few mistakes (mine) to get it right ... (missed at first that the function(Type...) could take no args) and then copy pasted the wrong code and put a field instead of a method.
But got it right!
Thank you !

Future request ... (way future) ... validate builder operations as they occur
as well as during make() /load(). By the time it gets to load the message has less
context so is harder to track down - both by the exception itself and by the stack track.
In this case my mistake caused an 'incompatible change' ... yes. which one ?
considering I had only 1 it wasnt too hard , but catching that I'd added a field
to an interface during the build process would be more useful - and slower :( :)