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

do their own then...

[wawannem]

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

Re:do their own then...

[knewter]

bahahahaha. Sun? Money?

You've not been here long, eh? :)

Re:do their own then...

[tomhudson]

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

Re:do their own then...

[SatanicPuppy]

What, like Microsoft did when it reinvented Java for IE? Do you really want a 3rd version of Java that's not quite compatible with regular Java (counting gcj as the 2nd)?

I'm fine with the GOOG not offering Java support, but what's the justification for only offering half-assed support? It kills the whole point of portability.

Re:do their own then...

[whiledo]

How would Sun producing their own App Engine solve the problem of Google's App Engine not being fully compatible? It'd still be incompatible and still have a lot of users.

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

[davester666]

Google is making their Java implementation proprietary by NOT implementing parts of the Java spec (and presumably not replacing it with something incompatible with what's in the java spec)?

I don't see how Google will get lock-in by providing fewer features than their competitors, unless their implementation is so superior, that their competitor's can't provide the same performance.

Note, I am not a Java programmer, and I hope I don't come across something for which Java will be the best way to implement it.

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:do their own then...

[Anonymous Coward]

Except you have it the wrong way around. Microsoft's Java was extended so that anything developed on it required things not available in Sun's Java. That was lock in. Anything developed with Google's Java will work fine in Sun's Java because it uses less not more.

I know, I know. This doesn't fly with the "OMG Google are the new Microsoft" conspiracy theory that we all know and love.

Re:do their own then...

[Ifni]

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. I'm sick of updating to the latest version of Java and having every existing Java application (I'm looking at you, Cisco) stop working, even though you keep each previous version installed by default. I mean really, what's the point of having a half dozen versions of the JVM installed if the only thing it uses is the latest one?

And yes, I know you can tweak a file here and there to force a given application to use a given JVM (and, if the app - not Java - supports it, Launcher), but that fails to address two important issues - a) that a given java app can't specify what version of the JVM it wants, and b) that even within a given version (say 1.6 update 7 versus 1.6 update 11) the functionality of (and maybe even interfaces to) included objects changes to the point of breaking compatibility.

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 because I can't keep it updated unless I want to get under the hood and fix everything it broke in the applications I use. And with the recent trend of releasing an updated JVM once every 2 months or so, this gets very tedious, very fast.

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:do their own then...

[IamTheRealMike]

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.

Re:do their own then...

[Anonymous Coward]

something about embrace, extend, extinguish - isn't this step 1? not saying that steps 2 & 3 will follow, but there's certainly precedent for this.

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

Re:do their own then...

[sohp]

Sounds like they should have specified a security model that would forbid certain classes and method rather than simply removing classes. Or was that too hard for Google's engineers? As a developer, would you rather have you application fail to run, or throw a completely bizzare ClassNotFoundException: java.lang.System, or run but throw an informative SecurityException when it tried to call System.exit()?

Re:do their own then...

[Sir_Real]

Then subclass for f***'* sake

Re:do their own then...

[DragonWriter]

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

Sun actually is launching their own cloud computing environment this summer, and has been announcing tie-ins to a lot of their existing products for it ("Save to Cloud", "Load from Cloud" in OpenOffice.org, Cloud related functionality in Netbeans 6.7, etc.) If their attempts to market their cloud offerings fall flat (which AppEngine supporting more than just Python makes somewhat more likely, as they have more competition, though I think Amazon is still the main direct competition for what they plan to offer), Sun's going to have wasted a lot of money and effort.

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.

Re:do their own then...

[DragonWriter]

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.

Re:do their own then...

[LizardKing]

So your blaming Sun for Ciscos ineptitude. I have code written under the 1.0.2 Java SDK that still runs under Java 1.6. There again, unlike Cisco's engineers I understood what portability was, because I was targeting SunOS as well as Windows.

Re:do their own then...

[Chyeld]

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.

Re:do their own then...

[Hmmm2000]

I thougth the a key feature of java was "write once - run anywhere". Dont blame the developer if a new JVM breaks a java app.

Re:do their own then...

[goofy183]

Yeah I'm surprised they didn't do this. Everything they describe is doable via a security policy configuration file and a single custom ClassLoader implementation.

Re:do their own then...

[shutdown -p now]

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 in Java that's effectively unavoidable.

Re:do their own then...

[merreborn]

Unless I've missed something, the missing classes are all legacy cruft that should have been deleted from Java long ago.

I, too, eagerly await the deprecation of java.lang.Thread, and the loss of the ability to open sockets and write directly to the filesystem. Who needs that cruft?!

In all seriousness, the missing functionality isn't about trimming cruft, it's about sandboxing so that apps can readily be hosted in google's "cloud", and play nice with other apps.

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.

Re:do their own then...

[deraj123]

Well yes, it does. From reading that list, it seems that all of these things that they want to "change" already allow for the changing through a security manager (as the GP mentioned). See, the whole point of Java is that you shouldn't be coding to each custom environment. And, security restrictions are something that any competent developer should be taking into account when writing his code. Therefore, if the environment fails in a somewhat expected, valid manner, developers can (and should) account for that in their code.

Re:do their own then...

[deraj123]

I thougth the a key feature of java was "write once - run anywhere".

It is. Although "write properly once - run anywhere" would probably be more accurate.

Dont blame the developer if a new JVM breaks a java app.

Most issues I have seen with a new JVM breaking a java app is because the app developer was doing something they weren't supposed to. (using com.sun classes, relying on undocumented, "undefined" behavior, etc) If you code to the spec, and only expect methods to do what they say they'll do in the documentation, chances of a new JVM breaking your application are very slim.

