ignorant, incompetent boobs... or what?
Usually I avoid ranting, at least on my blog entries. Thing is, negative
output creates negative image: there is little positive in negativity.
If you have nothing good to say, say nothing, and so on.
But sometimes enough is enough. This is the case with Google, and their
pathetic attempts at Creating Java(-like) platforms.
1. Past failures: Android
In the past I have wondered at the clusterfuck known as Android: API is
a mess, concoction of JDK pieces included (and mixed with arbitrary open
source APIs and implementation classes) is arbitrary and incoherent. But
since I don't really work much in the mobile space, I have just shook my
head when observing it -- it's not really my problem. Just an eyesore.
But it is relevant in that it set the precedent for what to expect:
despite some potentially clever ideas (regarding the lower level
machinery), it all seems like a trainwreck, heading nowhere fast. And
the only saving grace is that most mobile development platforms are even
worse.
2. Current problems: start with ignorance
After this marvellous learning experience, you might expect that the big
G would learn from its mistakes and get more things right second time
around. No such luck: Google
App Engine was a stillbirth; plagued by very similar problem as
Android. Most specifically, significant portion of what SHOULD be
available (given their implied goal of supporting all JDK5 pieces
applicable to the context) was -- and mostly still is -- missing. And
decisions again seem arbitrary and inconsistent; but probably made by
different bunch of junior developers.
My specific case in point (or pet peeve) is the lack of Stax
API on GAE (it is missing from white-list, which is needed to load
anything within "javax." packages). It seems clear that this was mostly
due to good old ignorance -- they just didn't have enough expertise
in-house to cover all necessary aspects of JDK. Hey, that happens: maybe
they have no XML expertise within the team; or whoever had some
knowledge was busy farting around doing something else. Who knows?
Should be easy to fix, whatever gave.
3. From ignorance to excuses
Ok: omission due to ignorance would be easily solved. Just add
"javax.xml.stream" on the white list, and be done with that. After all,
what could possibly be problematic with an API package? (we are
not talking about bundling an implementation here)
But this is where things get downright comical: almost all
"explanations" center around the strawman argument of "there must be
some security-related issue here". I may be unfair here -- it is
possible that all people peddling this excuse are non-Googlians (if so,
my apologies to GAE team). But this is just very ridiculous (dare I say,
retarded?) argument, because:
-
Being but an API package, there is no functionality that could
possibly have security implications (yes, l know exactly what is
within those few classes -- the only actual code is for implementation
discover, which was copied from SAX), and
-
If there are problems with implementations of the API (which should be
irrelevant, but humor me here), same problems would affect already
included and sanctioned packages (SAX, DOM, JAXP, bundled Xerces
implementation of the same)
Perhaps even worse, these "explanations" are served by people who seem
to have little idea about package in question. I could as well ask about
regular expression or image processing packages it seems.
4. Misery loves company
About the only silver lining here (beyond my not having to work on
GAE...) is that there are other packages that got similarly hosed (I
think JAXB may be one of those; and many open source libraries are
affected indirectly, including popular packages like XStream).
So hopefully there is little bit more pressure in fixing these flaws
within GAE.
But I so hope that other big companies would consider implementing
sand-boxed "cloudy" Java environments. Too bad competitors like
Microsoft and Amazon tend to focus on
other approaches: both doing "their own things", although those being
very different from each other (Microsoft with their proprietary
technology; Amazon focusing on offering low-level platform (EC2) and
simple services (S3, SQS, SWF -- simple storage, queue, workflow service
-- etc), but not managed runtime execution service.