Slashdot Mirror

Harmony is open and will remain open for the foreseeable future. Its not like BEA/Oracle/IBM were big supporters of harmony before this deal was inked...

Actually, you'll find in the article that most of the code in Harmony was written by IBM employees on company time, and now that IBM is switching its efforts to OpenJDK, the ASF folks are essentially saying that Harmony is dead. While we'd all like to believe that open source projects magically maintain themselves through the gumption of citizen-programmers, the fact is that the more complex and important ones are often maintained by corporate patronage.

Certainly the move isn't just an attack on Android -- all of the other things you list are true, and the JCP was desperately in need of reform. But the fact that it guts the basis for Android's Java compatibilty can't have caused anyone at Oracle to shed any tears. Look, one of their big Java ME guys is gloating.

I thought references to 128 bit addressing and boiling oceans were reserved for storage systems, not networking! http://blogs.sun.com/bonwick/entry/128_bit_storage_are_you

correcting my own presumptions,

seems java 5 was the first 64 bit sun distribution for linux.

takes a while to get there, but you can still click round the oracle java sites and find the binaries..

http://java.sun.com/javase/downloads/jdk/142/

http://java.sun.com/javase/downloads/5u22/jdk

for the impatient

still, java 5 released sept 29 2004, so i guess i'm stretching to remember installs from 6 years ago

correcting my own presumptions,

seems java 5 was the first 64 bit sun distribution for linux.

takes a while to get there, but you can still click round the oracle java sites and find the binaries..

http://java.sun.com/javase/downloads/jdk/142/

http://java.sun.com/javase/downloads/5u22/jdk

for the impatient

still, java 5 released sept 29 2004, so i guess i'm stretching to remember installs from 6 years ago

Actually, it is automatic. ZFS already assumes you have a multithreaded OS running on more cpu than you probably need (e.g. Solaris), so it's already doing checksums (up to and including SHA256) for each data block in the filesystem. Comparing checksums (and optionally entire datablocks) to determine what blocks are duplicates isn't that much extra work at that point, although for deduplication you probably want to use a beefier checksum than you might choose otherwise, so there is some increase in work. http://blogs.sun.com/bonwick/entry/zfs_dedup has some more information on it. Getting it onto my linux box, now.. there's the rub. userspace ZFS exists, but I've only seen one pointer to a patch for it that includes dedup, and I haven't heard any stability reports on it yet.

I heard that Sun used to charge royaltees for mobile phones that licensed the J2ME platform - complaint or certified implementations. And this kinda proves this: From http://java.sun.com/j2se/embedded/faq.html#faq10: Q: Does deploying Java SE for embedded devices or purposes require a royalty? A: Yes. Sun's license for Java SE enables it to be freely used for general purpose desktops or servers. If Java SE is bundled as part of a dedicated solution that involves or controls hardware of some kind, then it's likely an embedded application and is subject to modest royalty payments. I believe Google java implementation is custom - not part of SE or ME - so they avoid having pay any royaltees to Oracle. This is why I think Oracle is pissed.

In summary, open source Java is fine, open source almost-Java is not.

If you make a derivation/fork with the open source Java code Oracle only extends patent grants if your fork passes Oracle's expensive certification tests for Java. This certification is impractical for most people or organizations and is inherently impossible for anybody who is interested in making a new language with the code or adapting some of the code for other purposes.

In summary:

• an alternative open source Java is quite difficult because the of the costs of certification
• use the open source Java codebase for anything else and Oracle can sue you for patent violations
• contributing to Oracle's existing OpenJDK codebase is fine

Sun used the CDDL just to make sure Linux never got ZFS

That's a paranoid way of looking at it. Why Sun chose the CDDL instead of the GPL was to retain the right to fork a proprietary version while retaining GPL-like lincensing in all other respects. The CDDL is a better choice for businesses than the GPL as it offers some degree of protection from FSF lawsuits while still requiring that modifications be contributed back to the community.

Quoting http://blogs.sun.com/chandan/entry/copyrights_licenses_and_cddl_illustrated
   

