Slashdot Mirror

Sure you can.

http://hg.openjdk.java.net/

There’s Oracle’s source repo for OpenJDK.

I'm going to assume you're just a troll, but in case you're not or more so because someone else doesn't realize it: http://openjdk.java.net/

This is not news, unless we've all turned our clocks back to 2016 See: https://dzone.com/articles/a-f... and http://openjdk.java.net/jeps/2...

I am a professional programmer but I don't work with java, so I was confused about what, exactly, "modularity" means in this context. I clicked through a few links and found the info and figured I'd share here for anyone else in my position.

Java, as it stands, has no real mechanism for managing program dependencies (think, dynamic link libraries). Either a JAR file embeds all of the classes it uses or it loads external classes using something called the "class path system", where there is a programmatically accessible path where java code can look for class files to link in at runtime. This system is very simple, and lacks built-in versioning or encapsulation features. It's up to developers to build in their own versioning into the file structure. As you could guess, it's generally very brittle.

The new system replaces that with a concept of "modules". These are collections of classes with strong names, cryptographic signatures, version numbers, and members that are either public and advertised to code the imports the module, or private and for internal module use only. This is a huge step up from the idea of just going and loading class files out of some path. I'm actually astonished Java made it this far without such a feature!

You can find more info about the new module system here: http://openjdk.java.net/projec...

Java has had modularity for over a decade, but it just wasn't part of the language itself. It was called OSGi. Jigsaw is effectively a cut down version of OSGi.

I am a professional programmer but I don't work with java, so I was confused about what, exactly, "modularity" means in this context. I clicked through a few links and found the info and figured I'd share here for anyone else in my position.

Java, as it stands, has no real mechanism for managing program dependencies (think, dynamic link libraries). Either a JAR file embeds all of the classes it uses or it loads external classes using something called the "class path system", where there is a programmatically accessible path where java code can look for class files to link in at runtime. This system is very simple, and lacks built-in versioning or encapsulation features. It's up to developers to build in their own versioning into the file structure. As you could guess, it's generally very brittle.

The new system replaces that with a concept of "modules". These are collections of classes with strong names, cryptographic signatures, version numbers, and members that are either public and advertised to code the imports the module, or private and for internal module use only. This is a huge step up from the idea of just going and loading class files out of some path. I'm actually astonished Java made it this far without such a feature!

You can find more info about the new module system here: http://openjdk.java.net/projec...

IBM and Red Hat are correct:

The project seems to have slipped backwards, as this slide from 2014 indicates the implementation of version requirements.

Whereas the 2016 documentation stipulates:

"A module's declaration does not include a version string, nor constraints upon the version strings of the modules upon which it depends. This is intentional: It is not a goal of the module system to solve the version-selection problem, which is best left to build tools and container applications."

The State of the Module System

Anything less than Node's package requirements is going to be useless. There should be absolutely no wildcards in major version numbers, with warnings in medium. They are the curse of Node!

And yet as of Java 8, nothing in the JVM is written in Java. It's all c/c++. Almost 250,000 lines.

OpenJDK JEP 290 will add a serialization whitelisting/filtering facility at the Java runtime level to help applications combat this type of vulnerability.

From an academic standpoint, and that means writing a test in an university: you are wrong. Plain and simple.

So, lets look at a C-function like printf(). That is (part of) an API (called the standard C library). It has no protocol associated at all.

Now lets look at the hand shake between an mail transfer agent like sendmail (S) and an mail user agent like Mail.app (C):

S: 220 smtp.example.com ESMTP Postfix
C: HELO relay.example.org
S: 250 Hello relay.example.org, I am glad to meet you
C: MAIL FROM: bob@example.org
S: 250 Ok
C: RCPT TO: alice@example.com
S: 250 Ok
C: RCPT TO: theboss@example.com
S: 250 Ok
C: DATA
S: 354 End data with CR LF.CR LF
C: From: "Bob Example" bob@example.org
C: To: "Alice Example" alice@example.com
C: Cc: theboss@example.com
C: Date: Tue, 15 January 2008 16:02:43 -0500
C: Subject: Test message
C:
C: Hello Alice.
C: This is a test message with 5 header fields and 4 lines in the message body.
C: Your friend,
C: Bob
C: .
S: 250 Ok: queued as 12345
C: QUIT
S: 221 Bye
{The server closes the connection}

