Surrogate would be easier, it allows the classes to be restricted to
available java platform classes that have compatible serialized form and
doesn't rely on dynamic classloading.
However it appears possible (needs further investigation, just planting
the seed) to create *-dl.jar files that contain Dalvic bytecode instead
of JVM bytecode (which would also require River platform Dalvic
bytecode) and have the benefits of Dynamic Class Loading too ( Android
supports dynamic class loading of Dalvic bytecode from jar files).
So it seems possible for Android to participate in a djinn with Java,
because of the common Serialized form of existing Java classes present
in Android (in spite of bytecode and VM differences).
The Java platform is fragmented, there are several GUI frameworks,
ServiceUI was built to handle multiple GUI or the absence of a GUI
framework. I'd like to do the same and figure out a new location
independent URL scheme for obtaining dl.jar archives without
obstructing, but allowing developers to deal with different platforms.
Currently we just ignore the issue.
Time will tell whether it makes sense to support Android, it might be a
passing fad, or it may gain significant market share, who knows.
Android itself doesn't appear to fix issues present in Java, it looks
like a clone, with different bytecode, VM and UI.
I'd personally prefer a CDC platform that supports Java 5 language features.
Survival is the most important thing in the IT world, I don't think we
can afford to restrict River. I've used Sun Sparc Workstations ever
since the nineties, however, now they no longer exist. Once, they had
the potential to be everywhere, same story for others like the Amiga.
Now we face a new future where the PC too will become marginalised by
mobile and embedded platforms with sufficient memory and compute power.
Server's will always be around, but to be noticed, River needs to be on
the client too.
Cheers,
Peter.
Patrick Wright wrote:
>From what I've read (and is repeated here:
http://en.wikipedia.org/wiki/Dalvik_virtual_machine), Dalvik has its
own bytecodes suitable for a register-based VM. I haven't heard that
it can read Java class files (regardless of the source) directly; I
believe you have to convert them using the dex converter tool.
Even though Android source looks like Java (with some JDK classes
unavailable), for the purposes of Jini, it seems more like just
another foreign language which would need a surrogate to communicate
with Java-based Jini services, no?
Patrick
