Well, splitting off colour, bufferedimage, and stream-image-to-png/jpg/ etc would be moved to a new package, and all the existing swing stuff will wrap calls to that. This new package forms the core of a new module, dedicated JUST to image manipulation, not to rendering any of it. It doesn't have to be done that way, jigsaw specifically, for example, supports split packages, so the existing BufferedImage, java.awt.Color, etc can remain and be part of the gfx manipulation module, with java.awt.Button part of the "awt" module.
If big screen android tablets do become available, and android did not support swing, then no doubt oracle might lean on google to start work on that, and the community would doubtless agree with them and possibly contribute an android implementation of the swing module. XPath support, and in fact any XML parsing of any nature, is clearly something that should be modularized, and should NOT be on the "must be there to call yourself core java" list. What good is XML parsing on a 64k memory 1Mhz processor Arduino? It would be a pointless waste of dollars worth of ROM just to store the libraries, and it'll probably just fail with an OOME. Assuming the implementation of this module isn't really strange, and the module is stand-alone available, then adding it to your android app should not be difficult, with the biggest downside the need to compile the entire thing into your own app, inflating the size a bit. But that's clearly the world we ought to be moving to: The model that there's a benevolent dictator that points at certain libraries and decrees them as both (A) having an completely and irrevocably finalized API, which can never, ever, ever change again, and (B) being so important that all distributions of java, for any scenario and on any device, must have it installed before you even run so much as Hello World, seems, when you put it like that, insane. I see jigsaw / modularization as a core service of the language, as tightly integrated as garbage collection is on java, as a holy grail that's far more likely to result in the next big thing than some (admittedly decently) cleaned up syntax in a language that offers nothing new of this calibre. And no, Kevin, don't you dare hijack this thread. You can start a new one if you want. I wholeheartedly agree with you that its a bit annoying that google rolled their own libraries for image manipulation, but as long as the image manipulation classes are split across the javax.swing and java.awt packages, with fairly tight integration with swing and awt in general, I understand why they did it: Point me at a free and open source library that contains just the image manip stuff from java.awt and javax.swing and I'll gladly open an android support ticket to add it. Right now half the image manip stuff I try fails with a HeadlessException on my aws server, even though the code in question doesn't need a GUI! For example, there's on ubuntu a headless version of the jre, but there is no headless version of the jdk; apt-getting it will install half of X, even though on for example a micro aws box that's not desirable and not something you'd ever run. Fortunately it's just wasted disk space and nothing else. If this stuff had been sorted out properly, I'm guessing google wouldn't have felt the need to ship their own image manip, or omit it altogether. On Sep 12, 6:43 pm, Fabrizio Giudici <[email protected]> wrote: > -----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.