Copied from: https://en.wikipedia.org/wiki/...

As you see: this is clearly a protocol. And it has no API associated. See here: https://java.net/projects/java... for an API that supports the protocol above. And again that API 'is not the protocol'.

Sorry, you either have no clue about computer science or you missed some basics. Protocols and APIs have a lose association (as both can exist without the other) just as grammars and programs have a lose association.

And thanks for insulting me in your other answers.

1. To see the date of http://hg.openjdk.java.net/jdk...
2. hg clone http://hg.openjdk.java.net/jdk...
3. cd *jdk7u* && sh get_source.sh

It requires installed Ant ALSA CUPS and FreeType.

4. It can be auto-compiled using the defunct JDK 7 or the alive OpenJDK7, it does not require JDK 6 for bootrapping, and should be specified ALT_BOOTDIR=path to the jdk.

1. To see the date of http://hg.openjdk.java.net/jdk...
2. hg clone http://hg.openjdk.java.net/jdk...
3. cd *jdk7u* && sh get_source.sh

It requires installed Ant ALSA CUPS and FreeType.

4. It can be auto-compiled using the defunct JDK 7 or the alive OpenJDK7, it does not require JDK 6 for bootrapping, and should be specified ALT_BOOTDIR=path to the jdk.

There was no "value proposition" for Java, Sun eventually made it open source with new APIs and language features created through a community development process, in order to compete against Microsoft and others. That's why IBM, the biggest corporate cheerleader for Java, refused to increase its $8 billion acquisition offer for all of Sun Microsystems including their server and storage businesses, as well as Solaris, Java, and MySQL.

But Larry was/is intent on pulling a Darl Mcbride and figuring out how he can take Java closed so Oracle can charge users serious dough. He can't, that genii flew.

Standard disclaimers apply: I am not a lawyer and this should not be construed as legal advice.

First, you don't steal titles from an existing work. Stealing has a very specific legal definition and in the context of law commentary, it's very important that you don't fuck it up.

Second, yes, using the same titles is, in fact, okay.

Third, that specific licenses allow you to use interfaces or not explicitly is irrelevant. Copyright enforces the wishes of the copyrighter in how distribution works. Unless you have some evidence that the Java platform is licensed in this way, this point is completely irrelevant. And it seems to me that you might be hoisted upon your own petard.

Fourth, what does it take to be a standard in your mind? What is your opinion on the Java platform documentation? Because it seems pretty well-specified to me. Java also has a language and VM spec that are published specifications. How do "oversight organization" and "corporate entity" automatically differ?

Your way of posting implies you don't know what an API is.

E.g. calling a middle ware an API is nonsense. And there is certainly no "Java API" for that.

To implement middle ware we in our times use: SOAP, REST, various message queues, CORBA and RMI, and probably custom made ones.

So: YES, if you want to call that an API (the correct term is: "a standard") then there is for most of them only one API, in other words: the CORBA binding for SUNs/Oracles Java and IBMs Java and HPs Java: are identical! That is the point of having such an API.

Are you also implying that there is no creativity and design involved in designing an API?

How do you come to that conclusion? I did not say that. Nor did I imply that.

When I ask 12 (competent) developers as you proclaimed to define an API for reading/sending/processing eMails like this: https://javamail.java.net/nona...
then I expect them to get at max three variations of such an API which should look very similar.

After all there is no sane reason to craft an API that diverges much from suns original work.

You might disagree, but you would be wrong.

Same for any other API. If you find it complicated to design APIs then perhaps restrain yourself from it.

Just because there are multiple ways to implement an API ...
Implementation is not defining an API!!!
... does not mean there is only one API for a given area of computing. Of course not, but there is one mainstream and a few rarely used ones, like SAX versus Schema based or RelaxNG based XML parsing/processing. In Java you have on API and multiple implementations.
Same for JDBC, JDBC is the API and various database vendors implement that API, but there is no "other version of JDBC than original JDBC because it is for funk sake not needed!!