A common misconception is about CDDL and GPL incompatibility. (Incompatibility in the sense: to combine two source files, one under GPL and another under CDDL, to create a common executable.) GPL is incompatible with most licenses like Mozilla Public License, Apache, and CDDL. GPL wants you erase those licenses and use GPL in that place, where as these licenses do not permit erasing them. Hence the incompatibility deadlock.

there is a difference between the philosophy of how ZFS and BTRFS were architected.

ZFS has notoriously been called a "rampant layering violation", but IMHO that makes it easier to use - since it eliminates one whole layer.

BTRFS is not similarly architected: it is not an apples-for-apples replacement for ZFS.

OpenSolaris ZFS Screencast: 100 Mirrored Filesystems in 5 minutes

OpenSolaris Screencast: ZFS Self Healing

Oracle Demo: ZFS Discovery Day

Presentation: (PDF) ZFS: The Last Word in File Systems (2008)

Presentation (VIDEO) ZFS: The Last Word in File Systems" (2008)

Nexenta 3.0 webinar (Slide 18, Deduplication)

Sun ZFS drive destruction Demo

OpenSolaris ZFS Screencast: 100 Mirrored Filesystems in 5 minutes

OpenSolaris Screencast: ZFS Self Healing

Oracle Demo: ZFS Discovery Day

Presentation: (PDF) ZFS: The Last Word in File Systems (2008)

Presentation (VIDEO) ZFS: The Last Word in File Systems" (2008)

Nexenta 3.0 webinar (Slide 18, Deduplication)

Sun ZFS drive destruction Demo

I hope this idea http://blogs.sun.com/brendan/entry/test also works with the port (and will be working with btrfs one day!?):

Transparently adding an SSD into the slow-HD-to-fast-CPU-register cache hierarchy. Are there ways to make something like this work with current FSes?

Mount a nice fast SSD as swap would be a good start. Then point your /tmp to a tmpfs.

My swap is practically always empty, so that would not help much. And how much stuff gets written into /tmp? Mine is 839kiB right now, that is neglible and probably in RAM cache already. What I want cached are all the binaries and libs linked from there. Then starting any app for the second time would be near-instant and this cache would survive reboots and be one or two orders of magnitude larger than RAM.

4? Hah. I have a method in my personal code library to work around a bug in the standard Java libraries which I reported to Sun in 2002. It's marked as "Accepted, bug" but low priority. (4759386, for anyone who doesn't believe me).

"While I like to feel that Google is somehow better than Microsoft in all ways, I know this is clearly not true. The problem I do have with Google and their Java VM is that they aren't really contributing back to the core Java platform"

And how can they do it? JCP is dysfunctional, just look how long it takes to release JDK7. And there are other even more blatant examples:

