Android

[Peter Firmstone <ji...@zeus.net.au>]

Interesting articles.

http://www.osgi.org/blog/2007/11/android-and-osgi.html

http://groups.google.com/group/android-developers/browse_thread/thread/c78d29308d8d48a2/e5516fdcb5e528f2

Android is based on Harmony, the Serialized form of the platform classes 
that exist in Android are the same as Java's.  If the Dalvik class dex 
files are wrapped in a Jar, they can be dynamically loaded.

So in theory at least, it should be possible to serialize objects back 
and forth between Android and Java, so long as the correct class files 
are loaded at each end.

Imagine that.

Peter.

Re: Android

[Peter Firmstone <ji...@zeus.net.au>]

Fabrizio Giudici wrote:
> Indeed, I thought that one could add them by means of the Maven shade
> plugin trick, or similar stuff. But you made me realize that we're
> sharing the same code between the peers, and thus we can't have RMI
> stuff renamed. Unless it's possible to write some sort of filter to
> the serialized data where names are again converted on the fly... but
> it sounds definitely cumbersome.
>   
Funny you mention filters, I've got classes that extend 
ObjectInputStream and ObjectOutputStream that do just that.

See net.jini.io.* on SVN for details.

It converts the names of net.jini.io.MarshalledInstance and 
java.rmi.MarshalledObject and serialVersionUID's for Java CDC.

java.rmi.Remote is a marker interface, there might be some way to do 
without it, via some sort of replacement, I'm not confident though.

I've been thinking about a new URL scheme for annotating codebases.  
Currently the sender doesn't know the platform implementation at the 
remote end, so the appropriate codebase to utilise there should be 
determined by a combination of a package name and perhaps version and 
the local platform.  The appropriate codebase could be provided via a 
codebase service rather than an http server.

OSGi also has a need to determine the most appropriate ClassLoader for 
Serialization, at the moment there is no suitable mechanism, we might be 
able to provide it.

If you're willing to help we can give it a try, its not something I 
alone have the resources to deal with.

I'm starting to believe that Services should have a separate 
"ServiceInterface" jar, proxy's servers and clients can all share common 
interfaces.

If Apache River were to have a public codebase service that vetted, 
signed and distributed these ServiceInterface jar's they could be 
utilised by parties unknown to each other to cooperate.  Service 
Interfaces can be placed high up in the ClassLoader hierarchy, so 
they're visible to all proxies and clients, enabling many different and 
varied implementations of each.

Cheers,

Peter.

Re: Android

