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

Re:Mountain out of Molehill

[kaffiene]

Um... no. They're not supporting Threads for a start - which is pretty major. I had a read of the exclusions a while back and there were some significant omisions. I'd list them if I could find the page again, but no luck I'm afraid.

That said, I'm not sure if I see this as a major issue either.

Re:do their own then...

[Chyeld]

http://code.google.com/appengine/docs/java/runtime.html#The_Sandbox [google.com]

The Sandbox
To allow App Engine to distribute requests for applications across multiple web servers, and to prevent one application from interfering with another, the application runs in a restricted "sandbox" environment. In this environment, the application can execute code, store and query data in the App Engine datastore, use the App Engine mail, URL fetch and users services, and examine the user's web request and prepare the response.

An App Engine application cannot:

• write to the filesystem. Applications must use the App Engine datastore for storing persistent data. Reading from the filesystem is allowed, and all application files uploaded with the application are available.
• open a socket or access another host directly. An application can use the App Engine URL fetch service to make HTTP and HTTPS requests to other hosts on ports 80 and 443, respectively.
• spawn a sub-process or thread. A web request to an application must be handled in a single process within a few seconds. Processes that take a very long time to respond are terminated to avoid overloading the web server.
• make other kinds of system calls.

Threads
A Java application cannot create a new java.lang.ThreadGroup nor a new java.lang.Thread. These restrictions also apply to JRE classes that make use of threads. For example, an application cannot create a new java.util.concurrent.ThreadPoolExecutor, or a java.util.Timer. An application can perform operations against the current thread, such as Thread.currentThread().dumpStack().

The Filesystem
A Java application cannot use any classes used to write to the filesystem, such as java.io.FileWriter. An application can read its own files from the filesystem using classes such as java.io.FileReader. An application can also access its own files as "resources", such as with Class.getResource() or ServletContext.getResource().

Only files that are considered "resource files" are accessible to the application via the filesystem. By default, all files in the WAR are "resource files." You can exclude files from this set using the appengine-web.xml file.

java.lang.System
Features of the java.lang.System class that do not apply to App Engine are disabled.

The following System methods do nothing in App Engine: exit(), gc(), runFinalization(), runFinalizersOnExit()

The following System methods return null: inheritedChannel(), console()

An app cannot provide or directly invoke any native JNI code. The following System methods raise a java.lang.SecurityException: load(), loadLibrary(), setSecurityManager()

Reflection
An application is allowed full, unrestricted, reflective access to its own classes. It may query any private members, use java.lang.reflect.AccessibleObject.setAccessible(), and read/set private members.

An application can also also reflect on JRE and API classes, such as java.lang.String and javax.servlet.http.HttpServletRequest. However, it can only access public members of these classes, not protected or private.

An application cannot reflect against any other classes not belonging to itself, and it can not use the setAccessible() method to circumvent these restrictions.

Custom Class Loading
Custom class loading is fully supported under App Engine. Please be aware, though, that App Engine overrides all ClassLoaders to assign the same permissions to all classes loaded by your application. If you perform custom class loading, be cautious when loading untrusted third-party code.

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

Not a full java environment anyway.

[nietsch]

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?

Uh, we did scream

[betterunixthanunix]

Visual J++ was what we screamed about, and Sun sued Microsoft, and Microsoft backed down and took J++ off the market.

Re:do their own then...

[ultrabot]

I used to hate Java (and JavaScript) because it took forever to load, turning a screaming fast Internet connection into a rush hour exercise in patience, but they improved that and I started singing the praises of Java and JavaScript. Then I found that even though JavaScript is still good, Java now drives me crazy

You know this already, but Java and Javascript are technologies that are not related to each other in any way, apart from the unfortunate naming. Javascript is as close to C as it is to Java.