What else? Google has written a lot of splendid Java libraries (like http://code.google.com/p/google-collections/ ). Sun/Oracle are free to take and integrate them into the JDK - they did this with Xerces and other libraries.

But they won't do this. Why? Because Java is dead. For example, a request to add Multimaps was filed in 1998 and is still open: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4155149 Sun can't be bothered to take one of available Multimap implementations and add it to the core JDK.

"In many way what Oracle should be pushing for is:
    - getting Google to use the standard Java byte code"

What for? To make devices run slower?

" - working with Oracle to contribute their work back to the core"

Contribute back what? Android implements core libraries very faithfully.

However, no matter how great ZFS is, you still need full backups of your ZFS storage

Backups of ZFS file systems are dead simple: http://blogs.sun.com/timf/entry/zfs_backup

I wish there was something even remotely close to this in linux world. It's extremely frustration how much I have to go through to back up my linux desktop.

this looks pretty good.

You still use the vendour name to create the input arguments for your 2nd invocation. How is that any better than

It's better because you're at least asking the runtime to describe itself instead of asking Windows to describe a DLL file. A DLL that you may not be able to trust is the correct DLL. If the runtime is lying to you, then you have much bigger issues to worry about and this whole point is moot.

In the previous post, you also said...

When your supported VMs are upgraded by the vendor - you've got a tiny little Java app to update and the rest of the behemoth is never touched.

So even if the Eclipse devs followed your advice, it still would have been broken, because you have to update at least something.

Actually, no it wouldn't, and here's why: from the first link in the summary:

An engineering side note: The "Java" property values for java.vendor and java.vm.vendor were never changed in the jdk6 releases and will remain "Sun Microsystems, Inc.".

and

The Windows specific exe/dll file "COMPANY" value is what is at issue here, not the Java properties. It came as a surprise to us that anyone would be inspecting or depending on the value of this very platform specific field.

So, while I totally agree that if the reported vendor changes, and if there aren't sufficient checks to handle this then yes, this exact same problem would still be there.

However, JDK and it's updates will "never" change the vendor string. If the Eclipse devs had taken the more correct route of determining the properties of the actual runtime they would be running under, we would never have seen this problem.

Also, from the first link:

Note that the jdk7 releases will eventually be changing to Oracle, including the java.vendor and java.vm.vendor properties.

So, we know also for a fact that with JDK 7, even java.vendor, and java.vm.vendor will change. Well, so what? We have plenty of notice, and the Eclipse devs could add code in *right now* to also allow "Oracle" in the vendor string and use the same workaround. That's what I would do.

If the workload of ensuring that your Java IDE (of all things) works with the new releases of the major JVMs is too much for you, then frankly, you're in the wrong business. Now, I accept that this change was difficult to predict, but the devs took such a short-sighted and broken view of what defined the JVM vendor that they really have to accept the blame here. Worse than that - they created an overly complicated proprietary mess to deal with it when they could have achieved the same with about 3 lines of code - code that would be cross-platform and not a special case hack.

You rant quite a lot about how incredibly bad the Eclipse devs did this job

Actually, I ranted about how there's a much better way, and somebody on the cross-platform Java IDE development team really should have known about it since it's also the class that provides you information about the nature of the freakin platform you're running on. Though, now that you mention it - yes, I agree with you, they did do an incredibly bad job, overcomplicating the whole issue, and guess what - they screwed up. Any change, intentional or not in the "COMPANY" field of the DLL (assuming they are even checking the DLL that the runtime is using - that's not even certain) will render their application totally unusable. So yes, they did do an incredibly bad job on this small part of it.

but your "solution" would have resulted in exactly the same situation.

As I've shown, my "solution" would have worked perfectly in this case, since the return value from the API has not changed. Since we also know that it will change with JDK 7, if they were using my "solut

Ok, here's some research. First, there are actually two memory areas in the VM, the heap and the Permanent Generation. It is a PermGen overflow that's causing Eclipse's problems, not heap overflow. As I understand from the linked article, PermGen is a place where VM data is stored; stuff like the class structure, method bytecodes (is that just a copy of the executable?), heap content information, etc. PermGen info used to be stored in the heap, but was moved out as a performance optimization, which incidentally is no longer relevant. I'm still not quite clear why PermGen has a fixed size. Evidently there are quite a few applications out there that routinely overrun PermGen and have to increase it. The cause seems to be people writing custom classloaders that bypass the "class already loaded" optimization, which I suppose makes sense for Eclipse where you keep modifying the class all the time and want to keep reloading it into the VM for testing. Apparently it is possible to write them in such a way that the resultant class metadata "leaks", resulting in overflow. Now, I think I'll just take a small break laughing my ass off at how those poor Java kids need 256M just to store their class definitions. I say, collect your garbage off my lawn and learn C++ already! It seems your fancy Java doesn't absolve you from the need to learn memory management after all :)

If you're incapable of doing memory management, you're an incompetent boob of a coder.

Ok, here's some research. First, there are actually two memory areas in the VM, the heap and the Permanent Generation. It is a PermGen overflow that's causing Eclipse's problems, not heap overflow. As I understand from the linked article, PermGen is a place where VM data is stored; stuff like the class structure, method bytecodes (is that just a copy of the executable?), heap content information, etc. PermGen info used to be stored in the heap, but was moved out as a performance optimization, which incidentally is no longer relevant. I'm still not quite clear why PermGen has a fixed size. Evidently there are quite a few applications out there that routinely overrun PermGen and have to increase it. The cause seems to be people writing custom classloaders that bypass the "class already loaded" optimization, which I suppose makes sense for Eclipse where you keep modifying the class all the time and want to keep reloading it into the VM for testing. Apparently it is possible to write them in such a way that the resultant class metadata "leaks", resulting in overflow. Now, I think I'll just take a small break laughing my ass off at how those poor Java kids need 256M just to store their class definitions. I say, collect your garbage off my lawn and learn C++ already! It seems your fancy Java doesn't absolve you from the need to learn memory management after all :)