As a disclaimer, note that I use terms like "most" and "chances are very slim". There have been exceptions, where a new JVM did break things, but the majority of broken applications are not due to those exceptions.

Re:do their own then...

[Chyeld]

http://code.google.com/appengine/docs/java/gettingstarted/installing.html

And given the SDK they point you to is Sun's and this is Google, how unlikely is it that the things being complained about are actually being managed by a security manager and not actually missing. I.E. Communication error.

Re:do their own then...

[mellon]

So it seems like you're saying that what Google did is better than what the guy from Sun thinks they should have done. Because it's *always* better to get a compile-time error than a run-time error.

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:do their own then...

[lamber45]

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

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

Re:do their own then...

[SashaMan]

This article writer is a tool. Interestingly enough, most of these restrictions (no filesystem access, no sockets, no spawning threads) are EXACTLY the same restrictions as recommended by Sun for EJB: http://java.sun.com/blueprints/qanda/ejb_tier/restrictions.html

Re:do their own then...

[davolfman]

Those sandboxing restrictions remind me a little of the restrictions already in place for applets.

Re:do their own then...

[fm6]

Please. Not every shoot-from-the-lip blog entry is part of a FUD campaign.

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

[Chyeld]

Agreed, And not being a Java developer I have no way of knowing the truth of whether Google did it the 'right' way or not other than asking. However, the only complainer I've actually seen is someone from Sun, a company who has a vested interest in making whatever Google did look bad and not a stellar rep with me for saying things 100% on the up and up all the time.

Additionally, I don't see anywhere in the 'official' statements indicating that Google actually removed anything in the breaking sense. Google's specs could be read by me to indicate they did the 'right way' or the 'wrong way'. And our 'complainee' simply said:

The JRE Class White List - Google App Engine
Whether you agree with Sun policing it or not, Java compatibility has served us all very well for over a decade. That includes being sure as a developer that all core classes are present on all platforms. Creating sub-sets 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.

on his blog.

That tells me diddly shit. So, the question is, given Google actually employs some fairly smart fellas, what are the chances that they actually did it the right way and Phipps is just bitching for bitching's sake? Or perhaps doesn't believe the security manager is a 'right way' either.

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

[Anonymous Coward]

Or maybe it was just a comment he posted to a link when the news broke last week and it took a journalist posting a story with a catchy headline the following week when things were clearer to cause a fuss?

Re:do their own then...

[Thinboy00]

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.

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

[Fastolfe]

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.

Do you have any information suggesting that this is how Google chooses to deviate from the standard? I think we can all agree that this is, indeed, a huge difference. But is Google actually doing this?

Re:do their own then...

[Thinboy00]

The reason Sun has a problem with that is this:
Java was always intened to be portable. That "the reverse isn't true" is a HUGE problem. It means something coded for your computer won't work on your G1 without refactoring. The whole point of Java is that either it will work, or if it won't the compiler will at least tell you WHY it won't and WHERE you can get instructions on how to minimally refactor. Google's way the compiler just spews a bunch of "I've never heard of this class before: java.lang.System [which you need to so much as write a Hello World!]" errors/exceptions/etc. without telling you where to get Google's doc on what to use instead.

Re:do their own then...

[Fastolfe]

Sounds like they should have specified a security model that would forbid certain classes and method rather than simply removing classes.

After reading through the documentation, it looks like they do throw SecurityException when it's appropriate for them to do so. It looks like they're making extensive use of Java's security features to point out where an application is doing something it's not allowed to. Is this actually a problem people are having with their Java ports?

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: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:do their own then...

[Kalriath]

It is. Although "write properly once - run anywhere" would probably be more accurate.

Isn't that "write once, debug everywhere"?

Re:do their own then...

[BikeHelmet]

I'm pretty sure it'd fail to compile if the class was missing...

They say the System methods that are disabled are not relevant. I assume it's like calling System.exit() in an applet... there's just no point to.

Re:do their own then...

[BikeHelmet]

You'd be surprised how many systems lack a console, or don't respond to other java.lang.System methods.

I actually had to go back and change some settings on my dev machines to get the console to exist! Before that it was just "NullPointerException" over and over.

Re:do their own then...

[12357bd]

Then why Google does not defines his own 'limited profile' in the standard java specification process. Not that difficult. Make no mistake Google is using his monopoly muscle here.

Re:do their own then...

[dgriff]

Slashdot way:

1. Post an article that looks good but is technically illiterate
2. Get modded up to "5, Informative"

Re:do their own then...

[darkvad0r]

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)

Re:do their own then...

[rackserverdeals]

So, maybe the could put some of it to use building a cloud of their own.

They area

The nice thing with Java development is it's portability. It's why the specification process can be a pain. It comes in handy.

An app I built for a client was deployed at a host that kept having problems, including being hacked. Because of standardization in the spec, the application could be deployed on a different server, using a different app server brand without any issues.

With Google App Engine, you can't do that. You have to specifically code for it. It' smore than just using their api's. Some things you would have on a normal java webapp server, you won't have with App Engine. So you can't just transfer an existing app and you might not be able to transfer away from it.

This may seem like a non issue for people working in PHP or something similar where there is one vendor, but the Java Community Process is good for vendors. It allows multiple vendors to compete to make a better implementation of the spec.

Re:do their own then...

[jetxee]

It's not different for Python on Google App Engine. Only a subset of its standard library is available (anything that requires disk access does not work).

So, also with Python one has to code specifically for GAE. The same applies for Java.

But GAE offers free-as-in-beer and ad-free application hosting. It's OK that it is somewhat limited and is not 100% compatible with everything else.

Re:do their own then...

