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.'"

Pot. Kettle. Black.

[TheRealMindChild]

'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 [wikipedia.org]?

Re:do their own then...

[fuzzyfuzzyfungus]

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.

Re:do their own then...

[Chyeld]

Subtle yet important difference to me, Microsoft released something that did include the 'full set' plus some but didn't work the same as the specs said it should.

Google simply didn't release a full set.

And where Microsoft pulled their stunt to kill Java, I imagine Google did it for technical reasons (i.e. trying to lock down the sandbox) since they have said they want to add more classes to the list of allowed ones.

Re:do their own then...

[DragonWriter]

IrI'm fine with the GOOG not offering Java support, but what's the justification for only offering half-assed support?

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.

Re:Like J2ME/CLDC?

[CarpetShark]

Exactly. I can't help thinking that Java might have been a lot more pervasive and standardised by now (not to mention that the CLR probably wouldn't exist) if Sun had been more open with Java licensing years ago.

AP Java Subset?

[firefoxman]

The CollegeBoard uses a subset of Java in their AP curriculum, and they don't get a complaint?

Re:Pot. Kettle. Black.

[DragonWriter]

The real problem is that Google created their own version of Java ME. Instead of sticking with the existing standard, they came up with their own.

Since AppEngine, Google's cloud platform is (while, like mobile devices, a different environment from the standard desktop or server environment for which the Java Standard Library is designed) not a mobile platform, and doesn't have the same constraints that shape the development of Java ME, it's not surprising that they did something different.

OTOH, the justification is the same for having Java ME when Java SE already exists: the environment in which AppEngine Java is being used is very different from that for which SE was conceived, putting unique constraints on it.

I think that Phipps is upset because Sun is in the process of gearing up their own cloud services, and the last thing they want is Google's Java support drawing enterprise interest to AppEngine while they try to get Sun's cloud service off the ground.

Re:why didn't they complain about GWT?

[lfaraone]

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

Because they never said that GWT supports "Java", they said it implements some JRE classes. And like everyone says, Sun is a sore loser for failing to release a usable cloud-computing project.

Re:do their own then...

[wawannem]

You're right... I guess I didn't really think about where the money would come from. But, if anyone has any really expensive hardware sitting around that isn't flying off the shelf the way it used to, I would think it would be Sun. So, maybe they could put some of it to use building a cloud of their own. I've just always been of the school of thought that if you don't like how something is built, build your own.

Re:Mountain out of Molehill

[AKAImBatman]

They're not supporting Threads for a start

