#65 Standard library creation fails for Java Interfaces
It is currently not possible to create InjectJ
libraries (using the @inject export tags) from Java
interfaces
As soon as one attempts to do so, the following error
message shows up:
[javadoc] javadoc: In doclet class
de.fzi.injectj.util.doc.LibExtractionDoclet, method
start has thrown an exception
java.lang.reflect.InvocationTargetException
[javadoc] java.lang.NullPointerException
[javadoc] at
de.fzi.injectj.util.doc.LibExtractionDoclet.start(Unknown
Source)
[javadoc] at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[javadoc] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[javadoc] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[javadoc] at
java.lang.reflect.Method.invoke(Method.java:324)
[javadoc] at
com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:193)
[javadoc] at
com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:92)
[javadoc] 1 error
[javadoc] at
com.sun.tools.javadoc.Start.parseAndExecute(Start.java:311)
[javadoc] at
com.sun.tools.javadoc.Start.begin(Start.java:121)
[javadoc] at
com.sun.tools.javadoc.Main.execute(Main.java:41)
[javadoc] 1 warning
[javadoc] at
com.sun.tools.javadoc.Main.main(Main.java:31)
Logged In: YES
user_id=596852
I like to introduce some of my thoughts to this subject :
1. 'class' and 'interface' :
We add the class and interface models to the inject/j
language, coexisting with the current library model, this would
not be that much work to do, since we have a working semi-
objective approach at the current library model.
Pros:
- defined difference between libraries and classes
Cons:
- its not part of the inital model what we wanted (to be flat
and more "procedural").
or
2. As by now, interface methods are exported in libraries from
classes that implement these interfaces. You can't export the
interface itself with @export on interface comments, but you
can use them on method comments.
We may add a comment to the methodblock so the user can
see where they are coming from.
Pros:
- We keep our model
- REALLY easy to implement :-)
Cons:
- it may confuse an OO programmer to think that "libraries"
are in fact
classes.
3. I dont think introducing libraries with interfaces will lead
out of confusion, since programmers are always thinking in a
class model when using interfaces, especially java
programmers where interfaces can't take static
methods.
Logged In: YES
user_id=466738
Ok. My additional five pennies on the subject: I think we
have to separate clearly a) what an Inject/J programmer
"sees" as the object model (*the* model) and b) how it is
implemented on the Java side. So, allowing the export of
Interface methods does not necessarily mean having to have
interfaces on the Inject/J side.
The problem we are faced with here roots in an long-known oo
difficulty (parallel inheritance hierarchies) and a
limitation (without any negative meaning) of Java (single
inheritance). One way to tackle this problem is to use java
interfaces. However, in this case we need to be able to
export methods from java interfaces to Inject/J libraries
(or we drop the policy that only *model* classes can be
exported to libraries and allow the export of model.impl
classes - which I certainly do not favor).
Let's assume for a minute that we do allow export from
interfaces. What does that imply? Well, the dispatch
mechanism has to make sure that there is an actual object
that impelements the particular interface in order to invoke
the respective function. No other requirement is needed, or
am I mistaken? Whether the respective Inject/J object (the
library) is an interface on the java side and the java
object is called polymorphically or whether there is real
Java object to begin with, does not matter in my opinion.
Even more, we already have this situation: We allow export
of methods from pure abstract classes. There will never be
an object of type - say - ClassWeavepoint (abstract) but
only RecoderSourceClasses or the like. The same would be
true for Accesses.
What I propose is the following: We only export methods for
the specific acceses - MethodAccessWeavepoint,
VariableAccess, ... - or, if necessary - which I believe it
is - methods from the common base class AccessWeavepoint,
which are common to all accesses. The Inject/J machinery has
to make sure (it already does) that whenever I have an -
say - MethodAccessWeavepoint on the Inject/J side and invoke
its functions, a corresponding RecoderMethodAccess object (
which will then implement the interface
MethodAccessWeavepoint) is available.
Logged In: YES
user_id=596852
Ok. Got your point.
I will check your proposal on our current model and let you
know (after my exam tomorrow)!