river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Android
Date Sun, 16 May 2010 00:39:52 GMT
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.



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

View raw message