-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On the whole I agree with you (about the general idea of modularize, so you don't force people to have all the rt.jar to call a thing "Java"), but I disagree with some points. In particular regarding AWT/Swing:
1. There are not only the UI classes, but the model classes. In particular, BufferedImage, Color, and all the friends. Given that one common thing that people would do with a smartphone is to manipulate images, one could immediately reuse tons of imaging stuff from the Java world. For instance, I have written codecs for some popular proprietary formats by camera manufacturers and, given that you can buy an sd card with WiFi capabilities, you can send in real time a photo taken by a camera to a smartphone. In fact, there is an Android app with this capability, only that it just supports JPEG. Personally, I'd have a number of smart things that could be done with my camera and my droid and that I could implement in a very short time if I could reuse my current imaging libraries. There's really *no* technical reason for not having BufferedImage and friends on Android and the fact that Google didn't put sucks a lot - since we're talking of innovation and community, it's really limiting my freedom to innovate, in the sense that it raises the cost bar for me too much. BTW, BufferedImage and friends is also missing from GAE and that's why I say that Google deliberately decided to fragment the Java world and caused some damage at least to a part of the developers. 2. While I reckon there's little sense in having Swing running on my Droid, things could be really different when talking of the upcoming tablets. When we start talking of devices with graphic capabilities of 1024x600 and above, it might make sense that some existing Swing software is ported. Especially considering that AFAIK Android still misses complex components such as table, trees, treetables, calendars, etc. Please, let's not give dummy rationales such as "the app would not look consistent with the L&F of Android". Yes, it's right, but let's give the final word to the developer. Maybe in some cases it would work fine all the way for what the developer has in mind and would make it possible to roll out a solution quickly and with a low cost. There's nothing that can kill innovation or freedom such as paternalism. 3. Even though this is probably no more true since 2.0, there were other parts missing from the runtime. For instance, AFAIK there were no XPath support for older SDKs - I had to tweak in some third parties' libraries such as JDom and Jaxen to have it working. What is frankly annoying is that I've not read in any place a rationale on why Google decided not to support BufferedImage on Android and GAE. One would expect that a corporate who's such a great attitude towards the community would talk more about this, right? - -- 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/ iEYEARECAAYFAkyNA0AACgkQeDweFqgUGxc2OwCfSMecGJwI9Ue+7uqmQm6Yfy5g 0hUAoJUYOkORjIlttcjTs8H9+i4dLL+d =iji7 -----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.
