Forgot your password?
typodupeerror
Java Open Source Oracle

Java's Backup Plan If Oracle Fumbles 276

Posted by timothy
from the enough-java-should-keep-you-awake dept.
GMGruman writes "In an InfoWorld blog, Paul Krill suggests that those concerned that Java might get lost in Oracle's tangle of acquired technologies should relax a little: Java's future isn't wholly in Oracle's hands, so if Oracle screws up or lets Java languish, the popular language has other forces to move it forward nonetheless."
This discussion has been archived. No new comments can be posted.

Java's Backup Plan If Oracle Fumbles

Comments Filter:
  • by Noam.of.Doom (934040) on Sunday July 04, 2010 @08:21AM (#32791380)
    ... when being owned by Oracle?
  • by Big Jojo (50231) on Sunday July 04, 2010 @09:00AM (#32791488)
    Go away troll....

    Microsoft was entirely within its rights to extend Java to provide native support for Windows O/S. The lawsuit was ridiculous and wrongly decided.

    The issue was violating the the compatibility constraints, so that code would no longer be portable to non-Windows O/S. This was precluded by the license which MSFT signed, so the lawsuit was reasonably decided.

  • by Anonymous Coward on Sunday July 04, 2010 @09:10AM (#32791524)

    But Java's cross-platform compatibility has always been a myth. AWT apps were least-common-denominator pieces of shit most of the time. Swing apps weren't as bad, but never fit in with any desktop environment, and this only got worse as Sun kept cranking out a shitty new theme with each release of Java. Many Java apps made assumptions about file names and directory locations, and this prevented them from running on other OSes.

    The situation was slightly better for server-side Java, but we still ran into the FS path problems, and early on we had to use JDBC drivers that depended on native code (it was a few years before pure Java JDBC drivers were available for some database systems).

    The only thing that ever worked perfectly for us was to develop on Solaris workstations, and to then deploy to our servers running Solaris. Developing on Windows and deploying to Solaris was almost always a recipe for trouble. Java has never really been a viable option on Mac OS X, and Mac OS before that.

  • restraint of trade (Score:2, Informative)

    by SgtChaireBourne (457691) on Sunday July 04, 2010 @09:45AM (#32791630) Homepage

    Go away, lying revisionist troll.

    The lawsuit in 1997 against Bill's Microsoft by Sun was about contract violation. Microsoft had a contract to distribute java, not their own proprietary version of java, but bona fide java true to the published specifications. The allegations, proven in court, were that Microsoft aimed to harm to Java platform, violated the Sherman Act by illegally monopolizing and illegally maintaining aon the Intel-compatible PC OS market and the web browser market and the office productivity suite market. Microsoft was also illegal tying products, and illegally entering into exclusive dealing and exclusionary agreements (violation of Sec 1 of Sherman Act), and engaging in copyright infringement, and restraint of trade and unfair competition. It was also attempting to illegally start a monopoly in the server operating system market.

    Not only do you Microsoft toads ruin the economy, you make the net more expensive and create security problems. It'd be just fine if DHS started checking hard drives during entry or exit at the US borders and nuked any and all NTFS partitions they find. HFS, FFS, UFS, or EXT would be put on instead. Give a few months warning first and hand out Fedora CDs to those getting a warning. Then after the deadline, bam.

  • by drewhk (1744562) on Sunday July 04, 2010 @09:55AM (#32791664)

    "Java checked exceptions do absolutely nothing to help when you're working with dynamically-loaded code, for instance."

    The same is true for invoking methods through reflection. Or transforming bytecode through custom classloaders, etc.

    But these are low-level techniques that should be used with care -- exactly because they can break things in unexpected ways. But this is not an argument against checked exceptions.

  • by haydensdaddy (1719524) on Sunday July 04, 2010 @10:14AM (#32791738)

    Java has never really been a viable option on Mac OS X, and Mac OS before that.

    The reason for this was never Java itself, but Apples stranglehold on the implementation and their very public "fuck you" attitude toward developers wanting a release within 2 years of the releases on other platforms.

  • by Anonymous Coward on Sunday July 04, 2010 @10:15AM (#32791740)

    We have java swing code that runs on window, linux, and os-x. We use a custom look-and-feel so things are consistent. Ok, the one-button mouse is a pain.

    We java backend code that runs on intel (windows/linux), powerpc, and arm. I routinely deploy and test on linux-x86 and deploy to powerpc and arm targets with zero problems.

  • by EsbenMoseHansen (731150) on Sunday July 04, 2010 @10:46AM (#32791832) Homepage

    The myth is that it is especially so. Most languages are crossplatform to the same degree, including C, Python, Haskell and ECMAscript.

  • by KermitTheFragger (776174) on Sunday July 04, 2010 @10:54AM (#32791854)

    But Java's cross-platform compatibility has always been a myth. AWT apps were least-common-denominator pieces of shit most of the time. Swing apps weren't as bad, but never fit in with any desktop environment,

    Besides Apple no one cares about consistency on the Desktop anymore. Have you looked at Microsoft apps lately ? Visual Studio looks different then the rest, Office looks different from the rest, Outlook looks different from the rest of Office, Media player looks different from the rest, Home Server UI looks different from the rest and I could go on and on.

    and this only got worse as Sun kept cranking out a shitty new theme with each release of Java.

    In the like 14 years of Swing existence there have only been 3 themes in the JRE: Metal, Ocean and Nimbus. And metal is selected by default. Java never sets one of the newer themes by itself. So basically the default theme hasn't changed.

    Many Java apps made assumptions about file names and directory locations, and this prevented them from running on other OSes.

    So there are people who make crappy programs in Java. How exactly is that different from other languages ?

    early on we had to use JDBC drivers that depended on native code (it was a few years before pure Java JDBC drivers were available for some database systems).

    A few years before pure JDBC drivers were available ? That was when, 2000 or something ? Since that problem is long solved I don't really see how thats relevant today.

    Java has never really been a viable option on Mac OS X, and Mac OS before that.

    Apple does the Java implementation by their selves, not Sun / Oracle and yes, it shows. If Sun had done the Mac OS X implementation for Java it would probably be better.

  • by kthreadd (1558445) on Sunday July 04, 2010 @11:09AM (#32791888)

    It depends on what you mean when you say Java.

    The Java(tm) name is owned by Sun/Oracle.

    The Java Language Specification is owned by Sun/Oracle and is offered online for free, with a few restrictions however. As an example you are only allowed to print it once and not make any copies of it.

    The Java software platform is a piece of software licensed as GPL. Anyone can take it, modify it and give it away to someone else.

    So the answer varies depending on what you mean with Java. While the phenomenon known as Java may in theory be owned by Oracle it is in practive decoupled enough to be independent.

  • by toriver (11308) on Sunday July 04, 2010 @12:05PM (#32792120)

    No, it was a breach of contract suit; Sun and Microsoft agreed to a (publically available) contract about Microsoft making the reference implementation of Java on Windows, but then Microsoft broke the terms by doing stupid things like adding keywords (delegate, multicast [sun.com]) to the language and methods and fields/constants to the standard classes.

    I mean, this is public knowledge - why do you choose to lie? Yes, Sun was late in specifying JNI, and hence both Microsoft and Netscape came up with their own implementations of "native", but that was just one aspect of it and far from the most significant.

    In summary: You are the one without a clue.

  • Re:Scala (Score:3, Informative)

    by RPoet (20693) on Sunday July 04, 2010 @12:46PM (#32792308) Journal

    Scala is multiparadigmal; you can use the functional features when you want, and ignore them and program Java-style when you want.

  • by HiThere (15173) <charleshixsn@@@earthlink...net> on Sunday July 04, 2010 @01:46PM (#32792626)

    No, it's not decoupled enough to be independent...but it's decoupled enough to *become* independent, if enough people put enough time and work in on it. (The constraints listed mean, e.g., that the entire documentation would need to be recreated in a logically equivalent form, but in a form different enough to not run afoul of copyright restrictions.)

    Still, good progress seems to be being made in that direction. But much more should be done, even if Oracle demonstrates both commitment and competence.

  • by shutdown -p now (807394) on Sunday July 04, 2010 @05:34PM (#32793982) Journal

    we still ran into the FS path problems

    Yes, well, when trying to use some platform or technology, it helps to RTFM [sun.com].

    Seriously. Java won't make any code written in it portable automagically, but it does give you everything you need to write portable programs, and has plenty of documentation explaining how to do just that.

  • by shutdown -p now (807394) on Sunday July 04, 2010 @05:46PM (#32794034) Journal

    C# has declaration-site variance for generics, while Java has use-site variance. What this means is that interfaces which are always co- or contravariant (e.g. IEnumerable in .NET, which is analogous to Iterable in Java) can be declared as such. But if an interface has a mixture of methods, some of which are covariant and some are contravariant, the result has to be invariant in .NET. For example, IList<T> is invariant, because it has both Add(T), and indexer returning T.

    In Java, due to use-site variance, you can have a method which takes a List in a covariant or contravariant way (with "? extends T" and "? super T" wildcards), at which point you're restricted to using only those methods of List which can legally be used covariantly or contravariantly. You cannot do something like that in C#.

    To sum it up: Java generic variance is more powerful, but places a higher burden on API clients, because they have to use wildcards whenever they want variance. C# generic variance is more limited, but is completely transparent to API clients - for them, passing an IEnumerable<Derived> where IEnumerable<Base> is expected "just works".

    But then, of course, C# generics are reified, while Java ones are not. So there is some compromise whichever side you take.

  • by Zeinfeld (263942) on Sunday July 04, 2010 @10:20PM (#32795262) Homepage
    Yes, and a really bad idea for Andresen to mouth off the way he did when at the time he was attempting to claim sole credit for the invention of the world Wide Web.

    It is a curious fact that the original NCSA Mosaic documentation did not mention CERN or 'World Wide Web' anywhere. That despite the fact that 60% of the actual code in Mosaic was libwww from CERN. I know those facts as a member of the CERN team whose work was plagiarized. Later Andressen commissioned a book titled 'Architects of the Web'. It purports to have a chapter on each of the architects of the Web. Only you won't find the names I would consider the real architects, Tim Berners-Lee is only mentioned twice, both to attack him (there is no chapter on Tim). Nothing on Dave Raggett, Dan Connoly, Ari Luotonen. There were a few chapters in the book that were deserved, but most were not.

    Yes, I know rather more about the origins of the Microsoft/Netscape feud than you might imagine. Lets say that when Marc said something stupid about Microsoft that there were many of us who made sure that it did not escape notice in Redmond.

    At the end of the day the Sun lawsuit was really about giving Scott McNeally an alibi for having run his company into the ground. Then Sun and Netscape managed to persuade the DoJ to turn the anti-trust case into a massive alibi for both of them. In the process causing the DoJ to drop a valid line of enquiry (the Caldera connection and the O/S tying issue) for a bogus one. If you look at the way Netscape managed to take down Spyglass, it was essentially identical to the claims they persuaded the DoJ to make against Microsoft. And at the time Spyglass was Netscape's only competition in the browser market.

    Sun was not brought down by anything that happened in Redmond. What killed Sun was the fact that the UNIX market moved to Linux rather than Solaris and Intel and AMD started to beat Sun in chip design.

To thine own self be true. (If not that, at least make some money.)

Working...