That would be their locked-down sandbox. You can accomplish the same thing in vanilla Java with a security manager. (Which for all we know, they did. I haven't tried yet.) If the security manager doesn't allow it, you're not using it. Period, end of story.

You may note that everything Google has locked down is either controlled by the security manager or is simply an API to access a service that they don't provide.

which is pretty major

Generally speaking, it's a good idea to avoid multithreading/networking/filesystem access in a servlet environment anyway. That's what the container is for. It manages all those little details so you don't have to.

That's not to say that people don't come up with reasonable uses for such services (e.g. Quartz scheduler), so programmers will have to decide whether they prefer to use Google's locked-down environment with its alternative solutions (e.g. Cron) or if they would rather purchase dedicated hosting and handle all the details themselves.

For me, the answer is straightforward. I have one site that would be nice to move over, but I'm not going to. It makes use of services that Google does not provide. Those services are important enough to me to continue paying for dedicated hosting. On the other hand, I'm working on a new site that has far lower requirements. That one is getting installed on Google AppEngine.

So far I haven't found any limitations I can't live with for the new site (as I said, nothing that can't be restricted with a security manager), so I'm pretty happy. I may change my mind after using it more, but until I run into some hard and unexpected limitations, I'm not going to crucify Google for their AppEngine support.

Re:do their own then...

[fm6]

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 [wikipedia.org] decided he could redo the ARC format faster and smaller. That's what happened when Anders Hejlsberg [wikipedia.org] decided he couldn't live with Java's limitations [zdnet.com]. 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.

Re:Pot. Kettle. Black.

[MrEricSir]

Free or not, at some point you MUST have a standard, or you will not have interoperability. What Google is doing here is no different than what Microsoft has done for years.

Now I'm not saying Java ME is good. In fact, it's awful. But an awful standard is still better than none.

Re:Pot. Kettle. Black.

[DragonWriter]

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.

I really don't think that Java developers have much trouble understanding or using a clearly defined subset of existing functionality.

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

What Microsoft did was create an incompatible implementation of core Java classes, supporting similar features but requiring different behavior with the same classes. This has much more serious negative impact than implementing a well-defined subset, since the former makes it hard to move code either way between implementations, and the latter (what Google is doing) makes it very easy to move code off the non-standard implementation (AppEngine) and onto a standard implementation, but somewhat challenging to move code using the unsupported features from the standard implementation onto the non-standard one.

It's actually a really bad thing to do if you want to create lock-in to your non-standard implementation, since it does nothing to keep people from moving off your platform, but makes it harder than supporting the standard would for them to move on to your platform.

Re:Sauce for the goose...

[ValuJet]

How does using a subset of java 'Lock you in' to google? You can take that implementation and go anywhere that has the full version of java available and install your app there. It will work with some configuration changes.

My guess is Google doesn't allow you to play with threads for performance reasons. The file i.o. is because of the system architecture. You need to write to a filesystem, you have to write to memcache.

As someone who is looking to write an app on the engine, some of their stuff bothers me, but I get why they're doing it. If I ever want to take my ball and go elsewhere, I will always have that ability.

Everything you need is there

[owlstead]

OK, no Swing, no Corba etc. But I cannot see what part is missing for cloud computing (or any other algorithm. The collections classes (even the thread safe ones), all cryptographic stuff etc. The only thing that really seems to be missing is graphics (images). But for most cloud computing needs, this should be sufficient.

Anything else you may be able to import using the classes from the open source JDK anyway. As long as you don't create files etc. of course, thanks to the sandbox. And we're not talking about a release of another JDK or anything like that, in that case it would be a problem not to include the default functionality.

This seems to be a bit of a cheap shot. He should well know that you cannot display any personal opinions that are directly in his line of work, and then claim that they are not the opinions of his employer. Not in his position.

Re:do their own then...

[goofy183]

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.

HOWTO: Using a SUBSET to create LOCK-IN!!!

[onitzuka]

1. Remove APIs for Threads, File Access, ThreadGroups, or whatever you feel you want removed (eg. java.io.*, java.lang.*, java.util.*, etc...)
2. Replace those features with APIs that offer features only available on the Google's application server. (eg. google.io.*, google.threads.*, google.db.*, google.util.*, etc...)
3. Have developers write their code for your Google application server.
4. Snicker knowingly because you know that Java Servlet/JSP developers can and do use Threads and file systems and network access in their applications. In fact PHP developers use file systems all the time along with network access. Why do you snicker? Because you know they cannot simply copy their applications to Google App Engine without reimplementing it and creating a version JUST for Google App Engine. As the implementations are different and we know that developers time costs money($$$), managers will eventually have to decided whether to continue to support the open Servlets/JSP implementation (which could be ported to Tomcat, Resin, JBoss, or any others) or if they will just go with the Google App Engine version.
5. Laugh when they cannot port their applications out WITHOUT reimplementing all of the private APIs.
6. Profit

Re:do their own then...

[lamber45]

Those restrictions are very siliar to the ones imposed upon Enterprise Java Beans. Quoting from the Sun documentation [sun.com]:

Specifically, enterprise beans should not:

• use the java.lang.reflect Java Reflection API to access information unavailable by way of the security rules of the Java runtime environment
• read or write nonfinal static fields
• use this to refer to the instance in a method parameter or result
• access packages (and classes) that are otherwise made unavailable by the rules of Java programming language
• define a class in a package
• use the java.awt package to create a user interface
• create or modify class loaders and security managers
• redirect input, output, and error streams
• obtain security policy information for a code source
• access or modify the security configuration objects
• create or manage threads
• use thread synchronization primitives to synchronize access with other enterprise bean instances
• stop the Java virtual machine
• load a native library
• listen on, accept connections on, or multicast from a network socket
• change socket factories in java.net.Socket or java.net.ServerSocket, or change the stream handler factory of java.net.URL.
• directly read or write a file descriptor
• create, modify, or delete files in the filesystem
• use the subclass and object substitution features of the Java serialization protocol

Sun folks often have no clue about Java

[IQGQNAU]

Whatever Phipps' experience (of which I have no knowledge), he clearly doesn't comprehend Java security. The whole key to safe code in networked environments is the use of security policies. That includes, in addition to "fine grained" access control over OS operations, the ability to restrict access to classes in the classloader mechanism. This is the same stuff that happens whether you're doing applets in a web browser or a servlet in a web application container (including Sun's Glassfish).

Re:do their own then...

[deraj123]

I'm not sure what you mean. The complaints seem to indicate that you'll get things such as "NoClassDefFoundError" and the like, rather than the more appropriate "SecurityException". As to which one actually happens, I don't know. The point is that a developer, developing an application for Java, should not have to concern himself whatsoever with NoClassDefFoundErrors when interacting with standard jvm classes. He SHOULD however, be concerned with potentially encountering SecurityExceptions.

My point was that (from a cursory glance) for all of Google's restrictions, the Java spec already defines the proper way to indicate that those features are not available. Given that there is a "right" way to do this, there's very little reason for Google not to do it the right way.

Re:do their own then...

[gnud]

Well, if the error is about code that you will use...

Imagine that you use some 3rd party library that includes code for caching to disk. Since you know you can't write to disk on the AppEngine, you disable caching in the configuration. But the UnsatisfiedLinkError is still there.

Re:Pot. Kettle. Black.

[Thinboy00]

The point is actually this: If I (or someone else) write a program in GoogleJava (or whatever you want to call it) and said program runs, I can take that same source and compile it under Java standard edition, with no refactoring, and it will run exactly the same (AFAIK). Try doing that with MS Java (no refactoring allowed!).

Re:do their own then...

[fractoid]

It sounds like Google actually did it The Right Way, rather than just excising whole classes.

I like that better than The Sun Way:

1. Implement a nice interface
2. Re-implement it with slightly different naming conventions
3. Deprecate the original, perfectly functional interface
4. Deprecate the re-implementation as well for good measure, and add a totally new package that does the same job
5. Repeat as unnecessary until apps aren't portable between different point releases of the JVM let alone different goddamn operating systems.

Re:HOWTO: Using a SUBSET to create LOCK-IN!!!

[onitzuka]

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.

I can see how you misunderstood the posting. Please, let me help you.

I will do this in two parts:

[PART-1]
I am sure that you only missed the that I used "e.g." (what is an e.g.? [about.com]) in the above, otherwise you would not have made the mistake of thinking that it could have been referring to anything else other than an example being posited for the discussion.

Those names were examples... hypothetical, if you will.

Now that that is all cleared up, give the post a re-read... but only after reading PART-2 which comes next...

[PART-2]
Also consider another good point: Why block the ALREADY open source standardized community developed and supported implementations only to provide your own replacements? Even if as you suggest that you "would fully expect them to be opensourced", WHY NOT support the existing open source community? WHY NOT support the existing open source solutions?

Re:Mountain out of Molehill

[khchung]

Following /. tradition, I have not looked at the details, but that won't stop me from commenting here... :)

As someone who has been writing Java since '99, I have to say if even Threads is not supported, it is a big issue.

There is a reason why the Core class are called "Core", every Java library expects the Core classes are there. If we now have a popular Java platform that only have a subset of the Core classes, it will cause a lot of headaches down the road, eventually fragmenting the "Java" platform.

Re:Mountain out of Molehill

[oreaq]

As someone who has been writing Java since '99, I have to say if even Threads is not supported, it is a big issue.

Thread support is also "missing" in Sun's JEE Specification. Concurrency is done by the application server, not by the application. As a developer you just configure the relevant parameters you do not code the the actual threading. I do not know Google's AppEngine (and of course I haven't read TFA) but I guess it will be similar.