[nuttycom]

The central problem is that Sun has not gone far enough in creating limited profiles of Java - by properly modularizing the core libraries. There is no reason why awt and swing should be part of the minimal core of Java. The same thing can be said for System and perhaps even the threading and socket APIs. If the core of Java was sufficiently modular, then there would be no issues with Google specifying a subset of modules that are supported within their environment.

With any luck, this is something that Project Jigsaw will address - though I dearly wish that Sun had opted to adopt OSGI within the jvm instead of developing their own module system.

Re:do their own then...

[onitzuka]

A simple example would be server-based image processing. We see this done in PHP using the GD extension now which is installed by default on most hosting providers.

Re:do their own then...

[nuttycom]

Sure, but this is a flaw in the modularity of awt - image processing libraries should not be intertwined with GUI libraries. Instead, the GUI library should depend upon the image processing library, and not vice versa.

Re:do their own then...

[fm6]

Java was always intened to be portable.

Not always, actually. The "write once, run anywhere" notion was invented after Java unsuccessful first career as a standalone embedded environment.

But yeah, portability is now a major feature of the Java platform. But portability has never been as absolute as that marketing slogan asserts. You can write a web browser that will run on any cell phone with the right kind of Java support. That same browser would be hard to run on a PC. But who wants to?

What, you say that Java ME, not regular Java? OK, try this one: a line of computer systems that I document comes with an embedded "lights-out manager" that you can use for (among other things) remote control of the system. If you're miles away (or just don't feel like going into the machine room) you can point a web browser at this thing and it will download a terminal program that allows you to access the console as if you were sitting in front of it. You can even mount your local devices (or ISO images) so they're accessible from the system. And yes, it's written in Java, so it simply doesn't matter what kind of system you have.

Now, would this terminal app run on Google App? Very much doubt it. And that has nothing to do with what classes are available. The GA cloud is just not the right place to run a graphics terminal.

The whole point of Java is that either it will work, or if it won't the compiler will at least tell you WHY it won't and WHERE you can get instructions on how to minimally refactor. Google's way the compiler just spews a bunch of "I've never heard of this class before: java.lang.System"

Please, don't overstate your case. I very much doubt that they've eliminated System. If you want to be credible, find some missing classes (haven't seen a list yet) and tell us what kind of applications won't run because of them. If these are applications that you should be able to run on Google App, then you have a good argument. But not otherwise. And if they're creaky old legacy classes that now have better alternatives, then Google has done the Java community a big favor by doing what Sun lacked the cojones to do.

Re:do their own then...

[Ifni]

Note to self: Slashdot mods are rabidly pro Sun.

I mean really - Off-topic? The article is about a sun employee complaining about someone creating a version of Java that is incompatible with Sun's product and I point out the hypocrisy by describing how Sun's own versions of Java are incompatible with each other. I must just be more perceptive than most...

Re:do their own then...

[LionMage]

Interesting info with respect to threading. What I find weird is that Thread and related classes, including most or all of java.util.concurrent, are present in the white list linked from TFA. Of course, there are static methods on Thread to do non-destructive, non-management-esque things with the currently executing thread, but what's the point of making ThreadPoolExecutor available if you can't create one? Even the Executors factory methods hand you back various versions of Executors (including ThreadPoolExecutor) that can spawn new threads. The restrictions you cite would make it seem that these classes can't be used at all, even though they're in the white list. Very strange.

Re:do their own then...

[mcfedr]

This is exactly the point, i dont want to code to the google app engine, i want to write an app that i can run on app engine, and then when sun create a better, cheaper, whatever, cloud java service, move it and use that. without having to change anything. Thats the freedom that the standerd java platform gives me.

GOOGLE IS EVIL

[Anonymous Coward]

Sun confirms it!

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?

Re:Pot. Kettle. Black.

[MrEricSir]

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. And that's bad for everyone.

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:Pot. Kettle. Black.

[Anonymous Coward]

And that's bad for everyone.

Unless you want things to be free.

PS. if you don't get what I'm saying please refer here

Re:Pot. Kettle. Black.

[sohp]

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.

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

[MrEricSir]

It would be extremely trivial to convert something written for Microsoft's broken standards too.

The point is that as a developer, that just means more wasted time on something that's out of my control.

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:Pot. Kettle. Black.

[jrumney]

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.

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: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: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:Pot. Kettle. Black.

[Anonymous Coward]

What Sun wants is interoperatiaility, Google's Java is NOT Java. I have a GPhone that is suppose to use java yet only Google's apps will run on it. Our company uses a lot of Java apps because our customers use different OSes. Sun java just plain works on all of them yet my Google phone is another story. These apps work fine on "Other" java enabled phones.

Well Google what happened to "Do no evil"? Where is openness when my app won't run on your phone?

What is next changing the TCP/IP stack? The world runs on standards we need to stick to them. This change Google has made is a step back for interoperability.

Re:Pot. Kettle. Black.

[LionMage]

That seems to mainly be due to the insistence of mobile phone vendors who wanted to do things their own way. In fact, if you read through to the end of the IT World article linked in the summary, there's a salient comment at the end by someone using the handle Contrarian which touches on this very issue:

It's "why should we care" attitudes like Google's that will make your job harder by ensuring every "cloud" has a different subset of Java living in it.

It's the same "we're too big to be told what to do" attitude that made mobile Java the disaster it is - every phone company demanded the freedom to make their own APIs and Sun failed to keep them all under control, with the consequence that mobile Java is a nightmare of incompatible fragments.

"Flout", not "flaunt"

[beanyk]

Grr.

Re:"Flout", not "flaunt"

[spiffmastercow]

No, you don't understand. He's actually saying that he is a dick for flaunting the rules, and embarrassing Google to prove his own superiority.

Re:"Flout", not "flaunt"

[reginaldo]

Personally i believe the java api to inflate jvm ipl cos imo. Did that have the requisite nyumber of acronyms?

Re:"Flout", not "flaunt"

[pelrun]

No, you don't understand - 'flaunt' doesn't mean what you think it does. You flaunt wealth (that you have) and flout rules (that you despise/ignore).

Of course, people got this wrong enough that even the dictionary grudgingly gives flaunt the alternate meaning of 'ignore'.

Re:"Flout", not "flaunt"

[spiffmastercow]

No, you don't understand - 'flaunt' doesn't mean what you think it does. You flaunt wealth (that you have) and flout rules (that you despise/ignore).

Of course, people got this wrong enough that even the dictionary grudgingly gives flaunt the alternate meaning of 'ignore'.

No, I got it right, and you have no sense of humor.. He's flaunting his (Sun's) rules, making poor google feel bad about itself. It's an alternate explanation of the meaning of that sentence, with the assumption that the guy typed exactly what he meant.

