>VM, I think it's really unforgivable the choice of Google of fragmenting de 
>facto Java with a stripped down version of the runtime.

Aren't we used to this, by now? GWT & GAE are incomplete JRE's as
well. It's a trade-off, not an insurmountable problem. When Oracle
comes out with a full mobile Java 5 runtime, we can switch to that...

Moandji

On Wednesday, July 21, 2010, Fabrizio Giudici
<[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 7/21/10 09:38 , Wildam Martin wrote:
>> Hi folks,
>>
>> What I am still missing is an overview of what classes are
>> available on the Android as I am pretty sure that not every Java
>> application can be converted to Android without error. And second:
>> Is that Android package created by NetBeans automatically in the
>> dist folder if I do an Android project using the plugin
>> (http://wiki.netbeans.org/IntroAndroidDevNetBeans - unfortunately
>> this is an old entry at the NetBeans Wiki and I don't know if
>> still applicable)?
>>
>> But basically I would just like to know the limitations of Android
>> as I expect customers asking what could be done on the Android
> You probably don't realize, but you've asked a $100,000 question (not
> a million, indeed, but just a magnitudo below). :-) While I understand
> the reasons (which are not only technical, BTW) to have a different
> VM, I think it's really unforgivable the choice of Google of
> fragmenting de facto Java with a stripped down version of the runtime.
> Some things are obviously missing (e.g. Swing and AWT UI classes),
> some aren't so obvious (BufferedImage is AWT, but it's a model class
> and could frankly stay). Figure it out that I was happy to have
> written a 100% Java codec (for proprietary camera raw manufacturers
> formats such as Nikon or Canon) and it's currently impossible to run
> it on Android because there's no BufferedImage and related stuff.
> Also, depending on the Android version, you'll also miss some parts of
> the XML library (e.g. XPath, only introduced in 2.2), while other
> present parts could be bugged and not working in some cases.
>
> So you figure out, either you find something that has tried what you
> need and documented its status, or you have to go with trial and
> error. I'm going that way, slowly introducing parts of what I need,
> testing carefully, and then moving to the next step. I should be able
> to finish a DZone post today about using a RDF store on Android.
>
> The way I'm following with Android to try/fix needed libraries that
> couldn't run out-of-the-box is based on the static manipulation of
> bytecode, by means of the Maven shade plugin. It's a plugin that takes
> a jar as input, can strip or add some classes/resources, above all it
> can replace references. So, if you run into a library that e.g. needs
> javax.swing.ActionListener, you can take the existing implementation
> (from a FLOSS source) or write your own, then you need to put it into
> a different package (you can't embed java*, javax* stuff into your app
> for obvious security reasons), for instance it.tidalwave.javax.swing,
> and then use the shade plugin for patching the needed library so that
> it searches for it.tidalwave.javax.swing in place of javax.swing. For
> instance, I was able to patch some XML stuff in this way to have the
> initial parts of the OpenSesame RDF store running (for details wait
> for my post, or check out the sources of blueBill Mobile).
>
> It's really a boring approach, since it's trial and error and there's
> always the risk that you run into a showstopper problem. But so far it
> has worked and it allowed me to reuse or to write perfectly portable
> code. In the next weeks I'll try whether it works also with
> BufferedImage (so I can reuse my imaging libraries) and with more
> parts of the NetBeans Platform (I'd really like to use the Node and
> FileSystem abstractions).
>
> PS I can't tell you how the NetBeans plugin for Android works - as
> anticipated I use Maven and NetBeans works pretty well with it, even
> though for all the resource management of Android (manifest etc...)
> you have to go in manual mode.
>
>
> - --
> Fabrizio Giudici - Java Architect, Project Manager
> Tidalwave s.a.s. - "We make Java work. Everywhere."
> java.net/blog/fabriziogiudici - www.tidalwave.it/people
> [email protected]
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkxGzugACgkQeDweFqgUGxeI/gCfbdre2lcIRvzTq+yBEMAyEwv9
> BxYAn2FsGl+kbq5NI2vk8+QxklNojT9n
> =LnYM
> -----END PGP SIGNATURE-----
>
> --
> You received this message because you are subscribed to the Google Groups 
> "The Java Posse" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to 
> [email protected].
> For more options, visit this group at 
> http://groups.google.com/group/javaposse?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Reply via email to