Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Communications Businesses Google The Internet Software Java Programming

Google, Sun Headed for Showdown Over Android 124

Posted by Zonk from the immovable-object-vs.-nuclear-furnace dept.
narramissic writes "There may be trouble brewing between Google and Sun. Google has written its own virtual machine for Android, 'most likely as a way to get around licensing issues with Sun.' If Google used any of Sun's intellectual property to build Dalvik, Sun could sue Google for patent infringement. But here's where it gets interesting - Sun is a vocal advocate for open source and it would 'hardly appease the open source community to sue Google over an open source software stack.'"
This discussion has been archived. No new comments can be posted.

Google, Sun Headed for Showdown Over Android More

Google, Sun Headed for Showdown Over Android

Comments Filter:

  • To put it bluntly. (Score:5, Insightful)

    by LWATCDR ( 28044 ) on Friday November 16, 2007 @10:27PM (#21386971) Homepage Journal
    So reporter thinks that Sun might sue Google for forking Java all the while over looking the fact that Sun has GPLed Java and that other groups have produced versions of Java with out getting sued. Google and Sun both are saying that they are working together.
    In other words a none story.

    • Re: (Score:3, Interesting)

      by Anonymous Coward
      No, it's not a non-story.

      OK, mini-rant about Sun and Java's naming. Java is three distinct things that Sun has helpfully lumped into one name:

      1. The virtual machine.
      2. The collection of libraries.
      3. The language itself.

      Google is using #3, the Java language. They are not using #1, the virtual machine, and using only some subset of #2, the collection of libraries.

      Now given the way that Sun sued Microsoft over changing parts of Java in the past, it's almost guaranteed that they'll do it again over Google not u
      • There used to be something like this with JavaScript, though I don't think Sun ever owned that -- wasn't it Netscape? Ah, well...

        I remember Microsoft re-implemented it from scratch, but because someone owned the name "JavaScript", they simply called it "JScript".

        So, Google is now selling the brand "Android", which is a shift from the pseudo-codename "gPhone". It seems like they're in an ideal position to say "Fine, we won't call it Java." And they will be careful to refer to it only as the "Android language
        • I could be remembering this completely wrong, its been a few years since I've looked at JavaScript, much less payed attention to it. But...

          Netscape incorporated Java Script, I don't think they ever actually "owned" it though, in so much as Java Script was more of an idea out in the wild long before it was a formal language. The inventor of Java Script came up with the idea while working for Netscape, he's the lead developer for Mozilla now(I think?). The whole JS idea was really a clever hack that he c
          • from Wikipedia:

            JavaScript was originally developed by Brendan Eich of Netscape under the name Mocha, later LiveScript, and finally renamed to JavaScript. The change of name from LiveScript to JavaScript roughly coincided with Netscape adding support for Java technology in its Netscape Navigator web browser. JavaScript was first introduced and deployed in the Netscape browser version 2.0B3 in December of 1995. The naming has caused confusion, giving the impression that the language is a spinoff of Java and h

        • Re:Change the name. (Score:4, Interesting)

          by ClassMyAss ( 976281 ) on Saturday November 17, 2007 @01:45AM (#21387821) Homepage
          Jonathan Schwartz's blog post seems to indicate that Sun would prefer to milk this for the publicity rather than cause a fuss over it. Whatever happened behind the scenes, I took that post as a white flag from Sun, basically saying, "Look, we're not on board for a bunch of reasons, but we've got no beef here, let's all try to get along and spin this to each of our needs."

          Even if the VM is not officially Java, you're still ending up with a whole lot of development energy invested in Java, which is good for Sun. I really hope there's no way they are stupid enough to bring this to court just to make a few bucks...

      • Re: (Score:3, Interesting)

        by Bill, Shooter of Bul ( 629286 )
        Yes, it is a non story. Sun sued Microsoft years before they open sourced java. Micorosft has also signed a license saying that they would not fork java, but they did anyways. In this case Sun says its cool, then its cool. I don't know how true your assertions about Java ME are, but they are not true of Java in general. GuI interfaces are usually done horribly in Java, because its easy to screw them up. The unresponsive Gui (see zend framework) often makes people think that Java is slow.

        • Re: (Score:2, Informative)

          by Dr. Slacker ( 31348 )
          I think you forgot that MS had to stop using their Java VM and use Sun's VM instead. If you look in an XP machine's Control Panel you'll see Sun's JAVA icon.
          • MS didn't have to stop using their VM in the original Java court case, which only required two remedies:

            1) That the MS VM defaulted to standard Java and used a switch to engage MS extensions instead of being the other way around, as was originally the case.
            2) Microsoft would add all standard Java classes including JNI to their distribution instead of shipping a subset that made writing multi-platform code difficult.

            It actually took MS about a month to comply with these orders by making an update available t

        • Re:To put it bluntly. (Score:5, Insightful)

          by Actually, I do RTFA ( 1058596 ) on Saturday November 17, 2007 @02:30AM (#21387979)

          GuI interfaces are usually done horribly in Java, because its easy to screw them up. The unresponsive Gui (see zend framework) often makes people think that Java is slow.

          Unresponsive is slow. From a user's (and my) POV, I don't care if code executes in 10ms or 299ms if the GUI refreshes every 300ms. Why, because I use a program to do things, not to marvel at the effiency of the algorithim (unless I'm examining the code).

          Additionally, a lack of progress bars leads to killing processes and restarting them, making them slower in reality.

          • Additionally, a lack of progress bars leads to killing processes and restarting them, making them slower in reality.

            Yes, this is the biggest problem I have with most amateur-level software. So I am careful to avoid it on the rare occasion I write anything, and provide plenty of status messages. But too often you will click something and then wait for a long time with no updates. My current favorite offender is Vega Strike, a cross-platform spaceflight game. There are many times when it looks like it's frozen.

          • The unresponsive Gui (see zend framework) often makes people think that Java is slow.
            Unresponsive is slow.
            I understand your argument that GUI unresponsiveness makes an application "slow", but he means that bad GUI programming leads people to think the entire language/platform is slow by nature, which is untrue.

            Lack of progress bars in an application doesn't make Java slow, for example.
        • Very good point. Java code, written properly, can be as fast as anything. Anyone ever seen Jake? It's the open source Quake II engine translated into Java (from C++); it beats the Quake II engine in benchmarks.

      • Re: (Score:3, Informative)

        by Pollardito ( 781263 )

        Now given the way that Sun sued Microsoft over changing parts of Java in the past, it's almost guaranteed that they'll do it again over Google not using their virtual machine or library.

        but did they just take away things from the library and not add new features to the core? it's one thing to release a new platform that doesn't support all of the java libraries, that just means that existing programs aren't completely portable to your new device and is really your own loss. it's another to do what MS did and that is to add language features (method pointers for callbacks), release a developer suite for your bastardized version of the language, and encourage people to develop programs us

      • Re: (Score:2, Interesting)

        by ReeceTarbert ( 893612 )

        There's a reason Java ME has gone nowhere

        Uh? You are kidding aren't you?

        What about this list of Networks Operatos and Carriers [sun.com]

        Or the Java ME Device Table [sun.com]?

        Or, for that matter, what about these phones from Nokia [nokia.com], Motorola [motorola.com] and Sony Ericcson [sonyericsson.com] just to name a few?

        Google is trying to succeed where Java has failed

        I agree that there's a lot NOT to like about Java, but calling it a failure it's just trolling... and I just fell for it! ;-)

        RT
        --
        Your Bookmarks. Anywhere. Anytime. [simplybookmarks.com]

        • Re: (Score:2)

          by Fizzl ( 209397 )
          Platform is there, but applications are not.
          I have develop some stuff for Java ME just to get familiar with it. I don't own the latest and greatest phones, so trying to use graphics for even UI was a show stopper.
          I have also coded module tests for the standard libraries and JSR's for one manuacturer. I tried running them on different manufacturers platforms just for fun, and found out that the API is not reliable accross platforms, which means that you have to develop towards the lowest common denominator.

          • It's handy if you just want to make some simple forms and display simple data, but for real application development I find it insufficient.

            True. If you stick to the CLDC/MIDP profile your options are fairly limited, but usually developers target one series from one manufacturer. For instance, for a Series 60 model from Nokia, in addtion to the Connected Limited Device Configuration CLDC 1.1 (JSR-139) [jcp.org] and the Mobile Information Device Profile MIDP 2.0 (JSR-118) [jcp.org] you could use:

          • You sir, need to head over to http://wap.getjar.com/ [getjar.com] with your mobile phone and see all the quality apps developed and uploaded for testing and evaluation With your desktop browser just go to www.getjar.com and see what's available there

            and the best part of all these things are: they run in a java sandbox on your phone and uses gprs so you end up doing most everything you can do with a desktop browser, but on your phone and for the equivalent of a couple of cents

            I have heard some complain about i
      • There's a reason Java ME has gone nowhere, and Google is trying to succeed where Java has failed.

        I take it that by "nowhere" you mean "into pretty much every phone in use today, with one notable exception (iPhone)"...

      • Re: (Score:2)

        by mcvos ( 645701 )

        I can't really blame Google though, since the VM is why Java is notoriously slow, and the libraries is why it's notoriously member hungry. For a PC that's not a big deal, but on a mobile device, it is. There's a reason Java ME has gone nowhere, and Google is trying to succeed where Java has failed.

        Java has not been notoriously slow for a couple of years now. Unless you consider C++ notoriously slow, because that's about how fast Java 5 JVMs are. It is true that Java is somewhat memory hungry, but I don't

    • Re: (Score:2, Interesting)

      by davester666 ( 731373 )
      I think Android is good for the cell phone industry and for developers in that it sounds like it's a full reset of the API's that are available to developers. The current setup that Sun provides has boatloads of backwards compatibility cruft and old API's like AWT that just don't help with providing either great experiences for developers or end-users. If anything, Sun will jump on the Android bandwagon by adding the same API's to their VM [making it even more bloated].

      • Re: (Score:2, Interesting)

        by ClassMyAss ( 976281 )
        Indeed - Sun made a lot of big mistakes early on that have severely hampered Java's acceptance since then:

        1) The first VMs were truly awful and slow
        2) Terrible browser integration with applets
        3) AWT as a whole was just a mess, and Swing didn't do much to help things.
        4) Brought the language out as a trimmed down C++, only to realize that some of the stuff in C++ was actually useful and put it back in later (it happened with generics and static imports, and if reason takes hold it will eventually happen

      • The current setup that Sun provides has boatloads of backwards compatibility cruft and old API's like AWT

        This may be true for desktops, but the version used on mobile phones and other handheld devices has no AWT (or Swing for that matter) and it's called Java ME [sun.com] -- check the Platform Overview for the details if you like.

        RT
        --
        Your Bookmarks. Anywhere. Anytime. [simplybookmarks.com]

    • Re:To put it bluntly. (Score:5, Informative)

      by fm6 ( 162816 ) on Friday November 16, 2007 @11:34PM (#21387309) Homepage Journal
      Pretty much. But it's worth noting that many companies in Sun's position would sue Google. Not only did Google clone Sun's Java technology, they hired some of Sun's best Java people to do it. Of course, suing wouldn't accomplish much, but some ego-driven CEOs wouldn't let that stop them.

      • Re: (Score:3, Insightful)

        by cromar ( 1103585 )
        It's not the CEOs. It's the PR and legal depts.

        • Re: (Score:2)

          by fm6 ( 162816 )
          I think I speak for everybody here when I say: Huh? "Hello, Legal? Public Relations here. Would you mind launching a multi-million dollar lawsuit? What, you want to check with the CEO first? Whatever for?"

    • it's a real issue (Score:3, Insightful)

      by m2943 ( 1140797 )
      while over looking the fact that Sun has GPLed Java

      Releasing software under the GPL wouldn't give Google patent rights, since Google is not basing their software on Sun's.

      and that other groups have produced versions of Java with out getting sued

      Quite to the contrary: all conforming Java implementations that have ever been produced are produced under license from Sun, and Sun has used legal threats to ensure that.

      There are a bunch of non-conforming implementations where Sun has chosen not to press the issue

      • Re: (Score:2)

        by steve_l ( 109732 )
        AFAIK, the sole patents are -as you point out- on mechanisms for bytecode verification. But there is no guarantee that google dont have a different solution to the problem.

        To make life more complex, Sun are actually breaking their own Java Community Process rules by refusing to give apache access to the test kit for Java, so that the Harmony team can test their clean room implementation of the java 6 classes. Passing that TCK automatically grants patent rights, so by denying access to the test kit, sun are

        • Re: (Score:2)

          by m2943 ( 1140797 )
          AFAIK, the sole patents are -as you point out- on mechanisms for bytecode verification

          I wouldn't be sure those are the only ones; Sun has been quite busy patenting stuff around Java.

    • A bigger story - BSD libc + Linux (Score:5, Interesting)

      by btarval ( 874919 ) on Saturday November 17, 2007 @01:42AM (#21387811)
      Well, I wouldn't quite say that it's a non-story. But IMHO there's a bigger story which has been missed. Namely, that Google decided to take a BSD-derived libc and include it as a part of their Android effort. This is running on top of Linux.

      This is a blow aimed squarely at the Free Software Foundation, and RMS's efforts to establish GPLv3. Good luck in trying to square that one away.

      Now, why in the world Google would do this is beyond me. IHMO it smacks of too much money, and too many engineers with not enough relevant things to do. But hey, if Google's goal is to try to minimize both versions of the GPL, well, I can think of no better effort.

      • And this is precisely why, when Sun GPL'ed Java my response wasn't "yay, open source java", it was "Why on earth didn't they go CDDL?"

        CDDL allowed people like FreeBSD and Apple to use the cool technology in OpenSolaris like ZFS & DTrace. It's a happy-fun-sharing license. GPL won't let you play nice with the other children.

        I was wondering how long it'd take for someone to decide the risks of GPL just weren't worth it, and create their own JVM

        • CDDL allowed people like FreeBSD and Apple to use the cool technology in OpenSolaris like ZFS & DTrace. It's a happy-fun-sharing license. GPL won't let you play nice with the other children.

          Um, no, not quite. CDDL allows FreeBSD and Apple to use things like ZFS and DTrace with very similar freedoms -- and responsibilities -- to the GPL. It is almost the same sort of happy-fun-sharing license as the GPL. The essential difference is not a matter of the "viral clause" because they both have it. The difference lies in the fact that CDDL insists on certain things regarding patents; and being a different license than the GPL, it's a sticky point to mix the two on the same system.

          In short, CDDL and

          • Incorrect.

            CDDL has a viral clause wit a very limited scope. That is, it is limited to the file, rather than GPL's "product".

            There is nothing in the CDDL that prohibits the use of GPL code ( or the use of CDDL code in a GPL project ), other than you cannot change the license. Since the GPL wants you to change the license ( to the GPL ), this is where the fundamental difference is.

            So yes, it's the GPL that doesn't let you play with other children... it wants everyone to be GPL or BSD

            • Re: (Score:2)

              by HiThere ( 15173 )
              This is technically almost correct...but only because the GPL was there before the CDDL was. Were the time order reversed you could make the exact same argument about the CDDL.

              OTOH, the CDDL, as I remember it (not certain...I haven't kept up with Sun's license versions) had special advantages for the company that originated the software (or perhaps just for Sun). But this might have been an earlier license, or an earlier version of the CDDL. (The one I'm remembering was based off the MPL. I looked it ov
              • "the real advantages of the GPL is that I know what the license means without having to buy a lawyer."

                Really? Can you dynamically link to a GPL library with non-GPL code?

                are you sure? 100% sure?

                "I don't remember exactly what it said, but it was about patents."

                The CDDL explicitly grants you immunity from patents. the license says that they cannot sue you for infringing on any patents contained within the CDDL code, and if anyone's going to be sued for patents, it's Sun ( so if you extend OpenSolaris

                • Re: (Score:2)

                  by HiThere ( 15173 )
                  That sounds like the explanation they gave at the time.

                  I read the original license, read their changes, and wasn't satisfied. But I didn't need to use that license, so I didn't ask a lawyer.

                  As for your question "Can you dynamically link to a GPL library with non-GPL code?", I try to avoid getting NEAR to the edges of legal agreements. If I had to do what you are suggesting, I'd either contact the licensor, and get their explicit approval, or get a lawyer and get HIS explict approval. So far I've never ne

      • Re:A bigger story - BSD libc + Linux (Score:4, Informative)

        by DavidNWelton ( 142216 ) on Saturday November 17, 2007 @03:19AM (#21388153) Homepage
        No, it was aimed squarely at having a smaller libc than glibc, according to the google guy who was hanging out on #android. It is an "embedded device" with space constraints, you know!
      • Square that? Many of us don't need to.

        I'm a total fan of open source projects. Except I don't like the GPL. I consider it too restrictive because realistically, I need to be able to work with different licenses and closed source projects.

        If I make something derived from a GPL'd library, then yes, I'll GPL it only out of compliance.

        But if I had a choice, my public works would be BSD-style because I'll put my money where my mouth is and share.

      • This is a blow aimed squarely at the Free Software Foundation, and RMS's efforts to establish GPLv3. Good luck in trying to square that one away.

        Not really. The GPL doesn't disallow that kind of behavior for a reason - because part of the idea of the GPL is to permit interoperability. If that were against the spirit of the GPL, it would be explicitly disallowed. But that would also mean that the GPL was unnecessarily restrictive of choice, and it would not be as popular as it is today.

        The point of the GPL is NOT to force all software to be GPL. It's coercion, maybe, but not force. You have a choice - you can write that software all yourself, or y

      • Re: (Score:2)

        by LWATCDR ( 28044 )
        "This is a blow aimed squarely at the Free Software Foundation, and RMS's efforts to establish GPLv3. Good luck in trying to square that one away."
        You mean the version of GPL that has the anti-tivo clause in it. Gee I wonder why Google wouldn't want to use that...
        BSD LIBC has been used in Linux before. Several commercial Linux programs have used bsd libc so they could statically link it with their software. lgpl doesn't allow this. It allowed the the commercial software companies to create executables that
    • "In other words a none story"

      Yup, but watch while everybody jumps onto the empty hook anyway...this is /.

    • Re: (Score:1)

      by Xordan ( 943619 )
      Parent is correct that this is a non-story.
      I went to a talk by Scott McNealy (Chairman and Co-founder of Sun) at Imperial College London this week and the question of what Sun's stance on Android is was asked to him.
      His response was that they totally welcomed and supported this move, and that they were sure that there would be no breakages in core API compatibility between the Sun VM and Android.
      This break in the core API was the main reason why Sun sued Microsoft, before Java was GPLed (also the reason why
    • Google's VM is not a Java VM. That is, it does not execute Java bytecodes and does not follow the JVM specs. Rather, Google has basically a recompiler that can read a Java class file and generate code for Google's VM.
  • Anyone know how much a cell phone manuf has to pay Sun to include the J2ME VM in their product?
    • I'm going to go with 0, since Java is open-source and free. Somebody correct me if I'm wrong on this point. How Sun makes money on Java is a very complicated question, but up front, none. Similar questions like how they make money on the open-source Solaris OS are equally difficult to answer. But it all fits into the same business model.

      • Re:Does Sun make any money from Java on phones? (Score:5, Informative)

        by ricegf ( 1059658 ) on Friday November 16, 2007 @11:29PM (#21387289) Journal

        I don't know for sure, but since it's Slashdot, I'll happily speculate. ;-)

        Java is GPLed. A manufacturer is free to tweak Java for his machine and ship it... with the source code. Or, he can pay Sun a nominal fee for a non-GPL license and tweak to his heart's content, and keep his tweaks to himself.

        This is precisely the dual-license model used for QT, and it works pretty well. Free software gets to use the technology for free. Proprietary software pays for a proprietary license, but they're charging their customers anyway. Everybody's happy. Well, except for BSD advocates... ;-) ;-)

        • > Well, except for BSD advocates... ;-)

          Actually, I'm happy too.

        • Re: (Score:3, Interesting)

          by kripkenstein ( 913150 )

          This is precisely the dual-license model used for QT, and it works pretty well. Free software gets to use the technology for free. Proprietary software pays for a proprietary license, but they're charging their customers anyway. Everybody's happy.

          Well, I'm not sure Qt is such a good example. In fact many (including me) believe that the reason GTK+ has been popular in recent years (used on all major desktop distros - Ubuntu, Fedora, SUSE; Nokia devices; etc.) is precisely the licensing issue. Imagine if Linux itself (the kernel) used that licensing model - GPL for free, pay up otherwise. Would Linux be as popular today? I doubt it.

          The general model of GPL for apps, LGPL for frameworks that apps run on top of, makes sense. You want to extend the k

        • Re: (Score:2)

          by Goaway ( 82658 )
          Incorrect.

          Java on the desktop is GPLed, with an extra exception that allows non-GPL software to run on it.

          JavaME does not have this exception, thus forcing phone manufacturers to pay for a commercial license to escape having to GPL their entire software stacks (which they will not and often can not do).

          And that is why Google made their own VM, to work around this huge limitation Sun put in to protect their profits.

      • I'm going to go with 0, since Java is open-source and free. Somebody correct me if I'm wrong on this point.

        Quoting from Java ME Lincensees [sun.com]:

        The companies listed below have licensed Java Platform, Micro Edition (Java ME) configurations and profiles and the associated Technology Compatibility Kits (TCK). Only Java ME technology licensees can claim compatibility with Java ME technology specifications and TCKs.

        The list is quite long and of course includes the usual suspects.

        RT
        --
        Your Bookmarks. Anywher [simplybookmarks.com]

    • I'm not sure what you have to pay, but it is something.

      Here's a better article [betaversion.org] about the same thing. I was wondering if this story was going to get picked up anywhere.

      I don't think JavaME [java.net] will be given away any time soon. It's going to be really interesting to see what Sun does here.

      -ec

  • nothing to see here (Score:5, Informative)

    by doktorjayd ( 469473 ) on Friday November 16, 2007 @10:30PM (#21386985) Homepage Journal
    FTA:

    While Sun declined to comment directly for this story, it pointed to some public statements from company executives. Jonathan Schwartz, president and CEO of Sun, wrote a blog post congratulating Google on the day of Android's launch. Notably, he refers to Android as a "Java/Linux" platform

    where is the trouble? the article is pure beat-up.

    the reason for dalvik is entirely technical. check out the youtube presentations, it makes it pretty clear that you develop in pretty much pure java, but the runtime needed a little more than the standard jme could provide.

    move on..

    • Re: (Score:2)

      by Goaway ( 82658 )

      the reason for dalvik is entirely technical.
      Incorrect. There is a very big legal issue in that Sun does not allow non-GPLed software to run on the GPLed mobile Java unless you buy a license. That is what this, and many previous and no doubt many future stories are about.
  • Schwartz is sencerely all for oepn source, and he insists he's not interested in sueing anyone over patents. They might sue over license infringement of course, but in this case there is none. It's all Apache code. The only sore point is that Android doesnt include a complete and compliant Java stack (neither JME or JSE), only a subset, so they wont be able to certify it as a compliant implementation, and therefore it's technically not 'the Java platform', it just looks alot like it. Google knows this, so t

    • The only sore point is that Android doesnt include a complete and compliant Java stack (neither JME or JSE), only a subset, so they wont be able to certify it as a compliant implementation, and therefore it's technically not 'the Java platform', it just looks alot like it. Google knows this, so they've been careful in their videos to only say 'written in the Java programming language'.

      IANAL, but I bet you that actually doesn't work legally. Saying that the programs would be "written in the Java programm

      • But you actually use Sun's javac to compile the initial phase. If I wrote a compiler that took executables produced by MS's Visual Studio and compiled them into some virtual machines bytecode, and it didn't worth with executables from GCC or any other compiler, I could say "you write your programs using Microsoft Visual Studio, and then run the result through this convertor" in full legality; I couldn't even describe my product if I weren't allowed to. This is in fact exactly what Google has done.

  • FUD (Score:2, Informative)

    by mritunjai ( 518932 )
    Sun and Google are good partners, and I don't see them getting into legal minefield over this issue. Heck, Sun has never been a litigious, two main cases being MIcrosoft (bastardizing Java) and NetApp (counter-suing them... in California vis-a-vis NetApp filing in lower Texas court).

    However, there *definitely* would be issues raised by Sun over this issue. You can fork and modify their Java implementation all nilly-willy you want but you CANNOT call it Java unless it passes *all* the certification tests.

    So
    • The article does appear to be FUD, however your assertion "So unless Google certifies their implementation, it cannot be called Java, and if Google doesn't - there *would* definitely be issues. Sun doesn't take bastardization of Java lightly!" is not only difficult to parse, but unnecessary. The article states: "By contrast, Google carefully appears to avoid calling Android a Java platform. Google describes the Android software development kit as a set of tools that lets developers create applications using

    • Re: (Score:1, Flamebait)

      by m2943 ( 1140797 )
      Sun and Google are good partners

      Really? In what way? If anything, Google keeps demonstrating that one can build enormously scalable and highly reliable web services completely without Sun hardware.

      So unless Google certifies their implementation, it cannot be called Java,

      And it is not called "Java", it is called "Android". What Google is saying is that you can use Sun's Java environment to create applications for Android, which is completely correct.

      Sun doesn't take bastardization of Java lightly!

      No, Sun

  • A bit offtopic...

    How about Google bringing decent Java performance on the Web ? Possibly with OpenGL ES like for Android.
    Java on web browsers has possibly gotten worse with years. Sun loaded it so much with useless crap and didn't even try to get a proper way to vsync an applet (very important if you are trying to make a media application/game that requires the basic concept of frame-rate).

    Current multi-media web dev is relegated to Flash, but I'm sure that there are many skilled programmers out there th

    • Re: (Score:3, Insightful)

      by mhall119 ( 1035984 )

      Java on web browsers has possibly gotten worse with years.

      Java 6 update 3 contains improvements to both install and startup of the JVM within web browsers.

      Current multi-media web dev is relegated to Flash, but I'm sure that there are many skilled programmers out there that would be glad to have a lean Java VM & API working in web browsers. Sun gave up long time ago, Google could take over and make it ubiquitous.

      A new spec for easily embedded media components is in the works, hopefully it will make it into Java 7, and will be a good compliment to Java FX script on the web. There is talk about plugging it into existing media frameworks like GStreamer or VLC, to bring in all of their supported formats. Sun may have deglected multi-media, but it's not quite forgotten yet.

      • Re: (Score:2)

        by samkass ( 174571 )
        A new spec for easily embedded media components is in the works, hopefully it will make it into Java 7, and will be a good compliment to Java FX script on the web.

        I'm looking forward to Sun's renewed interest in the desktop (as someone who develops desktop Java applications). However, creating yet another media component stack on Java is a pretty boneheaded move. Clean up JMF or help FMJ succeed, then link it to the scripting engine. That would be 100x more useful than yet another media framework they'll
        • As someone who has worked with JMF, I can tell you that no amount of "cleaning up" would make it feasible for someone developing an applet or application that just needs to play a media file. You also wouldn't want to load the entire JMF just to play a file. I think it's better to make light-weight media widgets, and only employ the JMF if you are going to need more control over editing and playback. After all, there are image widgets, not image manipulation frameworks that you have to extend just to put

    • Re: (Score:1)

      by superNag ( 72318 )
      In a way, they've done that with GWT. And it's in many ways similar to Android: use Java for development, then recompile into something else (HTML+JavaScript or Dalvik bytecode).

  • Slashdot is being sensational (Score:5, Informative)

    by bogaboga ( 793279 ) on Friday November 16, 2007 @10:48PM (#21387101)
    The article that Slashdot links to is headed: "Google and Sun may butt heads over Android." Key word: "May".

    Then Slashdot modifies the headline to say: "Google, Sun Headed for Showdown Over Android."

    Question is: Does anyone of these reporters work for either company in order to have this seemingly serious situation? I doubt it.

  • J2ME (Score:4, Interesting)

    by notknown86 ( 1190215 ) on Friday November 16, 2007 @10:51PM (#21387111)
    IMHO, Android fills a void in Java Mobile applications by providing API to build richer applications (lcdui, in particular, is limiting) - more useful for Smart Phones which contain the ability to provide these types of functionalities. If J2ME filled every void, Android as an API wouldn't be needed (though Android as an OS could still fill a void). According to the article, JME requires a licencing fee. Android does not - this precludes building on the existing platform (unless, of course, Sun actually did waive the fee). Regardless, isn't it possible that this is a fragmentation where the positives outweigh the negatives?
    • > Android fills a void in Java Mobile applications by providing API to build richer applications...

      Yes, good. Richer applications. Probably the only thing like it (technically) is the iPhone SDK which isn't available to 3rd parties yet. Personally, I prefer Objective-C to Java anyway, and we've already seen some great 3rd party apps on that platform. The obvious problem is Apple hardly seems to want to support an open API on its own phone, let alone make it available to other phones. It's not too la

    • Re: (Score:2)

      by hey! ( 33014 )
      The problem with J2ME is that it isn't a product. It's a specification -- or worse a set of specifications that have different implementations on different vendor devices.

      J2ME is just like Unix was when Windows came along and kicked its ass off the low to midrange. Every hardware vendor had its own Unix, and while any Unix would have kicked Windows ass in technical terms, in effect you ended up tying your applications not only to your platform vendor, but to your hardware vendor as well. Windows not onl

  • Ahhhh, Slashdot (Score:5, Insightful)

    by ZombieRoboNinja ( 905329 ) on Friday November 16, 2007 @11:07PM (#21387187)
    Title: "Google, Sun Headed for Showdown"
    Summary: There MAY be trouble brewing between Google and Sun...
    TFA: Google COULD get in trouble with Sun, according to some analyst (but both parties declined to comment)
    Reality: Move along, nothing to see here...
    • This could be going places.

      Upcoming blogs:
      Google, Sun Fight to the death, thousands injured
      Sun uses death star to kill google, but google holds up giant mirror. news at 11.
      Google, Sun have massive war. everyone invited. Two japanese cities nuked.
  • I really think Google needs to look at more than one development language to target Android applications. Being only centered around Java is bad for more reasons than just a potential lawsuit. It locks out so many developers who are eager to contribute to the platform.

    • Re: (Score:1, Offtopic)

      by mhall119 ( 1035984 )
      With a good Java platform, you can use Javascript, Groovy, Ruby, Python, and several others.

    • Why? (Score:2)

      by Tony ( 765 )
      How does Java lock out any developer? If you're a developer, you can learn Java if you don't already know it. If you're unwilling to learn a new language, then *you* are the one selecting yourself out, not the platform.

      I had to learn C#. You can cowboy up and learn Java.

      • Re: (Score:2)

        by m2943 ( 1140797 )
        I know Java just fine, I just can't get my work done in it.

        Fortunately, it looks like Android also supports C and C++; Java is only needed for the PIM-like apps, and for that it's sufficient.

  • danger too (Score:1, Interesting)

    by Anonymous Coward
    same guy @goog wrote the Danger jvm. Oh I see! Get the one with the bigger bankroll, got it! Thx.

  • honest to god (Score:5, Funny)

    by pugugly ( 152978 ) on Friday November 16, 2007 @11:34PM (#21387307)
    I read this for a second as "Google, Sun Headed for Showdown Over Asteroid", and thought Google *might* be overreaching - .

    Pug

  • headline is kind of cool (Score:3, Funny)

    by JeanBaptiste ( 537955 ) on Saturday November 17, 2007 @12:26AM (#21387525)
    A number which is 10 followed by 100 zeros in a cage match against a hydrogen fusion reactor which accounts for 99.8% of the mass of our solar system. The whole thing happened over a misunderstanding regarding a robot designed to have human features.

  • Dalvik source available? (Score:1, Interesting)

    by Anonymous Coward
    So has google released the source code to the Dalvik VM? Any links?
  • Sun's biggest customer segment is the telco market.

    Don't be so sure that Sun is willing to potentially work against them. If I had a wireless company or division, don't think for a second that I wouldn't pull weight with Sun to get them to put some heat on Android.
  • We want cooperation. at&t and the others are already trying to lay waste to telecommunication and internet. We have some alliance to stand against them.
    Br. Cooperation instead of competition
  • I'm not terribly out of the loop when it comes to development technology, but have never heard of Android (in this context) nor Dalvik. Come on, editors, would ensuring a four or five word summary of what the heck these are, really be that hard to enhance the article, and avoid a few wikipedia lookups to simply read the news???

    Thanks...
  • There could be trouble between Google and Sun, according to someone. Google's Dalvik has advantages, according to some people, but it also has disadvantages. According to a developer not working for Google or Sun, it is possible that Google didn't pick Dalvik for technical reasons, although we don't know. There could be trouble for Google, say some people, because of 'intellectual property' Google may or may not have used, although we don't know what that 'intellectual property' might be. Stefano Mazzoc
  • Folks I already covered this.. Dalvik is an emulator VM as on OHA devices the esmertec JVM is deployed which as a Sun IP license held by esmertec. Google can get around Sun's IP as long as it does not claim the Dalvik emulator VM is not java or the java platform. Although, yo9u have to consider it a major goof on Google's part as esmertec does in fact have a JVM emulator and there also exists emulators that are full foss such as microemulator. Major goof in having th issue muddied as there is no conflict
  • Sun is a staunch advocate for open source, so it would hardly appease the open source community to sue Google over an open source software stack

    The Dalvik VM is not open source. Not only is it not open source, there has not even been a spec published for the Virtual Machine. Which is handy for the mobile phone companies because they can place their proprietary code inside the Dalvik VM and thus control the way the APIs are used. (Because you can only access them from Java code).

  • At least, that's what Jonathan Schwarz says in his weblog post [sun.com] on the topic.

Slashdot Top Deals

"Hello again, Peabody here..." -- Mister Peabody

Close