Slashdot Mirror
Sun's Phipps Slams App Engine's Java Support
narramissic writes "Sun Microsystems' chief open source officer, Simon Phipps, said in an April 11 blog post that Google committed a major transgression by only including support for a subset of Java classes in its App Engine development platform. 'Whether you agree with Sun policing it or not, Java compatibility has served us all very well for over a decade,' Phipps wrote. 'That includes being sure as a developer that all core classes are present on all platforms. Creating subsets of the core classes in the Java platform was forbidden for a really good reason, and it's wanton and irresponsible to casually flaunt the rules.' Phipps characterized his remarks as non-official, saying: 'This isn't something I could comment on on Sun's behalf. My personal comments come purely from my long association with Java topics.'"
Sun confirms it!
bahahahaha. Sun? Money?
You've not been here long, eh? :)
-knewter
Seems to me they should put their money where their mouth is...
Sun *DID* put their money where their mouth is. They developed java, then GPL'd it. They bought StarOffice, the GPL'd it.
Google, on the other hand, is an advertising company that is trying to get lock-in, same as Microsoft did with their proprietary java extensions long long ago ...
'Whether you agree with Sun policing it or not, Java compatibility has served us all very well for over a decade,' Phipps wrote. 'That includes being sure as a developer that all core classes are present on all platforms. Creating subsets of the core classes in the Java platform was forbidden for a really good reason, and it's wanton and irresponsible to casually flaunt the rules.'
You mean like Java ME?
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
Grr.
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.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
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".
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.
Moderators: Before moderating a comment Insightful/Informative, check to see if a child post has already refuted it.
As someone who personally loves the Java platform, I honestly think he's making a mountain out of a molehill. As far as I've been able to tell so far, the Google App Engine supports the Java platform in its entirety, with a few caveats. Those caveats deal with the services Google offers (e.g. no JDBC accessible database) and the sandbox the apps run in (e.g. no network support, no filesystem).
AFAICT, there's nothing stopping me from, say, writing a JDBC access layer for their Data Store. Which means that Google is keeping with the spirit of the platform, and that this is mostly just a misunderstanding.
If you want real problems, try running Java apps on a shared hosting provider sometime. The limitations of those sites will have you shouting praise for what Google is offering.
Javascript + Nintendo DSi = DSiCade
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.
CLDC, the bastardized, stripped version of Java the Sun blessed and which is still the standard on many phones broke the whole "run anywhere" paradigm.
Still causes us major problems since Sun still supports and condones it despite the fact that almost all systems now could easily support a real Java version.
While I agree that google is not Mr. Friendly, I'd be surprised if this particular move is about lock-in. Not because of any belief in google's virtue; but for basic technical reasons.
If you want lock-in, you create a superset of the competitor's platform, or a variant of the platform that behaves differently, then push people to use your proprietary features. Implementing a subset of the competitor's platform just raises the cost of porting to your implementation, and creates no barrier to moving from your implementation to others' implementations.
The java-subset thing seems like a bad idea; and I'd be curious to know why they did it; but I don't see how a platform subset is a good basis for a lock-in strategy.
Wouldn't the various Java ME configurations be exactly the kind of arbitrary subsets that Phipps is complaining about?
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.
The word is flout not flaunt. English is harder than it looks.
None of them can see the clouds; The polished wings don't care.
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.
Sleep your way to a whiter smile...date a dentist!
COBOL compatibility has served us all very well for over a decade, and to develop new programming languages is wanton and irresponsible.
The justification is the same as Sun has when it creates a limited profile of Java for a special environment, like Java ME: the demands of a special environment.
You obviously have never used COBOL.
Javascript + Nintendo DSi = DSiCade
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.
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.
The CollegeBoard uses a subset of Java in their AP curriculum, and they don't get a complaint?
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.
Oh, was that my outside voice?
Hmm...I wonder why they never complained about the limited subset of classes that GWT supports in client-side code.
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
http://code.google.com/appengine/docs/java/runtime.html#The_Sandbox
So I would say the reasons behind their decision would boil down to "cutting out the stuff that isn't compatible with the model the App Engine uses to run things".
Yeah, this is garbage. Watch the "campfire" videos, a boringly large part of the presentations is given over to how you are not locked in, because AppEngine exposes the standard Java servlet container and database access APIs even though it's based on BigTable which is not a standard database. They show how the guestbook app can be taken right across to run on WebSphere with no code changes. The design of Java on AppEngine is pretty much the opposite of lockin - they've clearly put a lot of effort into ensuring a very, very different underlying system can export the standard Java APIs.
As to why it's a subset, I guess the same logic as applied to the Python implementation which is also a subset - due to the way it works the classes need to be audited for security problems. Some of the Java APIs contain native code which probably has to be rewritten or at least very carefully audited to ensure you can't break out of the sandbox. And some I guess just aren't that useful. But I don't really know the reason.
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.
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.
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.
As far as I have learnt from a few cursory glances at appengine, it does not offer a complete OS environment. It is severely sandboxed, probably as a measure of security. All classes that deal with those non-existing features can either be non-existing, or exception-generating stubs. Google choose for those classes to be non-existent. That is something different than creating this-environment-only classes and functions, like MS did with their corrupted java. But there are prominent links on the appengine homepage to submit your own featers and bugfixes, so maybe all these complainers can contribute patches instead of contributing whine?
This space is intentionally staring blankly at you
While I agree that google is not Mr. Friendly, I'd be surprised if this particular move is about lock-in.
It never is. Whenever somebody modifies standard technology to suit themselves, they get accused of trying to create lockin. That's what happened when Phil Katz decided he could redo the ARC format faster and smaller. That's what happened when Anders Hejlsberg decided he couldn't live with Java's limitations. Netscape and HTML. Microsoft and HTML, CP/M, x86....
Lockin does usually occur when people do things in a different way, and the different way ends up being the de facto standard. But that's not why they do them. They do them because developers just plain like to do things their own way.
In the case of Google's "white list" this doesn't even come close to being lockin, because any application that will run on Google's classes will run on "standard Java". Sun's problem is that the reverse isn't true. And I'm not sure that really matters. Unless I've missed something, the missing classes are all legacy cruft that should have been deleted from Java long ago.
So why haven't they been? Lack of will. One Java core engineer told me that Sun got in trouble when they even deprecated an API, never mind removing a whole class. People just don't want to fix up all their legacy code, and Sun was too anxious to monetize Java to stand up to them.
Google has more flexibility, since they don't need for their version of the Java platform to make money anytime soon.
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()?
Then subclass for f***'* sake
Visual J++ was what we screamed about, and Sun sued Microsoft, and Microsoft backed down and took J++ off the market.
Palm trees and 8
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.
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.
Save your wrists today - switch to Dvorak
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.
there fixed that for you.
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.
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.
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.
Mmm.
Anybody want a peanut?
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.
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.
I hope the guy didn't notice that, otherwise he'd go bizerk.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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
Scala, JRuby, Rhino/JavaScript, Groovy, ...
Those sandboxing restrictions remind me a little of the restrictions already in place for applets.
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...)
Previously: "Linux... Toward the Sunrise..." Now: "Linux... Toward the-- No, now, part of Every Sunrise"
Please. Not every shoot-from-the-lip blog entry is part of a FUD campaign.
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.
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...
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:
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.
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.
The Right Way:
Google's way:
$ make available
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?
It's not the restrictions, it's the implementation. Normally, existing Java code could just be compiled on the embedded system, and compiler errors would specifically identify security reasons for specific classes/methods/etc being disabled. Google removed the classes entirely, so the developer will just get IDontKnowWTFThatClassIs exceptions instead, which are less informative.
It also contravenes existing standards, sort of like making "dangerous" files invisible to unprivileged users in *NIX (via some sort of arcane black magic, perhaps a modified (munged) shell or something...) instead of just setting appropriate file permissions.
$ make available
Citation needed, please. Here's what Google's documentation about java.lang.System says:
What about this is unreasonable? Where does it say that apps will get ClassNotFoundExceptions? Please stop spreading unsubstantiated FUD.
Congratulations, sir; you just made an incorrection.
Are you adequate?
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?
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.
$ make available
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?
I like that better than The Sun Way:
Rampant carbon sequestration destroyed the Dinosaurs' tropical paradise. I'm here to help repair the damage.
I just posted this comment today with the answer: HOWTO: Using a SUBSET to create LOCK-IN!!!.
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.
EvilCON - Made Famous by
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.
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.
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 ...
It is. Although "write properly once - run anywhere" would probably be more accurate.
Isn't that "write once, debug everywhere"?
For a site about things like basic rights, Slashdot users sure do like to censor "dissent".
Sun Java is enormously bloated; it's time that a company with muscle cuts Java down to a reasonable size.
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.
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.
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.
What's in a sig?
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)
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.
This space is intentionally staring blankly at you
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.
Dual Opteron < $600
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.
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.
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.
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.
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.
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...
Oh, was that my outside voice?
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.
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.