Potentially replace argument List with Collection, Iterable, or Set: ByteBuddy#makeInterface, possibly other methods about byte-buddy

[raphw]

This choice was made as the order in which the interfaces are declared is exposed via the reflection API. Because of this, it may affect code that uses reflection. Requiring lists should reflect this consequence.

Let me however think about it, I might adapt a different signature.

[rgoldberg]

If a List is passed as the argument to ByteBuddy#makeInterface(Collection), any iteration done inside the method will still be performed in the List order. So, since the method (and everything that it calls) only uses size() & iterator(), a (Collection) method will behave equivalently for a List argument as a (List) method.

The JavaDoc doesn't specify that the super interfaces will be declared in the order of their occurrence in the List, and it doesn't say how duplicates are handled (I would assume that an interface will be declared in the order of its first occurrence in the List). The same would hold true if you change the signature to (Collection c), and just specify that an interface will be declared in the order of it first occurrence in c.iterator(), which, for List, is obviously exactly the same as the order in the List itself.

If I, as the caller, don't care about the order of the interface declarations (or if I care about the order, but just want to specify it via some other Collection, like a SortedSet), why should makeInterface(...) care?

[raphw]

I have adopted your suggestion with some additional validation of the input which was meaningful for lists that can (illegally) contain duplicates even though it would not be allowed. I adapted this throughout all of Byte Buddy's API where it appeared meaningful, i.e. where the order of arguments does not always have a meaning. I will soon push an updated version. Thanks for your input.

[rgoldberg]

Thanks for updating the API so quickly.

One additional makeInterface method might be useful.

Right now, you have:

makeInterface(Collection<? extends TypeDescription> typeDescriptions)

It would be simpler for a caller who just has Collection<Class<?>> to be able to call:

makeInterfaceFromClassCollection(Collection<Class<?>> classColl)

You can probably come up with a better name than makeInterfaceFromClassCollection; I just had to pic something that was different from makeInterface to avoid a duplicate method signature due to type erasure.

[raphw]

You are right. Initially, I did not want to do it because I wanted to avoid polluting the API with additional method names. However, I will now add overloaded methods based on Iterable:

makeInterface(Iterable<? extends Class<?>> types)

[raphw]

The changes are now in place.

[rgoldberg]

Thanks.