But Java was the important thing we couldn't let die. And it isn't open source so the community couldn't steal it away from oracle.

Java is fully open-sourced and the most open-sourced programming language I know. OpenJDK is the same source code Oracle uses for its JDK. It's easy to download and compile all Java executables. Here is a guide and a Youtube video detailing how to build the JDK.

Java is defined and updated by the JSR process, which resembles RFCs. And also by the JEP process which tells you exactly what's being built into Java and when. You can also use their bugtrackers and mailing lists to track Oracle engineers' work.

I've learnt a ton just by tracking those lists.

But Java was the important thing we couldn't let die. And it isn't open source so the community couldn't steal it away from oracle.

Java is fully open-sourced and the most open-sourced programming language I know. OpenJDK is the same source code Oracle uses for its JDK. It's easy to download and compile all Java executables. Here is a guide and a Youtube video detailing how to build the JDK.

Java is defined and updated by the JSR process, which resembles RFCs. And also by the JEP process which tells you exactly what's being built into Java and when. You can also use their bugtrackers and mailing lists to track Oracle engineers' work.

I've learnt a ton just by tracking those lists.

I could go into a dozen technical reasons why javascript is a terrible, horrible, outrageously bad language

So is Java. It's unfair to call JavaScript's problems "product killing" ... unless you mean Java's are as well?

I juggle two day jobs, both for responsive, background-processing-heavy websites. One's in Node and one's in Scala (Java on steroids). To me, the Node way Makes More Sense.

Yes, Java can process in multiple threads at once; but then you need to worry about atomicity. Yes, Java it can delegate different jobs to different threads; but then you need to read up on ExecutorServices. Yes, Java is faster; but if you want async file reads, things get complicated pretty quickly. (If you're going to block your thread, you'd better adjust your thread pool....) Yes, Java is type-safe and compiled; but that hinders as often as it helps.

