Java's Backup Plan If Oracle Fumbles
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."
... when being owned by Oracle?
It is the universe that makes fun of us all.
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.
Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.
"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.
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.
Scala is multiparadigmal; you can use the functional features when you want, and ignore them and program Java-style when you want.
"Oppression and harassment is a small price to pay to live in the land of the free." -- Montgomery Burns.
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.