Forgot your password?
typodupeerror
Java Programming Sun Microsystems

Sun's Phipps Slams App Engine's Java Support 186

Posted by samzenpus
from the you're-both-pretty dept.
narramissic writes "Sun Microsystems' chief open source officer, Simon Phipps, said in an April 11 blog post that Google committed a major transgression by only including support for a subset of Java classes in its App Engine development platform. 'Whether you agree with Sun policing it or not, Java compatibility has served us all very well for over a decade,' Phipps wrote. 'That includes being sure as a developer that all core classes are present on all platforms. Creating subsets of the core classes in the Java platform was forbidden for a really good reason, and it's wanton and irresponsible to casually flaunt the rules.' Phipps characterized his remarks as non-official, saying: 'This isn't something I could comment on on Sun's behalf. My personal comments come purely from my long association with Java topics.'"
This discussion has been archived. No new comments can be posted.

Sun's Phipps Slams App Engine's Java Support

Comments Filter:
  • by tomhudson (43916) <barbara.hudson@D ... com minus painte> on Monday April 13, 2009 @05:57PM (#27563659) Journal

    Seems to me they should put their money where their mouth is...

    Sun *DID* put their money where their mouth is. They developed java, then GPL'd it. They bought StarOffice, the GPL'd it.

    Google, on the other hand, is an advertising company that is trying to get lock-in, same as Microsoft did with their proprietary java extensions long long ago ...

  • by seifried (12921) on Monday April 13, 2009 @05:59PM (#27563685) Homepage
    I think Sun is jealous, they have been pushing grid computing for ages and it's been a flop for them. Google is most likely going succeed here, especially with a "good enough" solution which no doubt pisses of Sun/Sun employees (who have a tendency to go for the engineering "ideal" solution which often results in a very nice and extremely pricey product). Witness the container computing stuff, Sun is making a big deal about seismic tests, and Google is quietly deploying hundreds of these things in their data centers. Sun seismic test [youtube.com] vs. Google data center tour [youtube.com]. I bet for most of us Google's Java AppEngine implementation will be "good enough".
  • by AKAImBatman (238306) * <akaimbatman.gmail@com> on Monday April 13, 2009 @06:00PM (#27563705) Homepage Journal

    As someone who personally loves the Java platform, I honestly think he's making a mountain out of a molehill. As far as I've been able to tell so far, the Google App Engine supports the Java platform in its entirety, with a few caveats. Those caveats deal with the services Google offers (e.g. no JDBC accessible database) and the sandbox the apps run in (e.g. no network support, no filesystem).

    AFAICT, there's nothing stopping me from, say, writing a JDBC access layer for their Data Store. Which means that Google is keeping with the spirit of the platform, and that this is mostly just a misunderstanding.

    If you want real problems, try running Java apps on a shared hosting provider sometime. The limitations of those sites will have you shouting praise for what Google is offering.

  • by bogaboga (793279) on Monday April 13, 2009 @06:02PM (#27563717)

    I realize it's now too late but if it were a few years ago, SUN should have considered changing Java's license to make sure that whoever supports Java, supports it in its entirety.

  • Like J2ME/CLDC? (Score:4, Interesting)

    by Anonymous Coward on Monday April 13, 2009 @06:02PM (#27563723)

    CLDC, the bastardized, stripped version of Java the Sun blessed and which is still the standard on many phones broke the whole "run anywhere" paradigm.

    Still causes us major problems since Sun still supports and condones it despite the fact that almost all systems now could easily support a real Java version.

  • by pohl (872) on Monday April 13, 2009 @06:22PM (#27563917) Homepage

    Hmm...I wonder why they never complained about the limited subset of classes that GWT supports [google.com] in client-side code.

  • by IamTheRealMike (537420) <mike@plan99.net> on Monday April 13, 2009 @06:23PM (#27563931) Homepage

    The java-subset thing seems like a bad idea; and I'd be curious to know why they did it; but I don't see how a platform subset is a good basis for a lock-in strategy.

    Yeah, this is garbage. Watch the "campfire" videos, a boringly large part of the presentations is given over to how you are not locked in, because AppEngine exposes the standard Java servlet container and database access APIs even though it's based on BigTable which is not a standard database. They show how the guestbook app can be taken right across to run on WebSphere with no code changes. The design of Java on AppEngine is pretty much the opposite of lockin - they've clearly put a lot of effort into ensuring a very, very different underlying system can export the standard Java APIs.

    As to why it's a subset, I guess the same logic as applied to the Python implementation which is also a subset - due to the way it works the classes need to be audited for security problems. Some of the Java APIs contain native code which probably has to be rewritten or at least very carefully audited to ensure you can't break out of the sandbox. And some I guess just aren't that useful. But I don't really know the reason.

  • by sohp (22984) <.moc.oi. .ta. .notwens.> on Monday April 13, 2009 @06:34PM (#27564035) Homepage

    What Google should have done was engage in the JCP to define a new profile for supported "device", along the lines of the CDC/CLDC and MIDP. At least that way it would have been within the framework of practice understood and used by Java developers. Instead, Google just said "here's what's available", without tying into any of the already available accepted ways of defining a subset of Java.

    This actually looks a lot like what Microsoft got in trouble for with their MS Java.

  • by ultrabot (200914) on Monday April 13, 2009 @06:37PM (#27564059)

    We'd be worried about Microsoft attempting to create an MS-only ghetto that they lock people into

    Like .NET?

    For most parts, /. seems to be pretty much ignoring what msft is doing these days, as far as server technologies are concerned.

  • by betterunixthanunix (980855) on Monday April 13, 2009 @06:38PM (#27564075)
    I hate it when people make snide comments about high quality engineering. Yes, it is possible to hack together a "good enough" system that is fine for consumers and some businesses, but for a lot of applications, a well engineered system is important. In the case of the containers, there are plenty of reasons why you might want to know the seismic test results: maybe you are deploying the container to replace some emergency services IT infrastructure in an earthquake zone, and need to be ready for aftershocks; maybe you just want to transport the datacenter on a railroad, and want to know how well it will hold up while it is jostled around on a flatbed car; maybe you need a datacenter to function onboard a ship, and want to know what effect choppy seas might have.

    Where were all these comments when Sun went after Microsoft for this sort of behavior? Back then, everyone seemed eager to watch Sun "stick it to" Microsoft; but when Google is the target of criticism, suddenly the fault lies with Sun. Windows is also "good enough" for most people (and Visual J++ was intended for Java development in Windows), so why treat it differently than AppEngine?
  • Re:Like J2ME/CLDC? (Score:3, Interesting)

    by israfil_kamana (262477) <christianedwardg ... m ['l.c' in gap]> on Monday April 13, 2009 @06:52PM (#27564231) Homepage

    Heh. I had to write an IoC container that would run on CLDC 1.1. Fun fun fun. No Serializable meant I had to re-compile all my code. Love that fragile base-class problem.

  • by DragonWriter (970822) on Monday April 13, 2009 @06:55PM (#27564261)

    Sun's problem is that the reverse isn't true.

    Sun's problem is that they are working up to the general launch of their cloud computing services, and Google AppEngine supporting more than just Python makes it that much harder for any new launch to get traction.

  • by Chyeld (713439) <chyeld@@@gmail...com> on Monday April 13, 2009 @07:06PM (#27564359)

    If you are developing for the App Engine, does it matter the flavor of the error? If you aren't developing for the App Engine and you are just looking to port something you've already written over, shouldn't you be reading the documentation concerning it first?

    Developer-wise, this should be a non-issue. Unless you were expecting things to just plug in directly, coding to match how the App Engine works was a given anyway.

    I agree with the others who opine that this is simply sour grapes from someone too late to the race to have a chance at first place.

  • by burris (122191) on Monday April 13, 2009 @07:09PM (#27564379)

    Google isn't calling their product Java. Google's product is called AppEngine. Google is free to say that AppEngine has "Java(TM) Language Support" without getting permission from Sun or anyone else.

    Trademark isn't an absolute monopoly on the mark.

  • by shutdown -p now (807394) on Monday April 13, 2009 @07:29PM (#27564551) Journal

    As far as I'm concerned, Sun (or anyone complicit in their activities re: Java) lost all right to bitch about this once every new version of Java consistently broke backwards compatibility with previous versions.

    In some aspects, it is the fundamental deficiency of Java the language. Because all methods are implicitly virtual and all overrides are also implicit, and because override resolution happens at class load time, not at compile time (i.e. if Derived.class derives from Base.class, and both have method void foo(), then Derived.foo will override Base.foo - even if, when Derived.class was compiled, Base.class didn't contain foo yet), you get a specific case of fragile base class problem [wikipedia.org] in Java that's effectively unavoidable.

  • by jrumney (197329) on Monday April 13, 2009 @07:56PM (#27564795) Homepage
    Microsoft didn't actually leave anything out of the APIs for their version of Java, they just made sure that their implementation of AWT sucked even more than Sun's and provided their own proprietary UI API which they promoted heavily. When Sun introduced Swing, a UI framework that sucked a bit less, in Java 2, MS stuck with Java 1.1 and promoting their own framework. If Microsoft had played along, Windows users at least might have had a version of Swing that didn't suck back in Java 1.3 days instead of having to wait for Sun to improve things in Java 1.6.
  • by ValuJet (587148) on Monday April 13, 2009 @08:04PM (#27564885)

    Your theory falls flat when you hit point #2

    The following packages do not exist.
    google.io.*
    google.threads.*
    google.db.*
    google.util.*

    If, in the future, google does add those libraries, I would fully expect them to be opensourced.

  • by Thinboy00 (1190815) <thinboy00.gmail@com> on Monday April 13, 2009 @09:54PM (#27565623) Journal

    It's not the restrictions, it's the implementation. Normally, existing Java code could just be compiled on the embedded system, and compiler errors would specifically identify security reasons for specific classes/methods/etc being disabled. Google removed the classes entirely, so the developer will just get IDontKnowWTFThatClassIs exceptions instead, which are less informative.

    It also contravenes existing standards, sort of like making "dangerous" files invisible to unprivileged users in *NIX (via some sort of arcane black magic, perhaps a modified (munged) shell or something...) instead of just setting appropriate file permissions.

  • by darkvad0r (1331303) on Tuesday April 14, 2009 @07:12AM (#27568097)
    Do you know how long does it take to define a profile through the standard specification process ? Joda-time (the replacement for those ugly Calendar and Date apis) has been meant to get included in Java since the beginning of 1.5 but here we are some years later at 1.6.something and still no sign of it. Maybe google will go through the standard process for defining the "Java Cloud Edition" (I don't doubt it) but the thing must be out for developers to play with so clearly there's nothing monopolist here (the thing is in experimental state after all)

Any circuit design must contain at least one part which is obsolete, two parts which are unobtainable, and three parts which are still under development.

Working...