These are two different cultures. Java culture seems to whirl around huge infrastructures -- J2EE, JDBC, Swing, Ant, etc -- that have gargantuan learning curves and ten-year-old flaws. (One that bit me: Java 7's UTF-8 decoder accepts invalid UTF-8 to maintain compatibility with Java 5 -- that is, a ten-year-old version of the standard.)

In contrast, Node culture is about self-organizing chaos. You can deliver results really quickly, but you might need to rewrite your code in a few months to keep up with library changes. And your favourite dependency might not be there tomorrow.

Java and JavaScript (and any other language, really) can kill your product in different ways. Pick your poison.

What gets me about java is that they add fancy new stuff like lambdas while leaving out basics like properties, operator overloading and user defined value types.

Regarding properties and operator overloading, the language designers' stated concern that these features are frequently misused and often lead to difficult-to-read code means they are not likely to ever be implemented. I think I agree with them: I'd rather see myObject.setProperty(value) than myObject.property = value (for example) because in the latter I cannot easily be sure whether "property" is actually a property or instead has been made a field. Similar arguments apply to operator overloading.

Value types are apparently high on the priority list, which means we are likely to see them in Java 9.

... checking on openjdk.net only gives me a preview version with a rather restrictive "you may look at it, just don't try anything with it" license.

Maybe you should go back to the site more than once every five months? OpenJDK 8 has been General Availability since March.

Download and install the open-source JDK 7 for most popular Linux distributions. If you came here looking for Oracle JDK 7 product binaries for Solaris, Linux, Mac OS X or Windows, which are based largely on the same code, you can download them from java.oracle.com.

Oracle has a strangle-hold on the language, even on the front of OpenJDK's website it tells you to download binaries from Oracle.

I don't know if this is the same concept as the new Streams API in Java 1.8, but if you are a Java guy, I think they are *really* cool: http://download.java.net/jdk8/docs/api/java/util/stream/Stream.html

For those interested, the license seems to be GPL+Classpath Exception:

http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/LICENSE

Functional Interfaces; The article was light on details, but it seems to address the use cases that extension methods in C# addresses.

The article actually named this incorrectly. A "functional interface" in Java 8 is an interface with a single method - basically, J8 equivalent of a delegate type in C#.

The default thingy is called a "default method", and there's no special term for interfaces having them. In effect, these make Java interfaces closer to traits (i.e. allow multiple inheritance of behavior).

Streams: Similar to IEnumerable and parts of LINQ (LINQ to Objects).

The big catch here is that they're still using interfaces with the same old Java generic model based on type-erasure. This, in turn, means that generic functions applied to a stream of primitives do a lot of boxing. To avoid that, they provide special-cased implementations for int, double etc, which have the same exact implementation for a specific primitive types. If you look closely at the samples in the article, you'll see that they call a function named mapToDouble. Note how C# doesn't need anything like that, since its generic Select<TSource, TResult> mapping method can handle primitives just as efficiently as any reference type.

Also have a look at javadocs for the standard functional interfaces in Java 8. Note how many they needed just to cover int, long and double (and this still doesn't cover combinations like int+double).

New Java Date Time API for Java8: http://openjdk.java.net/jeps/150
AKA JSR 310

One new thing for JavaFX http://openjdk.java.net/projects/jdk8/features#153
It's pretty minor.

If you subscribe to JBoss from Red Hat for your enterprise Java needs, you will get very good support - for a lot less than Oracle is likely to charge. see: http://www.jboss.org/

There is a very active community for supporting OpenJdk, which is the code base for Oracle's Java offering. see: http://openjdk.java.net/

I think you're jumping on the Node.js bandwagon without understanding why.

Node.js is a good asynchronous server, like Tornado (written in Python). However, it sounds like you are writing a backend for a RESTful (mobile) web application. Web is rarely asynchronous and has no special benefits from using an asynchronous server. You will not be more scalable just because you choose Node.js as your platform.

However, if you're excited about JavaScript on the server -- wonderful, because you get to use the same language throughout your project -- then consider the following products that are based on the JVM:

Prudence (cool because it has a framework for MongoDB, which is also JavaScript-based, and also because it uses Restlet, a truly awesome JVM library)

Helma (very mature and proved its worth)

JSSP

Myna

Phobos

It's not the programmers that matter. Programmers can write Java and compile it with any JDK they please, and it should run on any JRE, including OpenJDK and its companion JRE project. I don't know how well they patch compared to Oracle, but it's an open-source replacement, which works pretty well in my experience.

The Oracle HPC paper put the overhead at 1-1.5 (i.e. Java at 40-50% of the gcc Fortran version). They used Fortran as a benchmark for Java. There were no areas of outperformance and that was with a rather mediocre Fortran compiler. Your own paper doesn't support your theory. Choose a benchmark favorable to Java and in many areas it does well.

I believe the debate was whether Java was faster than C++. In some areas Java is faster than C++. Nothing is faster than FORTRAN (which is the reason it is still used for time critical applications). This is due to FORTRAN's lack of things like pointer-aliasing that prevent some optimizations in C++. The paper supports my point :) ... and the JVM has only gotten faster in the last five years.

I'm not arguing development time isn't important. I'm arguing what the word "fast language" is not about development time. Cars are important, refrigerators are important. The fact that a fridge is important does not make it a car.

Sorry man, I don't grok the intent of the last sentence. Could you please clarify?

you get development speed faster than C++ without taking order of magnitude performance hits and pick up mostly cross platform; I'd agree with you.

That was my point. So, happily, we agree. For enterprise work the speed to develop is usually more important than the runtime performance (although that can't suck too much).

The things that make Java safer than C/C++ for commercial development are the things that knock it out of the game for systems programming.

Not really. The reason Java is not used for systems programming is that there are good enough languages already in systems programming and an enormous legacy codebase that you would need to integrate with. In theory you could write an operating system in Java (with a sprinkling of C/assembler for register access; just as the Linux kernel has a sprinkling of ASM, IIRC). The reason Java is not used is not because of performance, it is because replacing the millions of lines of C just to change development language is not sufficient.

Just to pick a simple example where Java is a problem... C++ is far better at dealing casually with data structures at the bit level where the packing / unpacking needs to happen fast. I wouldn't want to try and write a router in Java.

I've done lots of device control in Java where I had to do bit-level packing and unpacking (eg. controlling traffic speed radars, shift-register based LED signs, NTCIP signs, control the timing registers and readout of astronomically priced astronomical CCD cameras, control GPS clocks, etc). Java was perfectly fine and perfectly performant at this. You can't write any old Java and have it perform well. You do have to use the profiler to check you are not slowing anything down (fortunately the awesome JVisualVM comes free with the JDK, or can be downloaded separately from http://visualvm.java.net/).

With the exception of pretty good cross platform, Java is a compromise. There is a lot of advantage in the standard language being pretty good at a lot of things and not fantastic at any of them. But let's not pretend this tradeoffs aren't happening.

All engineering is about compromise. I'm not saying Java is the perfect language in any domain. I'm saying that it is a good-enough language for any domain that makes it sensible as a first 'go to' choice. IMHO you should won't go wrong if in your solution architecture you select Java as your choice of development language and only then consider other languages if Java is inadequate. The benefits of re-use of your existing Java code, and re-use of the huge number of libraries (for just about any problem domain) outweigh (IMHO) many of the alternatives. In my work I have never encountered a performance problem with Java

Well, I went looking at this and it's not the JRE that does this, it's the Oracle installer for Java. JRE is not the installer, it's the run time environment.

Here is one of these stories about this issue.

But yes, on Linux or Unix I don't get any of this nonsense, it's just a tarball that I untar into a directory, set the path and run the JVM for example. The binary installers for Linux or Unix are simple shell scripts with the same tarball basically as part of the script, it doesn't do any of this stuff.

As I said, this is a terrible marketing move, does huge amount of disservice to the entire concept of Java by bundling things with installers that clearly shouldn't be there. It's not enough that people are confused about what Java is or is not (because of such a huge number of things that people just call 'Java'), but adding this nonsense to installers is just evil. Personally I have various issues with Oracle, would have really preferred if IBM bought Sun's assets rather than Oracle.

Pass. Who uses a full PC to make calls?

Their FAQ says that and Android client is in the works and will be demoed very soon. As for Apple they claim that Apple's restrictions shuts them out of iOS - but if you have Apple you already have access to FaceTime for all your Apple devices, not that FT can do multi person calls though.

That real-soon-now claim was made for the FOSDEM 2013 conference which occurred over a month ago. There was no jitsi android client at FOSDEM 2013. For what its worth, they've made several real-soon-now claims about an android client for the past couple of years. While there *is* a jitsi android client, it still lacks a committed user interface, so it definitely is still just a work in progress -- I suspect the devs are waiting for android's platform fragmentation problem to go away. :)

There are many applications and utilities written in Java that are quite far from useless, and which are not web-based applications. The website Java.net alone has an enormous number of open source ones. I've personally played around with Klooge Werks, a virtual gaming table for RPG's, which is written entirely in Java. Minecraft was originally developed in Java. A large percentage of IBM's Watson is written in Java.. And of course, Eclipse is mostly written in Java, which is the most widely used development environment for Android

"Apple hasn't issued any official statements advising users of the change or its reasons, but it's a safe bet that the company has deemed Oracle's most recent update to Java insecure"

Does this apply to the OpenJDK Runtime Environment

http://openjdk.java.net/

I don't feel it is trustworthy to leave a VM running all the time

It's really not a general-purpose VM like Linux, Windows, or $YOUR_OS_HERE on VMware, VirtualBox, Xen, or $YOUR_HYPERVISOR_HERE. It doesn't run an OS, just the one Java program it's given. One JVM instance only runs one program. Hell, the JVM works without any sort of kernel-level support, whereas everything moderately efficient requires kernel-level drivers to work properly. (Vanilla QEMU has no kernel-level drivers, but was so slow that KQEMU was developed, and QEMU was later tied with KVM to make it more efficient.)

Of course, that's not even getting into the fact that it's a very common practice to leave VMs running all the time, especially in datacenters. Many people leave Amazon EC2 instances running, I'd imagine almost everyone with a VPS keeps it running constantly, etc. This still has nothing to do with the JVM, because they are completely different concepts, though.

Also, would you be okay with running Java programs compiled to native code with something like GCJ? It doesn't use the satanic JVM, but that won't really change too much (except possibly give you better performance, depends on how well GCJ optimizes and how well HotSpot optimizes).

I have actually seen java applications access areas they aren't supposed to have access to.

As measured by? Hell, define "area." Are you talking across the network, or locally? If you're across the network, how do you know it was Java and not something else on that box? In either case, how do you know it wasn't malware that slipped in somewhere? This sounds like unsubstantiated paranoia.

That the VM doesn't provide me with good tools to see what really is running inside it...

VisualVM.

...and kill naghty processes

Again, I'm pretty sure you're confused about how the JVM works. Each Java program running has a separate instance of the JVM (java or java.exe). If you can't find and kill the process that's out of control, you are doing something horribly, horribly wrong. To summarize, if you don't like Java, fine. (I know I'm not a huge fan of Java on the desktop, and certainly not in browsers...) But you seem to have deeply flawed views on how everything works.

Java has a very small memory footprint by default.

Erm. No. Just no.

class Main { public static void main(String[] args) { while (true); } }

(jdk 1.7.0.6 x86_64 linux)

17M resident for that. 0.5G of virtual address space. The only other class referenced is java.lang.String.

The equivalent Perl is 1.7M. Node.js is 9M. Python is 4M. TCL is 1.9M.

EVERYTHING uses less RAM than bleeping Java. A lot less. And this isn't some fail test where Java gets better as applications scale. Go look over here and observe how almost every other language consumes less memory across a wide variety of algorithms. Anecdotal evidence from any app server admin will corroborate this.

Java is a RAM pig and it always has been. The problem, at least regarding initial memory footprint (and start-up time), is excessive class loading. This is not opinion. There has been a project to correct it on the books for almost four years.

Like everything else with Java, it has been neglected. Supposedly the results will appear in JDK 9..... sometime in 2015.

And don't cite Android as some exception. Dalvik isn't JRE.

As the actual proposal notes, while Project Nashorn has been in the works within Oracle for some time, what they're doing now is proposing to make it part of OpenJDK, to get more people working on it so that the code can be tightened up for production use.

We built Java to be an open source computing platform freely available to anyone wishing to use it. In 2006, Java was released under the GPL open source license and we continue to develop and innovate the platform under the same open source license -- it is available to everyone at: http://java.net./ This openness allows device manufacturers to customize Java and enable new user experiences, driving innovation and consumer choice.

As the lead developer and shepherd of the open platform, we realize that we have a responsibility to app developers -- those who invested in the platform by adopting it and building applications specifically for Java. These developers each contribute to making the platform better -- because when developers support a platform with their applications, the platform becomes better and more attractive to consumers. As more developers build great apps for Java, more consumers are likely to buy Java devices because of the availability of great software content. As more delighted consumers adopt Java phones and tablets, it creates a larger audience for app developers to sell more apps. The result is a strategy that is good for developers (they sell more apps), good for device manufacturers (they sell more devices) and good for consumers (they get more features and innovation).

In biological terms, this is sometimes referred to as an ecosystem. In economic terms, this is known as a virtuous cycle -- a set of events that reinforces itself through a feedback loop. Each iteration of the cycle positively reinforces the previous one. These cycles will continue in the direction of their momentum until an external factor intervenes and breaks the cycle.

When we first contemplated Java and formed the Java Community Process, we wanted to create an open virtuous cycle where all members of the ecosystem would benefit. We thought hard about what types of external factors could intervene to weaken the ecosystem as a whole. One important external factor we knew could do this was incompatibilities between implementations of Java. Let me explain:

Imagine a hypothetical situation where the platform on each phone sold was just a little bit different. Different enough where Opera Mini would run normally on one phone but run terribly slow on another. Let's say, for sake of example, that Java implemented an API that put the phone to sleep for a fraction of a second to conserve battery life when nothing was moving on the screen. The API prototype for such a function might look like SystemClock.sleep(millis) where the parameter "millis" is the number of milliseconds to put the device to sleep for.

If one phone manufacturer implemented SystemClock.sleep() incorrectly, and interpreted the parameter as Seconds instead of Milliseconds, the phone would be put to sleep a thousand times longer than intended! This manufacturerâ(TM)s phone would have a terrible time running Opera Mini. If apps donâ(TM)t run well across devices due to incompatibilities, consumers would leave the ecosystem, followed by developers. The end of the virtuous cycle.

We have never believed in a âoeone size fits allâ strategy, so we found a way to enable differentiation for device manufactures while protecting developers and consumers from incompatibilities by offering a free "Technology Compatibility Kit" (TCK). TCK is a set of software tools that tests and exercises the platform to make sure that (for example) SystemClock.sleep(millis) actually puts the device to sleep for only milliseconds. Like Java, the test suite is freely available to everyone under the OpenJDK Community TCK license: http://www.jcp.org/en/resources/tdk/

While Java remains free for anyone to use as they would like, only Java compatible devices benefit from the full Java ecosystem. By joining the Java Community Process, each member contributes to and builds one Java platform -- not a bunch of incompatible versions. Weâ(TM)re grateful to t

Apparently it's a security regression in the JDK, was analyzed and then patched in IcedTea yesterday

Whatever happened to them? Didn't they at one time have a Java implementation?

IBM's Java work is now part of OpenJDK. How close OpenJDK is to Oracle Java and whether it shares this exploit I don't know (although the OpenJDK home page says they are '...based largely on the same code'), but if it does it should be patchable.

I'm not ready to give up on Java. It is not because I think it's the best, I still think C# beats it as a language, but at times when a client requires non-microsoft, it is my only choice for a modern language. Yeah, I know C++11, I've looked at it quite a bit, and it is better than it was, but as long as it needs header files, I don't put it into a modern language category.

I could happily give up Java, but I wouldn't willingly give up Clojure. There's more (and better) languages for the JVM than just Java.

How is Java not integrating well with Linux? Java is free like in libre, the reference implementation is under the GPLv2: OpenJDK.
Oracle is now shipping JavaFX with OpenJDK: http://openjdk.java.net/projects/openjfx/

Okay, so TimSort.rangeCheck() was allegedly copied from java.util.Arrays.

Aside from the obviousness issues, this fact would make it slightly more sensible to use rangeCheck() for a copyright infringement case, except for the fact that java.util.Arrays was provided by Sun under the GPL v2. The GPL was written to encourage copying and modification.

The worst I could say about Google allegedly copying this code is that they re-licensed the GPL rangeCheck() method to Apache 2.0, which you can't really do; the combination of GPL code and non-GPL code would be a GPL end product. Regardless, I still don't see a billion dollar damage claim.

Wow, you're right, that's completely insane. Look at the revision history of TimSort.

How can Oracle claim copyright damages on a file in Java's source code that is Copyrighted in 2009 by Google?
Why hasn't Google tried to nullify the copyright claim on this file on the grounds they they wrote the code and that they themselves own the copyright?
Why would Oracle make an issue of this file if the case for infringement is so weak?

None of this makes any sense to me whatsoever. I feel like I'm missing something; Oracle can't be this outrageous and Google's lawyers can't be this dumb. Can someone clarify?

Except the TCK prevents "Java" platforms from dropping the deprecated cruft, and making a fast booting, lean and mean web targeted bytecode compliable VM.

Yes and the end result is Dalvik.
Oracle, through their lawsuit, are determined to retrofit a resurrected Java ME, with corresponding commercial licensing upon future Android handsets, while preventing application of the Java SE through a 'field of use' clause against embedded uses.
The engineering (lawyerless) part of Sun-Oracle is in the process of splitting up the 'cruft' into Modules. Hence APIs that aren't required on a handset such as AWT/Swing don't get loaded.
Had this modularization occurred 5 years ago, Google could have happily licensed the GPL parts of Java SE for Android.
Instead, Oracle continues to seek revenues by foisting the carcass of J2ME on an unwilling market.

OpenJDK is Free Software, under the GPLv2 with Classpath Exception - sez so here: http://openjdk.java.net/legal/gplv2+ce.html

"CLASSPATH" EXCEPTION TO THE GPL

Certain source files distributed by Oracle America and/or its affiliates are subject to the following clarification and special exception to the GPL, but only where Oracle has expressly included in the particular source file's header the words "Oracle designates this particular file as subject to the "Classpath" exception as provided by Oracle in the LICENSE file that accompanied this code."
Linking this library statically or dynamically with other modules is making a combined work based on this library. Thus, the terms and conditions of the GNU General Public License cover the whole combination.
As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module. An independent module is a module which is not derived from or based on this library. If you modify this library, you may extend this exception to your version of the library, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version.

While the source for those libraries was eventually released by Sun, it's not clear to me what license applies to the library source, and it's definitely not clear that the source was released before Google's work on Android. The issue may be water under the bridge as Sun did open source the vast majority of Java, but it kind of flies in the face of "clean room" claims.

How is it not clear? Download OpenJDK from the OpenJDK site and read the License file.

Here's a spoiler: It's mainly GPLv2, although there are apparently still some binary blobs out there with proprietary licenses, plus some parts have the Classpath exception.

However, it's a moot point as Google uses Apache Harmony's class library, not OpenJDK, meaning that this license wouldn't apply.

Likewise, Google claiming they made a cleanroom implementation is moot, as it'd be Apache Harmony's people who would need to claim that.

"new" may or may not throw exceptions

Stock "new" always throws std::bad_alloc when it fails, unless used as new(std::nothrow), or you overload it. Many compilers allow changing its behavior to return null instead, but this is not permitted by C++98, so when you use a compiler in such mode, you're not dealing with standard ISO C++.

What C++ needs (and perhaps this is in C++0x) is a better definition for exceptions, one that does not cause programs to abort (which is even worse than checking return values)

Pretty much every other language aborts the program if it's unhandled. The general rule is that, if something unprecedented happens in your code that you did not expect, which strongly indicates that your data is in an unknown and a potentially invalid state - like, say, an exception you didn't expect and therefore didn't handle - the best thing to do in most cases is to fail fast and hard, so that it is very clear that things went wrong, and also the precise point at which they did.

If you are rather complaining about exceptions leaking from destructors crashing everything, that is also not really a C++ specific problem, it's just that other languages make different (but also bad) choices. Throwing in destructor in C++ is, effectively, equivalent to throwing in a finally-block in Java while stack unwind due to another exception is already in progress. If you don't fail fast as C++ does, you have to discard one of the exceptions entirely, and only bubble up another - which is what Java does. This is also pretty obviously bad, since by the time you catch whatever came out from the finally-block, you've lost the original exception. Hence why good practice in Java is similar to the one in C++ - if an exception can be thrown in finally, catch it right there.

It already is the reference implementation

I use Java as my language of choice (because I know it and there are tons of libraries available.)

For web sites that are use by people, I use Apache Tapestry 5 as the web framework. It's very easy to use, integrates with Hibernate, is very fast and makes me very productive. I find that I can write nice looking pages that work well in a very short amount of time. I end up writing very little actual code, so maintenance is easy. Live class reloading is a major plus, I just edit my page or Java class, hit save and the changes are ready to be used in my browser.

However, there are many other Java web frameworks to chose from based on what you like best. Java is a bit bloated, but it's pretty fast and stable. And there are libraries for almost anything. (I generate PDFs, for example, using iText and everything works very well together.)

I use Eclipse for my IDE, which while it could be faster and less bloated, seems to work pretty well.

If you want to focus entirely on web services (e.g. SOAP or REST), then there are easier solutions for that in the Java world. (I use JAXB annotations with Jersey for REST services.) For SOAP I'd use Apache CXF based on what I've read. You can integrate both of these with Tapestry and Hibernate to create a cohesive web platform.