If you have one or two software mainframe software packages, and don't need 5 9s, TurboHercules is much cheaper than the low end mainframes that IBM offers.

Lehemann claims that it's "Moore's Law in Action".

IBM has also fought to keep zPrime's mainframe accelerator off the market.

There's a market for consistently reliable computers, but I don't think it's quite as large as the mainframe market.

... Go would be perfect if it also allowed for *some* manual memory management along with garbage collection. A large part of java's complexity that I see in big server type situations (> 8 G heap size) is that managing the gc parameters is almost a full time job. this is the theory and set of options you need to learn and internalize to get semi-satisfactory behavior from Sun's jdk1.5 gc. The complexity has only increased.... not decreased in later jdk's.

What buttons do I have to click to get my free patches? Oh that's right, they don't supply patches for free anymore.

Wrong again. You get LOTS of free patches with a free install of Solaris. RedHat set the pace for this: if you install RHEL, you have to use up2date which requires a registered system with the RedHat Network (RHN). If you don't want to register and pay for RHN, you wait for the next release and do your upgrade from that. Sun implemented a similar system -- in planning, testing, and preliminary deployment LONG before the acquisition -- requiring registration and a support contract number before allowing entitlement to certain patches in a more timely fashion than the traditional six-month release cycle.

Maybe you just re-install every 6 months when the new media set is released? right!

Actually, you can upgrade off the install CD from the media sets, too, without reinstalling. Always have been able to, and it's a simple, easy way to keep up-to-date, though it requires some downtime to install. Downside: no zero-day exploit fixes. Upside: free patch sets every six months. As long as I've been working with Solaris -- since 1999, and up through right now while I'm downloading the latest kernel exploit & StarOffice 8 security patch on my Solaris box -- the zero-day security exploits are listed in the patch entitlement for ALL Solaris systems, not just those with a support contract.

Upgrade old release (7, 8, 9): http://docs.sun.com/app/docs/doc/817-3799/6mjcan1v6?l=en&a=view
Upgrade newer release (10): http://docs.sun.com/app/docs/doc/817-0544/6mgbagb1c?l=en&a=view (x86 on this page; the SPARC install instructions are also in the documentation)ma

To get your security patches, go to Launch-> Applications -> Utilities -> Update Manager. Go through the registration wizard. Choose "Continue without providing a Service Plan Number". Accept the software license agreement. Finish the registration; if you want to use this as a base image for mass-deployment, click the "enable auto registration" option.

Next select all updates, and install them.

I understand you're concerned with not having the latest-and-greatest usability and functionality updates to your OS on a faster-than-6-month schedule. If it's of sufficient concern to you, register for a cheap Solaris support contract through SDN and be done with it. But for the rest of the world that wants to continue using Solaris for free, CRITICAL SECURITY PATCHES ARE AVAILABLE TO ANYONE WITH A SUN ONLINE ACCOUNT.

Free security updates online as soon as you get around to installing them. Free every-six-month usability and functionality updates. What exactly is the problem with this patch schedule? That those who choose to pay nothing for a great operating system don't get usability and functionality updates on the same schedule as paying customers?

OpenSolaris exists to fill that niche: customers who need bleeding-edge features on a very timely schedule and don't want to spend a lot of money. You can even patch production Solaris boxes from OpenSolaris patches if you wish, though I understand some assembly is required. Never done that myself. Never felt the need.

Overall, I think the Oracle acquisition of Sun has been a good thing for both companies. Sun gets to keep the lights on and payroll flowing, Oracle gets a bunch of hardware & software products in its portfolio.

What buttons do I have to click to get my free patches? Oh that's right, they don't supply patches for free anymore.

