Phones are a restricted environment. What could possibly be the point of shipping corba and swing on a phone? Jigsaw wasn't even a gleam in Mark Reinhold's eye when android was developed back then. They HAD to make a tradeoff, they didn't do it to piss of you or sun.
As a practical matter, android as a virtually complete java stack phone is about 100000000x more successful than j2me, which was a far more stripped down VM with far more of the very problems fragmented VMs lead to (being unsure of how certain APIs work without testing on an army of phones). It's true, there are certain classes in certain packages which are useful outside of the context implied by those packages. In a stand- alone device with absolutely no networking at all, java.net seems silly, but java.net.URI is still useful. In a headless terminal, some swing classes are still useful to resize images. You're running into this problem, and perhaps google could have shipped just those classes with android. However, BufferedImage and company are rather overengineered, and would have required inclusion of a heck of a lot more classes. They could have taken just the api part of ImageIO, and written their own implementation of it, but that's a rather minor nit in my book. On Jul 21, 12:41 pm, 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.