I think Sun is jealous

[seifried]

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

Re:I think Sun is jealous

[betterunixthanunix]

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:I think Sun is jealous

[seifried]

It wasn't meant to be snide. I was more trying to point out that not all of us need seismically tested/milspec/whatever gear. A shipping container sitting in the midwest is probably not going to experience an earthquake (now what they do to it during shipping is another story and I suspect you'd want something pretty robust for that). The other aspect of my comment was that while Sun is out making a lot of noise Google is quietly doing it, which is probably going to lead to success more than making PR type noise. Sun, like HP, used to be a company of engineers run for other engineers, which worked pretty darn good back in the day, but now this stuff is becoming commoditized, and the time cycles have been crunched ridiculously that by the time Sun is done engineering this they may be out of the game (has Sun actually sold any of these? Heck, are they even for sale yet?).

Re:I think Sun is jealous

[wallitron]

NEBS compliance is still needed for military applications, right?

Mountain out of Molehill

[AKAImBatman]

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.

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: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:Mountain out of Molehill

[fm6]

Um... no. They're not supporting Threads for a start - which is pretty major.

A major improvement. It's now accepted on concurrency wonks (including, no especially, the ones at Sun and Google) that Threads is a disaster. Sun itself would much prefer that everybody switch to the new Concurrency classes, which are not only much more reliable, but a lot easier to use.

Re:Mountain out of Molehill

[ultrabot]

Um... no. They're not supporting Threads for a start - which is pretty major.

A major improvement. It's now accepted on concurrency wonks (including, no especially, the ones at Sun and Google) that Threads is a disaster. Sun itself would much prefer that everybody switch to the new Concurrency classes, which are not only much more reliable, but a lot easier to use.

... and seems to use threads.

Re:Mountain out of Molehill

[shutdown -p now]

Speaking of your sig - the collection that you link to is seriously outdated (2004? c'mon, that's even before .NET 2.0). A lot of points on it simply don't apply anymore.

Re:Mountain out of Molehill

[binarylarry]

Sorry champ you failed it.

The new concurrency classes are designed to simplify making code safe to use in a multithreaded environment, not eliminate the need for threads.

Re:Mountain out of Molehill

[fm6]

It uses Thread objects. Not quite the same thing. If Thread is no longer a public class, then the various bad idioms that the Thread API. encourages are no longer possible.

Re:Mountain out of Molehill

[deraj123]

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.

I'd really like to know if this is the case. Everything I've read in the list seems to me to be something a security manager could potentially block anyways. I'd like to know if they're throwing a SecurityException in these situations or not.

Re:Mountain out of Molehill

[fm6]

You're confusing threads (in the generic sense) with Threads (the Java data type). You can't have multithreading without threads (duh!) but you can easily dispense with Threads as part of the official API.

I'm no expert on this technology, but I do know a lot about the motivations behind the Concurrency classes. That's because I spent 2006 helping to update the Java Tutorial, and spent a lot of time getting indoctrinated by the key people involved in this stuff, including Doug Lea.

Re:Mountain out of Molehill

[binarylarry]

With Java, threads are not exposed in a library you use like say, C++. Threads are part of the language itself, you can't easily do any truly concurrent/multicore programming without using the official implementation because of this.

You could "fake" things with structures like coroutines, but you won't be able to take advantage of SMP support in any modern CPU.

Re:Mountain out of Molehill

[zuperduperman]

Ummm, even Sun says you should not be launching threads inside of JEE containers. Or writing to the file system for that matter. In fact, most of Google's restrictions are identical to Sun's own restrictions for JEE, the only difference is, Sun didn't make it mandatory, and now they're complaining that Google are (because they have to actually host these things in a sane and manageable way).

The only thing that really irks me is no socket connections. Making HTTP the only avenue for network I/O, and even worse using Sun's crappy URL classes to do it, limits a whole lot of potentially useful applications one could write.

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:Mountain out of Molehill

[fm6]

Hmm, I did forget about Thread objects being part of the language. But that doesn't mean they have to be part of the public API. You just fiddle with the package declarations so that programmers can't declare or instantiate Thread objects. The Thread objects still exist, but they're only accessible via the Concurrency classes.

Except this is all getting a little weird. I suspect that the real status of Thread (and the other classes missing from the "White List") is "deprecated" rather than "deleted". So you'd get a nasty warning, or maybe even a compiler error, if you tried to use them.

Re:Mountain out of Molehill

[curunir]

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.

