Home

News: Sun's Open Source Boss Slams Google App Engine

  1. Simon Phipps, Sun's chief open source officer, slammed Google App Engine Java support for including only a subset of the Java Runtime Environment and breaking compatibility. Simon wrote:
    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.
    In an email interview from Monday, Phipps characterized his remarks as unofficial, but other news sources had picked them up by then. The Java community in general has welcomed Java availability for Google App Engine; Google published a list of white listed JRE classes available in their sandbox. Should Simon's comments elicit an equally strong reaction from other members of the Java community? Are these white listed (and black listed) classes any different from setting up a security manager and API access policies for any other environment or run-time deployment? What do you think?

    Threaded Messages (31)

  2. I get where Sun is coming from: 'don't pull an MS style move on us and fork the JDK'. But they really created this problem for themselves by throwing every fool thing that is popular for a more than a week into the JDK. I think they've slowed down but it was really bad for a while. I'm not going to cry about the loss of CORBA packages. My guess is that this whitelist will meet the needs of 99% or more of Java applications.
  3. Early view[ Go to top ]

    Let's not forget this is an early view of Java for the appengine. I wouldn't be too surprised of the white list would be expanded over time.
  4. Agreed, Google will likely improve this situation over time. And to be clear, I am delighted they are supporting the Java platform, growing the opportunity for all of us. My reaction (at that's what it was - an SMS-length reaction the day the news broke, not a fully-developed position for publication. I hate journalists sometimes!) related more to the fact that we can't afford as a community to leave this to Google. I can't speak for Sun - I am nothing to do with Java strategy at Sun - but I believe we will need a new Java profile, let's call it Java Web Edition. If we allow each cloud provider in turn to define their own subset, we will be left in the same ugly position we have with Java on mobile phones where the common specification doesn't go deep enough and forces applications to be refactored for every different platform. On the cloud, this equates to having no freedom-to-leave. I am lready worried about that topic and think we need both a common set of APIs for provisioning in the cloud and an abstraction layer so that applications written for the cloud can move freely between providers. Java would be perfect for this - but not if every provider has a different subset. What we need as a global Java community is Java WE. I'd like Google to show leadership and a commitment to openness by taking their subset to the JCP and offering to found a working group to establish a new Java profile for cloud applications. So, am I as crazy as the Slashdot crew says I am now I've explained some more?
  5. Aren't these restrictions almost the same as the ones defined by EJB specification to achieve scalability and security (http://java.sun.com/blueprints/qanda/ejb_tier/restrictions.html)? While the spec only talks about them as a set of guidelines to achieve the scalability, but GAE enforces them to guarantee the scalability. So which one do you prefer?
  6. These restrictions were applied (and not enforced) to code developed by bean providers and not to system library vendors including transaction managers, message/database providers, management and monitoring agents - all of which are disabled by GAE. The GAE is Googles IT Stimulus Plan. Get everyone to rewrite their applications and libraries. Its going to great seeing all the OSS projects releasing new versions just trying to workaround these restrictions and causing lots of other side effects in production code running outside of the cloud itself. I prefer my Java as is. Otherwise give me another language so I can make the context switch (api, programming model,...). William
  7. Please correct me if I'm wrong, but my understanding of cloud computing is raising the abstraction to a higher level so that development teams can focus on application logic rather than system logic. This is what Application servers are supposed to do, but still there is a need for infrastructure/environment team to setup/configure/manage system level services. If there is an environment up and running with system level services like transaction management, messaging, data storage, load balancing and etc then why do I need system library vendors? Please don't get me wrong, I'm not saying GAE is there, but I think they are on the right path.
  8. Please correct me if I'm wrong, but my understanding of cloud computing is raising the abstraction to a higher level so that development teams can focus on application logic rather than system logic.
    The cloud is anything you want it to be and more. The cloud is magic. Cloud cloud cloud cloud cloud, cloud. Cloud cloud. Cloud cloud cloud cloud, cloud cloud, cloud cloud. SOA cloud cloud cloud, SaaS, cloud cloud. cloud cloud (cloud) cloud cloud, Gartner, cloud cloud cloud, web 2.0, cloud cloud. Cloud cloud cloud? Cloud cloud cloud cloud. In conclusion: cloud.
  9. Malkovich ![ Go to top ]

    John Malkovich !
  10. The cloud is anything you want it to be and more. The cloud is magic.

    Cloud cloud cloud cloud cloud, cloud. Cloud cloud. Cloud cloud cloud cloud, cloud cloud, cloud cloud. SOA cloud cloud cloud, SaaS, cloud cloud. cloud cloud (cloud) cloud cloud, Gartner, cloud cloud cloud, web 2.0, cloud cloud. Cloud cloud cloud? Cloud cloud cloud cloud. In conclusion: cloud.
    Too much clouds. Where is the Sun?
  11. From east[ Go to top ]

    SUN now needs to rise from the East :)
  12. Please correct me if I'm wrong, but my understanding of cloud computing is raising the abstraction to a higher level so that development teams can focus on application logic rather than system logic.


    The cloud is anything you want it to be and more. The cloud is magic.

    Cloud cloud cloud cloud cloud, cloud. Cloud cloud. Cloud cloud cloud cloud, cloud cloud, cloud cloud. SOA cloud cloud cloud, SaaS, cloud cloud. cloud cloud (cloud) cloud cloud, Gartner, cloud cloud cloud, web 2.0, cloud cloud. Cloud cloud cloud? Cloud cloud cloud cloud. In conclusion: cloud.
    You almost got it right. The true mantra is: cloud crud cloud crud crud crud could cloud cloud crud crud! CRUD CRUD! CRUD CRUD! cloud CLOUD CLOUD! etc You can also write your application in formula style: 1 ( Java) application = y CRUD + x CLOUD
  13. Aren't these restrictions almost the same as the ones defined by EJB specification to achieve scalability and security (http://java.sun.com/blueprints/qanda/ejb_tier/restrictions.html)?

    While the spec only talks about them as a set of guidelines to achieve the scalability, but GAE enforces them to guarantee the scalability.

    So which one do you prefer?
    That's a good point, and technically I think you're right. However, J2EE JSRs went through the Java Community Process with all its rigor, and the GAE subset did not.
  14. Aren't these restrictions almost the same as the ones defined by EJB specification to achieve scalability and security (http://java.sun.com/blueprints/qanda/ejb_tier/restrictions.html)?
    You are absolutely right. I was thinking the exact same thing. A lot of those restrictions must sound familiar to anyone who has even remotely done anything with EJB3. I guess the name "EJB" is still tainted for some reason (quite undeservedly, EJB2 is really a long time ago), otherwise Google could have claimed implementing a 'kind-of-EJB' environment. Maybe Google could should start supporting some of the most popular EJB3 annotations, like @Stateless for session beans and @EntityManager for entity manager injection (but of course should not just the term 'EJB'). In a way the platforms could strengthen each other. People coming from GAE would feel more at home when starting with EJB3, since they are already used to basically the same restrictions. Likewise, EJB3 people probably won't have any problems with the 'new' Google restrictions at all.
  15. Google should just use a custom Java policy file to restrict access to API methods they do not wish to be invoked. Go-Daddy has similar restrictions on their web apps and I believe they use the Java SecurityManager to enforce their restrictions. Using a custom policy file is a documented and supported and Google.
  16. Google should just use a custom Java policy file to restrict access to API methods they do not wish to be invoked. Go-Daddy has similar restrictions on their web apps and I believe they use the Java SecurityManager to enforce their restrictions. Using a custom policy file is a documented and supported and Google.
  17. Google should just use a custom Java policy file to restrict access to API methods they do not wish to be invoked. Go-Daddy has similar restrictions on their web apps and I believe they use the Java SecurityManager to enforce their restrictions. Using a custom policy file is a documented and supported and Google.
  18. Seems EC2 offers far more flexibility and control of your environment. For the types of needs I have most regularly, I prefer the model of having a VM OS on which I can install what I like, rather than having a rigid platform that does not support everything I may want to do.
  19. First hand experience[ Go to top ]

    I tried building some code for Google AppEngine for Java and hit this very problem. I had some classes that were doing off-screen image generation using AWT classes to I could generate and serve images via a servlet. But the AWT classes are unavailable. I know Google doesn't want us building AWT UI's on their headless servers, but the AWT classes can be used for much more! Sun actually had a problem on UNIX servers where the AWT classes (even the headless ones) couldn't be used without an X11 server present, which was a problem on headless servers. However, Sun fixed that bug nearly a decade ago! Now it's Google's turn.
  20. Google and IBM[ Go to top ]

    Oh yes, that's the news all of you who thought that "IBM would kill Java while Google would be the ideal marriage" were waiting for...
  21. If Google keeps doing this way, you might need 2 versions for your application: one running on EC2 and the other running on GAE. If you don't have the 1st version and if Google screws you up, you'll be alone in the dark.
  22. ...Ahem...uh...this is only a Beta?
  23. ...Ahem...uh...this is only a Beta?
    So, since it's a Beta, we're not supposed to discuss how we would like it to improve or the ramifications of not having those improvements? Besides, GMail is still in beta and I've been using it for years. :)
  24. This is Googles way with all Java offerings...GWT supports a subset of Java, Android likewise. I'm not at all surprised that they are doing the same with the app engine, i would have been shocked to read there werent limitations.. To be honest, I can't see the problem. Apart from anything else, supporting everything would seriously increase the cost of providing the App Engine. Amazons EC2 is a great offering also but its different. Celebrate the differences.... Diversity is good...
  25. People are repeating that the missing classes are those as per EBJ's security context, but somebody has already pointed out that Image etc is missing as well. This is not tolerable from my point of view (most of the interest about webapps for me is for image manipulation). I must confess I missed the fact that we don't have a full fledged version of Java in GAE and now that I'm aware of it I think that GAE sucks. PS Yes, Google wouldn't be a better option than IBM.
  26. I agree with Simon Phipps, the white list is TOO SHORT. For instance the entire Swing is out of this list, Swing is pure Java and contains many non-UI interfaces and classes, for instance ListModel, TableModel, TreeModel and related selection listeners in some way are the facto standards beyond desktop. For instance the tree component of Wicket uses tree classes/interfaces of Swing, wingS and Echo intensively use Swing classes and ItsNat uses UI-agnostic classes of Swing when possible. Another missing piece of GAE is "sticky sessions", replicated sessions are fine for classic page based applications, but in a world of AJAX applications with more and more state in the server, replicated sessions are problematic. I think the Single Page Interface will be the next paradigm in web programming and seems GAE does not help very much ignoring sticky sessions. Furthermore sticky sessions highly reduce the traffic in this kind of applications.
  27. Clarification: "Furthermore sticky sessions highly reduce the traffic in this kind of applications" I mean "reduce data traffic between servers in the cluster to keep in sync sessions with very much data"
  28. Single Page Interface?[ Go to top ]

    I think the Single Page Interface will be the next paradigm in web programming Hmmm... This is more of a paradox than a paradigm... The web is based on HTTP and URI. The Single Page Interface is more like client-server using a browser as the client. It essentially dismisses URI while using HTTP merely as a firewall back-door... Better use the catchy marketing name, RIA, for such apps.
  29. Re: Single Page Interface?[ Go to top ]

    Better use the catchy marketing name, RIA, for such apps.
    Yes and no, RIA means "Rich Internet Application", the "Rich" term is understood as "visually rich", you can build rich web applications based on pages too, anyway I agree with you, a rich web client is prone to be a Single Page Interface, the opposite is no fully true. Try to remember the most boring web application in the world, an application with tons of different pages. Is it rich? NO. Can be converted to a SPI? YES, this is now technically possible, there is no visual change, the only changes for the user are: 1) No longer has to deal with the back, forward, form submitting, page caching nightmare. 2) The application is more responsive because the browser only changes the piece of the page to be updated when the user does something (usually got from the server using AJAX).
  30. What Google is doing is interesting. They are creating a version of Java that compiles to Javascript. It is one of the most interesting uses of Java out there. If Sun wins no one will be able to release a Java implementation before years of development. Google doesn't claim like Microsoft did that their Java implementation is complete. And by the way, Microsoft now side stepped the issue by creating C# and guess what. That is now one of my primary languages. Sun's own choices have made Java big and bloated. Maybe they should look at why someone would not want the entire API. Are they going to go after Groovy because it relaxes Java script and ban it from the Java platform? Maybe they should just take their ball and go home.
  31. go after Groovy?[ Go to top ]

    Are they going to go after Groovy because it relaxes Java script and ban it from the Java platform? Are you forgetting JSR-223 (Scripting for the JavaTM Platform) and JSR-241 (The Groovy Programming Language)?
  32. Java Needs a Cloud Profile[ Go to top ]

    For anyone who actually cares about it today, I've written a long blog post explaining my position.