Wrong again. You get LOTS of free patches with a free install of Solaris. RedHat set the pace for this: if you install RHEL, you have to use up2date which requires a registered system with the RedHat Network (RHN). If you don't want to register and pay for RHN, you wait for the next release and do your upgrade from that. Sun implemented a similar system -- in planning, testing, and preliminary deployment LONG before the acquisition -- requiring registration and a support contract number before allowing entitlement to certain patches in a more timely fashion than the traditional six-month release cycle.

Maybe you just re-install every 6 months when the new media set is released? right!

Actually, you can upgrade off the install CD from the media sets, too, without reinstalling. Always have been able to, and it's a simple, easy way to keep up-to-date, though it requires some downtime to install. Downside: no zero-day exploit fixes. Upside: free patch sets every six months. As long as I've been working with Solaris -- since 1999, and up through right now while I'm downloading the latest kernel exploit & StarOffice 8 security patch on my Solaris box -- the zero-day security exploits are listed in the patch entitlement for ALL Solaris systems, not just those with a support contract.

Upgrade old release (7, 8, 9): http://docs.sun.com/app/docs/doc/817-3799/6mjcan1v6?l=en&a=view
Upgrade newer release (10): http://docs.sun.com/app/docs/doc/817-0544/6mgbagb1c?l=en&a=view (x86 on this page; the SPARC install instructions are also in the documentation)ma

To get your security patches, go to Launch-> Applications -> Utilities -> Update Manager. Go through the registration wizard. Choose "Continue without providing a Service Plan Number". Accept the software license agreement. Finish the registration; if you want to use this as a base image for mass-deployment, click the "enable auto registration" option.

Next select all updates, and install them.

I understand you're concerned with not having the latest-and-greatest usability and functionality updates to your OS on a faster-than-6-month schedule. If it's of sufficient concern to you, register for a cheap Solaris support contract through SDN and be done with it. But for the rest of the world that wants to continue using Solaris for free, CRITICAL SECURITY PATCHES ARE AVAILABLE TO ANYONE WITH A SUN ONLINE ACCOUNT.

Free security updates online as soon as you get around to installing them. Free every-six-month usability and functionality updates. What exactly is the problem with this patch schedule? That those who choose to pay nothing for a great operating system don't get usability and functionality updates on the same schedule as paying customers?

OpenSolaris exists to fill that niche: customers who need bleeding-edge features on a very timely schedule and don't want to spend a lot of money. You can even patch production Solaris boxes from OpenSolaris patches if you wish, though I understand some assembly is required. Never done that myself. Never felt the need.

Overall, I think the Oracle acquisition of Sun has been a good thing for both companies. Sun gets to keep the lights on and payroll flowing, Oracle gets a bunch of hardware & software products in its portfolio.

Regular Sun contract support lasts 7 years, "vintage" support lasts out to 10 years, and you can pay for longer. There's plenty of people still running Solaris 8. You can even install Solaris 8 into a Solaris 10 zone or container to take advantage of new hardware. Though backward compatibility guarantees mean that 15 year old programs still work on the newest OS....

http://www.sun.com/software/solaris/lifecycle.xml

Sun already does indemnify it's customers. Schwartz pointed this out when NetApp's rumblings against Sun first happened.

Neither Schwartz or Sun exists anymore.

And the courts have said it doesn't, at least not in the way NetApp said it did the first and second time.

So that's the end of that, I guess.

It might be worth reading through NetApp's original ZFS patent lawsuit vs Sun before making wild speculations. It seems to me that they are now trying to sue other, smaller companies after their original attempt to sue Sun had failed.

Sorry buddy but the courts have ruled that ZFS doesn't infringe NetApp's patents. Read here and here. Cry more.

Sorry buddy but the courts have ruled that ZFS doesn't infringe NetApp's patents. Read here and here. Cry more.

Sun already does indemnify it's customers. Schwartz pointed this out when NetApp's rumblings against Sun first happened.

First, the basics. Sun indemnifies all its customers against IP claims like this. That is, we've always protected our markets from trolls, so customers can continue to use ZFS without concern for spurious patent and copyright issues. We stand behind our innovation, and our customers.