The problem you're referring to is a well-known limitation of the java platform with a planned solution. The problem is that it's been stalled and hasn't made it past the JSR stage despite being first reviewed in 2001.

See either: Project Barcelona or the Java Isolates JSR.

That combined with the Java Resource Consumption Management API would, if implemented, give application server vendors everything they would need to make a Servlet container that could be used in a shared hosting environment.

Until then, Java just isn't suitable for a shared hosting environment...at least not in the out-of-the-box kind of way. I have managed to string together a thin C CGI implementation that uses IPC to connect to a running Java process through JNI. It worked and actually substantially out-performed any of the scripting languages available from the hosting provider, but it took quite a bit of work to get running (mostly emulating what the Servlet API gives you for free) and the code I ended up with might not be portable to a real Servlet environment since I didn't bother implementing all of the Servlet API.

Long story short...I've felt that pain and can't wait for those two JSR's to make it into a new release of Java. I only wish Google's Java API had been available at the time.

Re:Mountain out of Molehill

[Anonymous Coward]

Threads is a disaster. [...] Sun itself would much prefer that everybody switch to the new Concurrency classes, which are not only much more reliable, but a lot easier to use.

"Threads is a disaster"? What are you talking about?!

If you don't have the ability to spawn multiple threads, the concurrency classes don't do squat.

What use is a read/write lock if I'm stuck in a single-threaded model anyway!?

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

[ClosedSource]

I think this whole fragmentation issue is a bit of a red herring. How much Java Server code finds its way onto a phone? How much Java phone code finds its way onto a server?

The whole WORA idea is flawed from the start. The platform used counts and it always will.

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.

Re:Mountain out of Molehill

[poot_rootbeer]

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.

Good.

No single platform should be or can be universal. The requirements for an application on an 8-core 64-bit server serving 10,000 users at once have nothing at all in common with a single-user application on a low-power pocket device; what's the advantage of using the same language to write both when fundamental design choices must be necessity be different?

I thought Sun had understood this concern when the J2ME/SE/EE standards were established. If their position is now that every JVM must implement Threads, even the ones running on the hardware equivalent of a Gameboy Advance, then they've lost sight of pragmatism.

Re:Mountain out of Molehill

[fm6]

Never said they were a panacea. Said they were more powerful and easier to use.

Every programming idiom has its pitfalls. It seems to me that the concurrency utilities do a lot to eliminate pitfalls based on hand-rolled thread management. Yes, there are still pitfalls that you can't get rid of without changing the way Java does threads, and there are others you can't get rid of at all. So what? It's still a significant improvement.

Re:Mountain out of Molehill

[Raenex]

Never said they were a panacea. Said they were more powerful and easier to use.

You incorrectly pinned the bad reputation of threads on the java.lang.Thread API. That just scratches the surface.

It's still a significant improvement.

No, it's minor. Just to put a rough number on it, I'd say around a 10% improvement.

Re:Mountain out of Molehill

[fm6]

I think we need a shorthand phrase to answer people who confuse contradiction with argument. I propose "Monty Python!"

Re:Mountain out of Molehill

[Raenex]

What compelling argument did you make? You don't understand the issues with threads. I pointed them out to you, yet you still think this minor library compares to Google removing threads (including any ability to start them via the concurrent utilities you are talking about).

Re:Mountain out of Molehill

[fm6]

I'm not going to repeat my arguments. Read them again. And if they're deficient, put out the deficiencies. Just saying "you're wrong" wastes both our time.

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

