Dynamic definition of Interface in java

asked 2014-03-26 03:47:02 -0700

PierreR gravatar image

updated 2014-03-26 09:30:48 -0700

The C++ API is pretty dynamic : one can create at runtime an Interface and add methods, signals and properties to it. It is also possible in C++ to call a method on an Interface that you don't know at runtime.

The java binding on the other hand, is really static : you need to define the Interfaces you are going to use during development, with appropriate annotations, to be able to call methods on it. Also you cannot create a new interface at run-time. As pointed , the annotation approach a some major advantages and is very conveninent in most cases.

However, I feel this approach is not always suitable :

  • in some environment, reflexion is not authorized (HGI - OSGI, for example)
  • sometimes, you really need dynamicity

Is there any rationnal behind this design ? is that a deliberate choic or just something that is not implemented yet ? I was looking at the code in InterfaceDescription.java as a starting point to implement such dynamicity, could you point me to some jni-binding issues I may encounter and that would make this more difficult than I thought it would be ?

edit retag flag offensive close merge delete

1 answer

Sort by ยป oldest newest most voted

answered 2014-03-26 09:06:54 -0700

georgen gravatar image


The design of the Java bindings is a result of the decision to expose AllJoyn interfaces as Java Interfaces. The C++ language does not have built in way to create interfaces. The best you can do is create a class with pure virtual functions that represents an interface. The Java language on the other had has the concept of Interfaces built into the language. Early on it was decided to expose the AllJoyn interface as a Java interface in the Java language bindings. To do this Annotations were added to the Java interface that could be read using reflection. The annotations provided the extra information needed to convert a Java interface to an AllJoyn interface.

This decision has some major benefits. When implementing a BusObject you are just implementing an interface. Implementing an interface is understood by the Java language and prevents the programmer from making some of the mistakes that are easy to make in C++. For example, if your AllJoyn interface has a method named Foo() and you map it with the name foo() (note difference in capitalization) it will not work. Since in C++ this is all done using strings the compiler will not catch the mistake. In Java you will get a compiler error. There are some other benefits. The biggest reason (to the best of my knowledge) was to make programming feel familiar for someone that primarily programs in Java.

The two major drawbacks of this early design decision are. 1. We don't have a way to generate a Java interface with all the required annotations at run-time this means the interface must be provided at compiler time. 2. Method calls are done synchronously. (This issue has a work around using concurrent callbacks and threads.)

So to answer you question. Java's inability to create interfaces via introspection is a result of an early design decision made to use Java's built in language interface to represent an AllJoyn interface. The design decision permeates the JNI code and is not simple to change. It may not be possible to implement run-time creation of AllJoyn interfaces in Java with out a major rework of the Java language bindings.

edit flag offensive delete publish link more


I totally agree with the major benefits of the annotation-based approach. The second drawback is not a big issue imho, as java has all the tools (java.concurrency, etc. ) to work around this. It's the first drawback that bugs me. I'll edit my question to add details about it.

PierreR ( 2014-03-26 09:20:41 -0700 )edit
Login/Signup to Answer

Question Tools



Asked: 2014-03-26 03:47:02 -0700

Seen: 424 times

Last updated: Mar 26 '14