The Wikipedia article on NetApp talks about them bringing a suit against Sun/ZFS and that Sun countersued, but doesn't mention the verdict.

Read all about it (the story so far, as presented by Sun/Oracle): http://www.sun.com/lawsuit/zfs, which provides links to a number of legal documents and patents and rulings from the PTO.
Basically, the patent which was central to NetApp's claim of infringement was found not to apply to ZFS. A second patent asserted to be infringed was rejected on reexamination by the PTO, but NetApp is still squirming through the appeals process. The current round of threats could be NetApp's last gasp/whimper on the topic.

Netapp is losing, but it's not quite over: http://www.sun.com/lawsuit/zfs/

It's still ongoing, naturally: Sun/Oracle has a page with updates on the case over the last few years.

And what if you want to stop China, Russia or Google from "spying on your stuff"?

http://www.openbsd.org/
http://www.sun.com/software/solaris/trustedsolaris/index.xml

As a whole the generics is a useless and dangerous disaster

You keep repeating that. Citation needed.

Since this is the first time I have ever commented on this topic it seems unlikely that I "keep repeating it". And I gave two examples in my comment. But also see Ken Arnold's opinion: http://weblogs.java.net/blog/arnold/archive/2005/06/generics_consid_1.html and http://www.artima.com/weblogs/viewpost.jsp?thread=222021 and Joshua Bloch's attempts at favorable treatment are pretty damning: http://java.sun.com/developer/technicalArticles/Interviews/bloch_effective_08_qa.html.

Java generics seems to require at least a graduate level course in type theory to use (possibly an actual degree in the field)

So? Is this a bad thing? It's like saying "expert field" seems to require at least "expert field" graduate level course. If you are no expert, then don't use java generics. And if you can't read other's code, then maybe we should hire someone who can.

Indeed it is a bad thing. A problem that all excessively obscure and complex languages have rapidly revealed (C++, Perl) is that every difficult-to-use feature gets used (if it is usable at all) and has to be supported by every other programmer eventually since 90% of all programming is support of existing code.

The saving grace for Java generics is that beyond container typing it seems sufficiently hard to use that it rarely gets used. Some time back I scanned the source of several substantial and active open source projects without finding any examples in use beyond container typing.

I remember using java generics to build a visual keyboard for any kind of text component. I'm reading my code now, and yes, I understand it.

Beyond container typing what aspects did you actually use? Have you ever written one genuine generic algorithm? That is - an algorithm with a generic interface that takes any appropriate generic type and returns an appropriate result type while maintaining typing throughout?

we still ran into the FS path problems

Yes, well, when trying to use some platform or technology, it helps to RTFM.

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.

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

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.

• Complaint 1997 Java case.
• Sun's complete filings in 1997 case
• Sun v. MS Case History page
• Sun's press releases on the case
• Sun v. MS Settlement agreement
• Sun Summary - 2002 antitrust case
• US District Court for the District of Maryland, Baltimore, ruling granting Sun's motions [PDF], Dec. 23, 2002
• Court Order re the Injunctions, January 21, 2003 [PDF]
• District Court Rules MS Must Carry Sun's Java

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.

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.

• Complaint 1997 Java case.
• Sun's complete filings in 1997 case
• Sun v. MS Case History page
• Sun's press releases on the case
• Sun v. MS Settlement agreement
• Sun Summary - 2002 antitrust case
• US District Court for the District of Maryland, Baltimore, ruling granting Sun's motions [PDF], Dec. 23, 2002
• Court Order re the Injunctions, January 21, 2003 [PDF]
• District Court Rules MS Must Carry Sun's Java

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.

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.

• Complaint 1997 Java case.
• Sun's complete filings in 1997 case
• Sun v. MS Case History page
• Sun's press releases on the case
• Sun v. MS Settlement agreement
• Sun Summary - 2002 antitrust case
• US District Court for the District of Maryland, Baltimore, ruling granting Sun's motions [PDF], Dec. 23, 2002
• Court Order re the Injunctions, January 21, 2003 [PDF]
• District Court Rules MS Must Carry Sun's Java

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.

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.