Android derives from DavlicVM & Harmony. (!Jav

[bitsofbytes]

Technically, Google's Android is a code derivative of DavlicVM and Apache Harmony. Apache Harmony and DavlicVM can be considered as similar to Java. However, Android is Not a subset of Java.

Some links to articles discussing the topic:
http://www.javaworld.com/community/node/2683 [javaworld.com]

Some information on DavlicVM and Apache Harmony:
http://www.dalvikvm.com/ [dalvikvm.com]
http://harmony.apache.org/ [apache.org]

Each VM/platform has its strengths and purpose. There should be room in the IT industry for Java, Apache Harmony, Google App Engine, .NET, Mono, LLVM, Tamarin, Parrot, and many other VM's with their associated programming languages.
Hope you find this information helpful.

Re:Pot. Kettle. Black.

[Chyeld]

No. Point blank, no.

Go to the end of the line.

Microsoft goes out and deliberately tries to subvert standards by creating implementations that are slightly off, thus preventing anything written for them from being easily portable to another implementation.

Google has gone and created an implementation that works exactly according to spec, except leaving out items which don't make sense in the app model they use. It would be extremely trivial to port something written for Google's implementation to anything else standard compliant.

This is about as similar to Microsoft as a blizzard in the Alps is to a sunny day in Cuba.

Re:Pot. Kettle. Black.

[Anonymous Coward]

Google has gone and created an implementation that works exactly according to spec, except leaving out items which don't make sense in the app model they use.

No. You obviously have not tried to actually use the fuckup called GAE. It's not a clean subset, or well-thought-out one. I doubt much thought was involved with the design.

It is same god-awful mess as what Android was -- I do agree in that different environments need subsets, actually, but the way Google has done it is both technically and philosophically wrong. Butcher-job of arbitrarily leaving out some classes, introducing others, and having seemingly no logic behind it.

And yes, I have misfortune to (try to) develop on both of these god awful clusterfuck platforms.

I don't think it's due to Evilness. Rather, it's ignorance coupled with arrogance; and in much bigger doses than what Sun has ever offered (Sun has managed the arrogance part sometimes, but less so with ignorance -- they have learnt, believe or not).

Re:do their own then...

[sohp]

I did go to Google review the App Engine Java documentation, what there is of it. It's not clear if a class like java.lang.System (which is whitelisted, btw) locked through security policy or simply re-implemented in some crippling way. A bit of a failure to provide clear guidelines on Google's part, but becomes a real development problem because they've already stated their Java doesn't conform. Programmers are left guessing or having to find out through failure what the actual behavior is.

Re:Pot. Kettle. Black.

[ChunderDownunder]

Microsoft didn't actually leave anything out of the APIs for their version of Java

Yes they did; Sun took them to court. Specifically, they left out JNI and RMI in favour of their own COM object APIs.

Proof? Microsoft's own document [microsoft.com] reveals this.

Re:do their own then...

[Thinboy00]

The Right Way:

1. Developer tries to port code
2. javac (compiler) throws security exceptions
3. Dev:"I'd better read the docs on this."
4. Program will now DTRT WRT using the right classes

Google's way:

1. Developer tries to port code
2. javac throws classNotFound exceptions
3. Dev:"WTF! java.lang.System is integral!"
4. Dev is VERY confused since java.lang.System is essential for a basic hello world.

Re:Mountain out of Molehill

[Raenex]

The major problems with threads isn't the java.lang.Thread API, it's the shared-state model and the whole concept of threads in general. The new concurrent utilities are just that, utilities. You still have to be very careful about shared variables and locking. Once you have two threads running you have to be sure that every single line of code that they call is thread-safe. Good luck with that.

Yeah, it's nice to have the utility classes to help avoid a few bugs, but they aren't the panacea you're making them out to be.

Re:do their own then...

[Fastolfe]

Google's way:

1. Developer tries to port code
2. javac throws classNotFound exceptions
3. Dev:"WTF! java.lang.System is integral!"
4. Dev is VERY confused since java.lang.System is essential for a basic hello world.

Citation needed, please. Here's what Google's documentation about java.lang.System [google.com] says:

Features of the java.lang.System class that do not apply to App Engine are disabled.

The following System methods do nothing in App Engine: exit(), gc(), runFinalization(), runFinalizersOnExit()

The following System methods return null: inheritedChannel(), console()

An app cannot provide or directly invoke any native JNI code. The following System methods raise a java.lang.SecurityException: load(), loadLibrary(), setSecurityManager()

What about this is unreasonable? Where does it say that apps will get ClassNotFoundExceptions? Please stop spreading unsubstantiated FUD.

Re:do their own then...

[goofy183]

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.

Re:Pot. Kettle. Black.

[IntlHarvester]

Well, that could have been inexpensively fixed.

The bigger problem with J++ was that Microsoft extended the language to provide delegates (IIRC), and that feature emitted illegal JVM opcodes. This made J++ source+binary incompatible with Sun Java in a manner that couldn't be resolved without junking all the Windows extensions. Therefore they lost the lawsuit and it ultimately cost them hundreds of millions of dollars.

Re:Mountain out of Molehill

[fm6]

Please give all your "Informative" mod points back. I just looked at the Google App White List [google.com] and Thread is most assuredly there. The irritating thing is that I started a really pointless flame war over whether Threads needed to go away without double checking your "facts".

Re:Mountain out of Molehill

[Raenex]

Just saying "you're wrong" wastes both our time.

That's all you've done in your replies. I said it was a minor improvement to start with, and told you the reasons why it was minor. I pointed out how your initial post gave a very wrong impression about what Google did versus the concurrent utilities. You haven't show any evidence that backed up your initial post. You sound like an inexperienced noob confusing Javascript with Java with regards to threading.

I've just realized that this whole argument is about a hypothetical. The Google white list does include Threads. Too bad.

Too bad for you a highly modded comment [slashdot.org] explains your error: "A Java application cannot create a new java.lang.ThreadGroup nor a new java.lang.Thread. These restrictions also apply to JRE classes that make use of threads. For example, an application cannot create a new java.util.concurrent.ThreadPoolExecutor, or a java.util.Timer. An application can perform operations against the current thread, such as Thread.currentThread().dumpStack()."

So really, what we're arguing about is whether Google App should support every single class in the Java SE core class list.

No, that was the high-level argument that started this story. What we are arguing about is your comments with regards to Java threading, and the benefits of the concurrent package.