So really, what we're arguing about is whether Google App should support every single class in the Java SE core class list. I don't even know what classes are missing from the White List. It looks pretty complete to me. To find the missing ones, I'd have to do a diff, and there doesn't seem to be a single files that lists all the official core classes. (There's a list of classes in the Javadoc, but not all of these are core.) It would be a lot of work to assemble a list from the core package list.

You do it, since you feel the Java Portability Apocalypse is at hand. Then do a diff and tell me why I should care about the missing classes. But I'm done with straw man hypotheticals like "what if they did away with System" or "what if they took up human sacrifice"?

Re:Mountain out of Molehill

[fm6]

Please give all your "Informative" mod points back. I just looked at the Google App White List 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 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.

Re:Mountain out of Molehill

[HAWAT.THUFIR]

Ummm, even Sun says you should not be launching threads inside of JEE containers.

I've never heard that. Why? You might want to make an operation run in the background, so give it a different thread.

Re:Mountain out of Molehill

[LionMage]

My understanding is that you're still prohibited from spawning your own threads inside of an EJB, but you're not prohibited elsewhere (e.g., inside a servlet or a Struts action). I recall reading that some of these restrictions had been relaxed, but I don't know many details. My company shifted away from using EJBs because we really only used them for transactioning, and we can get the same benefit by using Spring (which is way more lightweight). There's only one app I can think of that's still using any sort of EJB, and that's using message driven beans.

What about changing Java's license?

[bogaboga]

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.

Re:What about changing Java's license?

[TheRaven64]

They did. It's part of the trademark license. You can not use the Java trademark without implementing all of the standard classes, the standard language features, and having your code certified as doing so (I think the last requirement is waived in some cases). If Google are calling their product Java then they may be in trouble. If they called it Google Instant Coffee (beta) then they're fine.

Re:What about changing Java's license?

[burris]

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.

Re:What about changing Java's license?

[petermgreen]

They did that for many years.

As I understand it sun was pulled between two conflicting forces. On the one hand with MS pushing .net they wanted java to be a first class citizen on linux. Otoh they wanted to keep control over java.

Being a first class citizen on linux basically requires being FOSS. If not your package will most likely be either excluded altogether or shunted off to some "non-free" repositry which is not enabled by default and likely has lower standards of maintinance.

After much dithering a couple of years ago they finally announced they were definately going to make java FOSS and over the following years gradually did so. This meant but it also meant giving up some control.

Re:What about changing Java's license?

[TheRaven64]

Trademark isn't an absolute monopoly on the mark.

No, but to describe your product using someone else's trademark, you must have a permission to do so. You can say 'I like Java(tm)' or 'This is how you write code in Java(tm)' but saying 'This is Java(tm)' or 'This supports Java(tm)' requires you to have permission from the trademark holder. For a recent comparable case, remember the Apple advertising which said 'built on UNIX(tm)' and caused them to be sued by the owners of the UNIX trademark (a suit which was eventually settled by getting the next version of OS X certified as UNIX).

In the case of Java, it's easier than most. Sun offers a trademark license which only requires you to fulfil a certain set of conditions which are fairly trivial for someone wanting to use it. One of these conditions is that you must implement a certain core set of class libraries.

Like J2ME/CLDC?

[Anonymous Coward]

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.

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.

Re:Like J2ME/CLDC?

[israfil_kamana]

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.

Re:Like J2ME/CLDC?

[Roadmaster]

Was going to post about how J2ME does exactly what they complain about: "Creating subsets of the core classes in the Java platform was forbidden", well, Sun itself did it and let me tell you, it makes Java's already convoluted API a nightmare to work with, and is ridiculous when programming on a device such as a Blackberry.

RIM had to provide alternatives to some useful Java classes that are just not present in J2ME, turning Blackberry development into an incompatible and horrendous mess, negating all the benefits of using Java in the first place (not that there are many anyway).

Re:Like J2ME/CLDC?

[Anonymous Coward]

WTF does writing a IoC container have to do with Serializable? And what does "re-compile all my code" mean? Not trolling, purely curious.

Java ME

[Anonymous Coward]

Wouldn't the various Java ME configurations be exactly the kind of arbitrary subsets that Phipps is complaining about?

Flout not Flaunt

[onkelonkel]

The word is flout not flaunt. English is harder than it looks.

Re:Flout not Flaunt

[Anonymous Coward]

flout: openly disregard
flaunt: display ostentatiously

couple things: join two things together
couple of things: two things

Java compatibility has served us all very well for

[Gutboy]

COBOL compatibility has served us all very well for over a decade, and to develop new programming languages is wanton and irresponsible.

Re:Java compatibility has served us all very well

[AKAImBatman]

COBOL compatibility has served us all very well for over a decade

You obviously have never used COBOL.

Sauce for the goose...

[rewt66]

Would we be screaming if it was Microsoft who did this, rather than Google? Yeah, we would be screaming, and rightly so. We'd be worried about Microsoft attempting to create an MS-only ghetto that they lock people into (though it's harder to see how they could do so with a subset, rather than with extensions like they tried last time). We should subject MS to extra scrutiny - they have certainly earned it. But that doesn't mean that Google gets a pass. I know their motto is "Don't be evil", but that doesn't mean that they will live up to it forever.

Re:Sauce for the goose...

[ultrabot]

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.

Re:Sauce for the goose...

[Anonymous Coward]

No, because you don't have freaking clue about what your talking about. An application that uses a *subset* of java is still a valid java application, and not at all what Microsoft would do. Rather the opposite. Now learn how to read before blathering.

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.

Re:Sauce for the goose...

[WebMink]

Because the subset that every other cloud provider makes will be different, and then you'll need to refactor to run on other clouds. That extra friction will lead to you finding it hard to move between providers, and that's called "lock-in". What we need is an agreed "Java Web Edition" profile from the JCP. Maybe Google could contribute their work?

AP Java Subset?

[firefoxman]

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

why didn't they complain about GWT?

[pohl]

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

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 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:why didn't they complain about GWT?

[Anonymous Coward]

Hey, person that acts like he knows more about the subject than he does, Java != Javascript!

To be specific, Sun has nothing to do with Javascript and there was even a trademark battle over the name, Javascript's official name is ECMAscript, though no one calls it that.

Sun has NOTHING to do with Javascript, so they didn't complain cause they didn't care.

Re:why didn't they complain about GWT?

[Anonymous Coward]

Pretty simple answer to that. The App Engine is one of Google's major steps toward a "cloud computing" future. Sun is pissed that they're using a partial implementation of Java in their engine because it's in direct competition to their own cloud computing efforts, and they're already in serious financial trouble as a company as is. They can't afford to let Google get the upper hand on a market that they've been trying to enter for years, unsuccessfully...but they know it's going to happen. So expect more loud complaining from Sun, at least until the ship finally sinks.

cutting out the middle man

[Jah Shaka]

great, so first google totally rips of linux and calls it 'android' and now its ripping off java. Combine this with the fact that every company they buy becomes number 1 in their search index, killing of anyone who competes with them, and we get what we deserve. Personally i cant wait for my AI to search the web for me, cutting out the middle man.

Re:cutting out the middle man

[HAWAT.THUFIR]

great, so first google totally rips of linux and calls it 'android' and now its ripping off java.

"Android is a software platform and operating system for mobile devices, based on the Linux kernel, developed by Google and later the Open Handset Alliance.[2] It allows developers to write managed code in the Java language, controlling the device via Google-developed Java libraries.[3]" http://en.wikipedia.org/wiki/Android_(operating_system) No, I don't think that Google ever ripped off Linux, nor do I see that they're ripping off Java. Besides, they're both GPL'd, so there's not much "ripping off" to do, since any code changes make their upstream, or result in an essentially public fork.

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:Uh, we did scream