• Complaint 1997 Java case.
• Sun's complete filings in 1997 case
• Sun v. MS Case History page
• Sun's press releases on the case
• Sun v. MS Settlement agreement
• Sun Summary - 2002 antitrust case
• US District Court for the District of Maryland, Baltimore, ruling granting Sun's motions [PDF], Dec. 23, 2002
• Court Order re the Injunctions, January 21, 2003 [PDF]
• District Court Rules MS Must Carry Sun's Java

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.

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.

• Complaint 1997 Java case.
• Sun's complete filings in 1997 case
• Sun v. MS Case History page
• Sun's press releases on the case
• Sun v. MS Settlement agreement
• Sun Summary - 2002 antitrust case
• US District Court for the District of Maryland, Baltimore, ruling granting Sun's motions [PDF], Dec. 23, 2002
• Court Order re the Injunctions, January 21, 2003 [PDF]
• District Court Rules MS Must Carry Sun's Java

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.

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.

• Complaint 1997 Java case.
• Sun's complete filings in 1997 case
• Sun v. MS Case History page
• Sun's press releases on the case
• Sun v. MS Settlement agreement
• Sun Summary - 2002 antitrust case
• US District Court for the District of Maryland, Baltimore, ruling granting Sun's motions [PDF], Dec. 23, 2002
• Court Order re the Injunctions, January 21, 2003 [PDF]
• District Court Rules MS Must Carry Sun's Java

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.

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.

• Complaint 1997 Java case.
• Sun's complete filings in 1997 case
• Sun v. MS Case History page
• Sun's press releases on the case
• Sun v. MS Settlement agreement
• Sun Summary - 2002 antitrust case
• US District Court for the District of Maryland, Baltimore, ruling granting Sun's motions [PDF], Dec. 23, 2002
• Court Order re the Injunctions, January 21, 2003 [PDF]
• District Court Rules MS Must Carry Sun's Java

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.

Imagine for example a protocol where programmed objects can exist on different servers

Java Remote Method Invocation (RMI) ?
here: http://en.wikipedia.org/wiki/Java_Remote_Method_Invocation
and here: http://java.sun.com/javase/technologies/core/basic/rmi/index.jsp

You'd think that preventing SQL injection attacks was difficult. Basically don't allow multiple queries per request on your db and filter out semi-colons (or replace them with "") from post/get vars.

This doesn't solve the problem (of generating query strings with data inline); it just prevents anything bad from happening. The correct solution is via prepared or parameterized statements, which do not rely on string replacements.

Oooooooo that's shaaaaakey.

In any case the indemnification offered by Sun was always the weakest sort, here's a post from the CEO regarding the NetApp/ZFS debacle:

http://blogs.sun.com/jonathan/entry/harvesting_from_a_troll

Basically (from thew point of view of Sun) it was always: you use this Sun stuff, we have a bunch of patents on our IP. If we get sued we take away the those guys rights to use our patents, we may sue them. If you get sued for using our IP by those guys, let us know. If you have any patents of your own, use them against that guy, then we'll take away their rights to use our patents, also we may sue them. There was nothing there like Sun would pay money to you or to cover court costs, or provide council, etc.

In any case there is no more Sun, in small part due to that NetApp suit, and what has Oracle said about indemnification?

They make it available a the bottom of this page. And the framesets work just fine without needing a web server - just open up docs/api/index.html wherever you untarred the files.

It only makes sense, since they have the source for the documentation.

I honestly can't think of a time where a frame has made anything on the web easier save for Kingdom of Loathing.

Then you're an idiot. How are you going to implement a sidebar menu with dozens of links (Table of Contents) that doesn't reload the whole page (causing you to lose the position within the Table of Contents widnow) if you can't use JavaScript (hello, NoScript clowns, I'm talking about you)?

Implement this without frames and without losing the above advantages:
http://java.sun.com/javase/7/docs/api/

A great example of how frames do their job better than anything that has come along since. Best part is you can download it all to your local computer. So before anyone says "they could put it in a wiki", yes they could, but then the user has to be connected to the net.