Forgot your password?
typodupeerror
Java Programming Sun Microsystems

Sun's Phipps Slams App Engine's Java Support 186

Posted by samzenpus
from the you're-both-pretty dept.
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.'"
This discussion has been archived. No new comments can be posted.

Sun's Phipps Slams App Engine's Java Support

Comments Filter:
  • by TheRealMindChild (743925) on Monday April 13, 2009 @05:58PM (#27563671) Homepage Journal
    'Whether you agree with Sun policing it or not, Java compatibility has served us all very well for over a decade,' Phipps wrote. 'That includes being sure as a developer that all core classes are present on all platforms. Creating subsets of the core classes in the Java platform was forbidden for a really good reason, and it's wanton and irresponsible to casually flaunt the rules.'

    You mean like Java ME [wikipedia.org]?
    • by MrEricSir (398214)

      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.

      • by DragonWriter (970822) on Monday April 13, 2009 @06:22PM (#27563915)

        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.

        • by sohp (22984) <{snewton} {at} {io.com}> on Monday April 13, 2009 @06:34PM (#27564035) Homepage

          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.

          • by DragonWriter (970822) on Monday April 13, 2009 @06:49PM (#27564203)

            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: (Score:3, Interesting)

            by jrumney (197329)
            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 hav
            • by ChunderDownunder (709234) on Monday April 13, 2009 @08:49PM (#27565269)

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

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

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

              • Re: (Score:3, Informative)

                by IntlHarvester (11985) *

                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.

  • by beanyk (230597) on Monday April 13, 2009 @05:58PM (#27563673)

    Grr.

    • 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.
      • by pelrun (25021)

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

  • by seifried (12921) on Monday April 13, 2009 @05:59PM (#27563685) Homepage
    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 [youtube.com] vs. Google data center tour [youtube.com]. I bet for most of us Google's Java AppEngine implementation will be "good enough".
    • Re: (Score:3, Interesting)

      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 afters
      • by seifried (12921)
        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
  • by AKAImBatman (238306) * <akaimbatman@[ ]il.com ['gma' in gap]> on Monday April 13, 2009 @06:00PM (#27563705) Homepage Journal

    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.

    • by kaffiene (38781) on Monday April 13, 2009 @06:20PM (#27563893)

      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: (Score:3, Insightful)

        by AKAImBatman (238306) *

        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

        • by deraj123 (1225722)

          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.

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

      • 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

      • by khchung (462899) on Tuesday April 14, 2009 @12:01AM (#27566355) Journal

        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.

    • by curunir (98273) *

      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 [sun.com] or the Java Isolates [jcp.org] JSR.

      That combined with the Java Resource Consumption Management [jcp.org] AP

  • by bogaboga (793279) on Monday April 13, 2009 @06:02PM (#27563717)

    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.

    • 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: (Score:3, Interesting)

        by burris (122191)

        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.

    • 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 co

  • Like J2ME/CLDC? (Score:4, Interesting)

    by Anonymous Coward on Monday April 13, 2009 @06:02PM (#27563723)

    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: (Score:3, Insightful)

      by CarpetShark (865376)

      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: (Score:3, Interesting)

      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.

    • by Roadmaster (96317)

      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 be

  • by onkelonkel (560274) on Monday April 13, 2009 @06:07PM (#27563765)
    The word is flout not flaunt. English is harder than it looks.
  • by Gutboy (587531) on Monday April 13, 2009 @06:10PM (#27563789)
    COBOL compatibility has served us all very well for over a decade, and to develop new programming languages is wanton and irresponsible.
  • 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 do
    • Re: (Score:3, Interesting)

      by ultrabot (200914)

      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.

    • Visual J++ was what we screamed about, and Sun sued Microsoft, and Microsoft backed down and took J++ off the market.
    • Re: (Score:2, Insightful)

      by ValuJet (587148)

      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,

  • AP Java Subset? (Score:2, Insightful)

    by firefoxman (1290234)
    The CollegeBoard uses a subset of Java in their AP curriculum, and they don't get a complaint?
  • by pohl (872) on Monday April 13, 2009 @06:22PM (#27563917) Homepage

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

    • Re: (Score:2, Insightful)

      by lfaraone (1463473)

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

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

  • by nietsch (112711) on Monday April 13, 2009 @06:28PM (#27563985) Homepage Journal

    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?

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

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

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

    Each VM/platform has its strengths and purpose. There should be room in the IT industry for Java, Apache Harmony, Google App Engine,

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

    there fixed that for you.

  • by owlstead (636356) on Monday April 13, 2009 @07:04PM (#27564327)

    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.

  • by onitzuka (1303967) on Monday April 13, 2009 @07:49PM (#27564723)
    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: (Score:2, Interesting)

      by ValuJet (587148)

      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: (Score:3, Insightful)

        by onitzuka (1303967)

        Your theory falls flat when you hit point #2

        The following packages do not exist. google.io.*
        google.threads.*
        google.db.*
        google.util.*

        If, in the future, google does add those libraries, I would fully expect them to be opensourced.

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

        I will do this in two parts:

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

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

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

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

Some people have a great ambition: to build something that will last, at least until they've finished building it.

Working...