[ClosedSource]

And thus Sun effectively destroyed any chance that Java would be popular on the desktop. But the important thing is that Scott beat Bill.

Re:Uh, we did scream

[betterunixthanunix]

Visual J++ would, at best, have made the Java language (that is, the grammar) popular; it was missing key libraries like RMI and JNI, both of which would have been critical for cross-platform desktop development (yes, JNI is included in that; for example, to call OpenGL, or to write a library for interacting with Python). The entire point of Java was to be cross platform, so why should we accept Microsoft doing to Java what they did to ECMAscript? The last thing we would want is to try to maintain two separate codebases, one for Sun and one for Microsoft.

Re:Uh, we did scream

[ClosedSource]

Your looking at it from the point of view of being an outsider (with respect to Windows). Visual J++ was intended to be a Windows development language, not a class-platform one.

With Windows' overwhelming market share cross-platform applications were irrelevant to most Windows developers.

Let's face it - it's UNIX developers who cared about cross-platform because they didn't have a standard hardware platform. Those folks developed on some form of UNIX and if their applications happened to run on Windows it was OK, but they really didn't care that much. Those developers wouldn't be caught dead using a MS compiler anyway.

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

Some information on DavlicVM and Apache Harmony:
http://www.dalvikvm.com/
http://harmony.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.

yes well, who cares really

[gbjbaanb]

that Google committed a major transgression by only including support for [snip] Java

there fixed that for you.

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.

"Wonton", not "wanton"

[FrankDrebin]

Mmm.

Re:"Wonton", not "wanton"

[mapcan]

This is funnier than 2! 5 more like!!!

And what about that beauty called Parcelable?

[edivad]

I hope the guy didn't notice that, otherwise he'd go bizerk.

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:HOWTO: Using a SUBSET to create LOCK-IN!!!

[ValuJet]

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.

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.?) 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:HOWTO: Using a SUBSET to create LOCK-IN!!!

[Anonymous Coward]

Didn't MS try this sort of thing a few years back. How did it work out for them?

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

[redGiraffe]

I think you are missing something here: App Engine is a specific platform for specific needs. To quote Wikipedia:

Compared to other scalable hosting services such as Amazon EC2, App Engine provides more infrastructure to make it easy to write scalable applications, but can only run a limited range of applications designed for that infrastructure.

If you are writing for GAEJ then you are writing for that specific platform/framework, just as you would for J2EE5 or J2EE1.4 or a none EJB host or mobile application etc..

In my experience and to generalize:

1. Threads: Not used in web applications
2. Writing to file: Only used for file upload (images, pdf etc..) where streaming to a RDB would create a performance hit) - store in BigTable rather
3. Network access: Used to be used where SOAP services are used today. ..and then there is System.exit which is not implemented, probably a good thing, it used to do horrible thing in tomcat years ago :)

I short, it is as much of a lock in as the Spring framework or J2EE itself, two of the most popular business application frameworks.

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

[Anonymous Coward]

You just don't get it, do you? What the post you are replying to is saying but you are missing is that creating that stuff you "invent" in order to make Google the evil lock-in overlord, is that THAT WOULD BE A SUPERSET OF JAVA, ie http://www.merriam-webster.com/dictionary/i.e. IT'S NOT A PURE SUBSET OF JAVA ANYMORE! Now, get your medication.

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

[GauteL]

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

The word subset does not mean what you think it means. Hint: A subset is fully contained within the original set and does not contain any additional features. If Google adds these features their implementation is no longer a subset.

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

[BiAthlon]

The problem with your theory is that point number 2 and number 5 are false. There are no private APIs. If there were private APIs it would not be a subset, it would be a superset with missing functionality.

The only issue with Google using a subset of functionality is that if they strip too much out that is useful developers won't use it and instead opt to use one of the many other hosting options.

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

[onitzuka]

Yes. You are correct. Microsoft lost.

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

[onitzuka]

I see your confusion, but we are lucky that to help clear this up for you is another commenter on this post has provided their own real world example of this very LOCK-IN PROBLEM. Please give it a read.

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

[ValuJet]

No, it is you who still don't get it.

Yes, you have to code differently for the google app engine. Code deployed on other app servers will most likely not be ready to compile directly to the GAE.

Code on the GAE however would easily be ported to other servers... See how this is different? You would have to create your tables and set up your configuration settings.

The thing you don't seem to understand is that if you write an app for the app engine it can be ported to another container. This is a true statement.

Something written on another container is not able to be easily moved to google. This also is true of a subset. All things in the app engine are a part of the java spec.

Not all things in the java spec are available in the google app engine. This isn't a difficult concept. It isn't creating lock-in to make it hard to move to the app-engine but easy to leave.

Seriously

[postmortem]

Sun should be begging Google to be bought by them, not this. Google gets OS, hardware, development platform and bunch of products it can use for themselves. And all of it for almost a pocket change.

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

and ...

[Anonymous Coward]

Scala, JRuby, Rhino/JavaScript, Groovy, ...

Misnomers? Misuse of words?

[davidsyes]

Flaunt vs flaut... there is a difference.

http://grammartips.homestead.com/pairs3.html
http://www.wsu.edu/~brians/errors/flaunt.html

Too bad his publicist/administrative assistant (or, he himself) missed the difference in the words.

(No, i am not bragging nor showing off, nor being pedant. I am just pointing it out...)

Re:Misnomers? Misuse of words?

[davidsyes]

