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

Comments

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

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

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