[Fabrizio Giudici <fa...@tidalwave.it>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 5/16/10 20:42 , Peter Firmstone wrote:
> Thanks Fabrizio, your insight's much appreciated.
>
> I sincerely hope for all Java client developers sake, that Oracle
> does place some very serious efforts behind Mobile Java, otherwise
> I fear they will loose out to Android.
>
> Patrick is spot on, the only way that Android "might" participate
> in a djinn is via Surrogate.
>
> Android is missing the most important piece of the puzzle:
>
> java.rmi.Remote java.rmi.RemoteException

Indeed, I thought that one could add them by means of the Maven shade
plugin trick, or similar stuff. But you made me realize that we're
sharing the same code between the peers, and thus we can't have RMI
stuff renamed. Unless it's possible to write some sort of filter to
the serialized data where names are again converted on the fly... but
it sounds definitely cumbersome.

- -- 
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
java.net/blog/fabriziogiudici - www.tidalwave.it/people
Fabrizio.Giudici@tidalwave.it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvweBAACgkQeDweFqgUGxfGZQCghcZTtcDawoS1Po8YmaGbRKbl
2OsAnisDwK7mF4H1FnFajqGSM8ko7LQG
=GulH
-----END PGP SIGNATURE-----

Re: Android

[Peter Firmstone <ji...@zeus.net.au>]

Thanks Fabrizio, your insight's much appreciated.

I sincerely hope for all Java client developers sake, that Oracle does 
place some very serious efforts behind Mobile Java, otherwise I fear 
they will loose out to Android.

Patrick is spot on, the only way that Android "might" participate in a 
djinn is via Surrogate.

Android is missing the most important piece of the puzzle:

java.rmi.Remote
java.rmi.RemoteException

Instead android has a form of RPC called AIDL and something similar to 
Serializable called Parcelable, which requires the creation of idl 
files.  Looks like they're dealing with stub's too.

http://developer.android.com/guide/developing/tools/aidl.html

They also have some sort of Service interface, I don't know much about 
it, how its discovered etc.

Serializable is reported to work for some classes, not documented, must 
be tested etc.

http://developerlife.com/tutorials/?p=288

Cheers,

Peter.

Fabrizio Giudici wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I'm developing with Android since one month and since I've worked with
> Jini maybe I can give some points (all... to be taken with a pinch of
> salt).
>
> 1. The .dex thing is sometimes transparent, other times not
> transparent for what concerns classloaders. OTOH, as reported OSGi
> runs on Android and for sure it makes use of classloaders, so problems
> should be resolvable.
> 2. The runtime libraries aren't the entire Java runtime. Not only you
> entirely miss Swing, but also some parts of the low-level stuff. For
> instance, there's no java.bean.Introspector (not that this must be
> related to River, just a point).
> 3. I've been able to reuse some code I had and that made use of a few
> basic infrastructure APIs of the NetBeans Platform. I had some
> troubles, mainly because of a kitchen-sink problem of one of the
> classes (which brings in a lot of dependencies on AWT/Swing even
> though I don't need them). With a bit of patience, this has been
> solved by stubbing the required classes and using the Maven shade
> plugin (which is able to rename classes and packages in jars) to have
> them accepted by the runtime (you're forbidden to embed java.* classes
> on your app of course).
> 4. I'm using serialization internally to my application - I've seen
> some strange warnings in the logs, but it was fine. I've also read
> something around about people that tried serialization over the
> network against a plain Java, and had some issues.
>
> In the end, I think that running River on Android could be possible,
> with some work and maybe giving up to some functions. But it's one of
> those things that need to be tried.
>
>
> PS On a matter of perspective, even though I'm not an expert in
> scenario forecasts. I've been and I am a great advocate of JME, in
> spite of all its known troubles. But unless Oracle gives a big push,
> change the overall process about managing and evolving it, and
> considering the Android adoption rate, there are high chances that in
> a few years if you have to fact with Java(-like) on mobile stuff, it
> will be Android.
>
> - -- 
> Fabrizio Giudici - Java Architect, Project Manager
> Tidalwave s.a.s. - "We make Java work. Everywhere."
> java.net/blog/fabriziogiudici - www.tidalwave.it/people
> Fabrizio.Giudici@tidalwave.it
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkvv8x4ACgkQeDweFqgUGxcVeACeIIE1WQOXXXWeFtZ2eKqeBoQ3
> E+QAoKYkIrQYLfTDrzgZjUCsVz0R5gfY
> =ObYN
> -----END PGP SIGNATURE-----
>
>
>   

Re: Android

[Fabrizio Giudici <fa...@tidalwave.it>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm developing with Android since one month and since I've worked with
Jini maybe I can give some points (all... to be taken with a pinch of
salt).

1. The .dex thing is sometimes transparent, other times not
transparent for what concerns classloaders. OTOH, as reported OSGi
runs on Android and for sure it makes use of classloaders, so problems
should be resolvable.
2. The runtime libraries aren't the entire Java runtime. Not only you
entirely miss Swing, but also some parts of the low-level stuff. For
instance, there's no java.bean.Introspector (not that this must be
related to River, just a point).
3. I've been able to reuse some code I had and that made use of a few
basic infrastructure APIs of the NetBeans Platform. I had some
troubles, mainly because of a kitchen-sink problem of one of the
classes (which brings in a lot of dependencies on AWT/Swing even
though I don't need them). With a bit of patience, this has been
solved by stubbing the required classes and using the Maven shade
plugin (which is able to rename classes and packages in jars) to have
them accepted by the runtime (you're forbidden to embed java.* classes
on your app of course).
4. I'm using serialization internally to my application - I've seen
some strange warnings in the logs, but it was fine. I've also read
something around about people that tried serialization over the
network against a plain Java, and had some issues.

In the end, I think that running River on Android could be possible,
with some work and maybe giving up to some functions. But it's one of
those things that need to be tried.


PS On a matter of perspective, even though I'm not an expert in
scenario forecasts. I've been and I am a great advocate of JME, in
spite of all its known troubles. But unless Oracle gives a big push,
change the overall process about managing and evolving it, and
considering the Android adoption rate, there are high chances that in
a few years if you have to fact with Java(-like) on mobile stuff, it
will be Android.

- -- 
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
java.net/blog/fabriziogiudici - www.tidalwave.it/people
Fabrizio.Giudici@tidalwave.it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvv8x4ACgkQeDweFqgUGxcVeACeIIE1WQOXXXWeFtZ2eKqeBoQ3
E+QAoKYkIrQYLfTDrzgZjUCsVz0R5gfY
=ObYN
-----END PGP SIGNATURE-----

Re: Android

[Peter Firmstone <ji...@zeus.net.au>]

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
>
>   

Re: Android

[Patrick Wright <pd...@gmail.com>]

>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