OFF-TOPIC-modding cretinous SOB... how DARE you challenge me! Or the references to which i made reference. Did you do it because i insulted your sensibilities and affection toward SUN's man, or simply because you COULD? You are yet just another sad example of how the screwed up /. scoring system lets a SINGLE/SOLITARY person shaft someone down into oblivion when the system should actively corral others to weigh in to handicap people such as you, who mod someone without providing an meaningful explanation. Adverse moderation should not be allowed an anonymous comfort zone.

Google's response...

[narramissic]

An update to the original article contains this graph:

A Google spokeswoman provided the following statement in response to a request for comment: 'We provide a Java 6 runtime environment in a secure sandbox. We committed to having as many standard Java tools and frameworks work with App Engine as possible, and hope to improve the product through the feedback of developers during our Early Look.'

Legacy code? Like FORTRAN?

[mangu]

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.

I think I can speak a bit about legacy code. Where I work there are some old apps written in FORTRAN-77. Yes, I know the current name of that language isn't written all-caps anymore, but that's the whole point: the code is still all-caps, it was written in 1977 and never rewritten since then.

There's a bunch of old engineers who aren't old enough to retire who insist on keeping that FORTRAN code. I've told them and the management that those calculations aren't so difficult, just write the equations on paper and I will implement them in Python. Or just forget about writing the equations, I'm an engineer too and can read those equations from the same textbooks they read in the 1970s.

But no way, they always talk to the managers that went through college together with them in 1977 and convince them that FORTRAN it is and FORTRAN it must be. Fuck, life isn't fair...

Re:Legacy code? Like FORTRAN?

[fm6]

Most of what's wrong with FORTAN got designed in 50 years ago. Plus they're mostly part of the fundamentals of the language. Maintaining compilers that handle ancient FORTRAN design mistakes (FORTRAN was the very first high-level language, and taught all subsequent language designers a lot about how not to go about it) is one thing. Removing a class from Java is quite another. It's completely different from changing a language feature, which Sun is very very conservative about doing.

(Once had a coworker with a PhD in Physics. He was one of the few people in that field who hates FORTRAN. When I told him about the impending release of Fortran 2003, he turned green.)

And note that before you can remove an API, you have to deprecate it. That causes a warning message which tells the programmer that they need to retool. You give that a few years, then you pull the API.

Except now Sun rarely even deprecates an API. Too much blowback. And that is a formula for stagnation.

Re:Legacy code? Like FORTRAN?

[Thinboy00]

If sun deprecated/removed java.lang.System, how would you do a simple Hello World? THAT's why these classes haven't been deprecated: they're essential. The only reason Google doesn't want them is they don't work well with the "cloud" paradigm or pose security threats (real and imagined, but mostly real AFAICT).

Re:Legacy code? Like FORTRAN?

[petermgreen]

Why rewrite math code written in a native compiled language (aka fast) and probablly pretty well debugged over the years? rewriting it in python like you suggest sounds like it would just waste a lot of time to end up with a most likely slower and buggier result.

Re:Legacy code? Like FORTRAN?

[fm6]

And if they sacrificed kittens in the basement to the Great God Baal, that would be even more uncool. But they haven't done either.

Congratulations, sir.

[Estanislao Mart�nez]

Flaunt vs flaut... there is a difference.

Congratulations, sir; you just made an incorrection.

How can a SUBSET cause lockin?....

[onitzuka]

I just posted this comment today with the answer: HOWTO: Using a SUBSET to create LOCK-IN!!!.

Google Isn't Going for a Lock-In

[Comatose51]

If Google was going for a lock-in via the API, why would they show people a way to port AppEngine apps so that it can run on normal Django? What Google is going for is the ability to scale their infrastructure faster and cheaper than anyone else. They're counting on their economy of scale being better than anyone else's so that it's actually cheaper than for you to run your own datacenter. That's the whole idea behind cloud computing right? Whether that pans out is another story but that's what Google is leverage, not an API lock-in.

More of the same old story

[ClosedSource]

There's nothing that Sun hates more than a Java implementation that is designed to run faster than "100% slow Java".

The fact is that Java's claim of WORA has always been a pipe dream and it certainly doesn't work well on phones.

The reason that OAK was such a failure for embedded systems is that Gosling et al. didn't have any experience in developing successful embedded systems.

Java libraries favor abstraction over simplicity and performance which is fine on the server but counter-productive on a resource-limited device like a phone.

RE: Unfortunate Training Exercise

[Anonymous Coward]

Pilot: Rodger ... ... Tango ... Charlie ... XRay

Pilot: Rodger ... ... Proceeding to target

Pilot: Rodger ... ... Oridance Armed ... repeat ... Ordinace Armed

Pilot: Rodger ... ... Commencing Boming Run at 30 thousand feet ... repeat ... 30 thousand feet ... target in sight ... repeat ... target in sight

Pilot: Rodger ... ... Fuse's armed ... repeat ... Fuse's armed

Pilot: Rodger ... ... Doors open ... repeat ... Doors open

Pilot: Rodger ... ... Fail Safe Check ... repeat ... Fail Safe Check ... over

Pilot: Rodger ... ... Bombs away ... repeat ... bombs away ... commencing full thrust with after burners ... full turn ... full turn ... vectors up ... vectors up ...

Pilot: Rodger ... ... awaiting further orders

Pilot: Don't mind me ... but this looks a hell of a lot like Mountain View California ... not a bit like Afganistan ... you f*ckin genisus's rodger that ...

good for Google

[speedtux]

Sun Java is enormously bloated; it's time that a company with muscle cuts Java down to a reasonable size.

different platform

[nietsch]

Appserver is Googles take on cloud computing, but trimmed down to only one application instead of a whole virtual OS. It has nothing to do with Android, the mobile device OS, which may have other constraints and limitations to the Java language.