Slashdot Mirror
Sun's Phipps Slams App Engine's Java Support
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.'"
bahahahaha. Sun? Money?
You've not been here long, eh? :)
-knewter
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 ...
'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.'
You mean like Java ME?
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
Grr.
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 vs. Google data center tour. I bet for most of us Google's Java AppEngine implementation will be "good enough".
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.
Javascript + Nintendo DSi = DSiCade
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.
While I agree that google is not Mr. Friendly, I'd be surprised if this particular move is about lock-in. Not because of any belief in google's virtue; but for basic technical reasons.
If you want lock-in, you create a superset of the competitor's platform, or a variant of the platform that behaves differently, then push people to use your proprietary features. Implementing a subset of the competitor's platform just raises the cost of porting to your implementation, and creates no barrier to moving from your implementation to others' implementations.
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.
The word is flout not flaunt. English is harder than it looks.
None of them can see the clouds; The polished wings don't care.
COBOL compatibility has served us all very well for over a decade, and to develop new programming languages is wanton and irresponsible.
The justification is the same as Sun has when it creates a limited profile of Java for a special environment, like Java ME: the demands of a special environment.
http://code.google.com/appengine/docs/java/runtime.html#The_Sandbox
So I would say the reasons behind their decision would boil down to "cutting out the stuff that isn't compatible with the model the App Engine uses to run things".
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.
As far as I have learnt from a few cursory glances at appengine, it does not offer a complete OS environment. It is severely sandboxed, probably as a measure of security. All classes that deal with those non-existing features can either be non-existing, or exception-generating stubs. Google choose for those classes to be non-existent. That is something different than creating this-environment-only classes and functions, like MS did with their corrupted java. But there are prominent links on the appengine homepage to submit your own featers and bugfixes, so maybe all these complainers can contribute patches instead of contributing whine?
This space is intentionally staring blankly at you
While I agree that google is not Mr. Friendly, I'd be surprised if this particular move is about lock-in.
It never is. Whenever somebody modifies standard technology to suit themselves, they get accused of trying to create lockin. That's what happened when Phil Katz decided he could redo the ARC format faster and smaller. That's what happened when Anders Hejlsberg decided he couldn't live with Java's limitations. Netscape and HTML. Microsoft and HTML, CP/M, x86....
Lockin does usually occur when people do things in a different way, and the different way ends up being the de facto standard. But that's not why they do them. They do them because developers just plain like to do things their own way.
In the case of Google's "white list" this doesn't even come close to being lockin, because any application that will run on Google's classes will run on "standard Java". Sun's problem is that the reverse isn't true. And I'm not sure that really matters. Unless I've missed something, the missing classes are all legacy cruft that should have been deleted from Java long ago.
So why haven't they been? Lack of will. One Java core engineer told me that Sun got in trouble when they even deprecated an API, never mind removing a whole class. People just don't want to fix up all their legacy code, and Sun was too anxious to monetize Java to stand up to them.
Google has more flexibility, since they don't need for their version of the Java platform to make money anytime soon.
Well sure, If you're re-using a standard library it may have handling for the security exception chain and either fail gracefully or work with limited functionality.
If a JDK class is missing and the library class you want to use references it the code won't even run with an UnsatisfiedLinkError. That is a HUGE difference.
Another case where the library class references a missing JDK class but the use of the library class you're using never touches the forbidden code. In that case you again get a UnsatisfiedLinkError. If the use of the JDK class was just restricted by a security policy you only get the security exception if you actually call the API, a much better alternative.
The Right Way:
Google's way:
$ make available
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.
$ make available
Citation needed, please. Here's what Google's documentation about java.lang.System says:
What about this is unreasonable? Where does it say that apps will get ClassNotFoundExceptions? Please stop spreading unsubstantiated FUD.
I like that better than The Sun Way:
Rampant carbon sequestration destroyed the Dinosaurs' tropical paradise. I'm here to help repair the damage.
Except you're not going to get compile time errors from the third party library you're using since it is already compiled, you're still stuck with the ugly runtime UnsatisfiedLinkErrors. The JDK has features to support what Google wants to do built in specifically for this case and they really aren't very complicated to use.