Apache Foundation to vote down Java 7, protesting Oracle abuses(arstechnica.com)
arstechnica.com
Apache Foundation to vote down Java 7, protesting Oracle abuses
http://arstechnica.com/open-source/news/2010/11/apache-foundation-to-vote-down-java-7-protesting-oracle-abuses.ars?
4 comments
I am trying to comprehend your comment.
It seems like you are calling the Apache Software Foundation "bunch of salesman-type assholes threatening to destroy billions (or more) in value in order to measure the length of their dicks is sickening.".
That kind of statement seems extremely delusional to the facts of how the ASF has interacted with the Java ecosystem for the last decade.
The dispute is about a promise that Sun made -- and signed into with how the JCP was setup -- that a specification for a Java API, and the Testing of that API (TCK), are available open-enough to allow free and open source implementations. The ASF joined the JCP because it believed Sun would live up to this promise.
Oracle supported the ASF position, before it bought Sun, because it wanted an more open Java language. But now that Oracle bought Sun, their position switched, and they are actively working to prevent other implementations of the Language from being created.
This is not about politics and farting, this is about a contract and a promise that Sun made to the community.
It seems like you are calling the Apache Software Foundation "bunch of salesman-type assholes threatening to destroy billions (or more) in value in order to measure the length of their dicks is sickening.".
That kind of statement seems extremely delusional to the facts of how the ASF has interacted with the Java ecosystem for the last decade.
The dispute is about a promise that Sun made -- and signed into with how the JCP was setup -- that a specification for a Java API, and the Testing of that API (TCK), are available open-enough to allow free and open source implementations. The ASF joined the JCP because it believed Sun would live up to this promise.
Oracle supported the ASF position, before it bought Sun, because it wanted an more open Java language. But now that Oracle bought Sun, their position switched, and they are actively working to prevent other implementations of the Language from being created.
This is not about politics and farting, this is about a contract and a promise that Sun made to the community.
A more charitable interpretation of
> It seems like you are calling the Apache Software Foundation "bunch of salesman-type assholes threatening to destroy billions (or more) in value in order to measure the length of their dicks is sickening.".
might be that he's referring to Oracle. It's not very clear though.
> It seems like you are calling the Apache Software Foundation "bunch of salesman-type assholes threatening to destroy billions (or more) in value in order to measure the length of their dicks is sickening.".
might be that he's referring to Oracle. It's not very clear though.
That was my reading.
I was referring to Oracle.
I thought you were :-)
BTW, I am trying to build Harmony from source right now on OS X, just to see if it runs OK...
BTW, I am trying to build Harmony from source right now on OS X, just to see if it runs OK...
The amount of man-centuries of work that would at the very least now have to be ported?
There are large numbers of Very Important Programs that are still written in some old dialect of Fortran. It's not like the Java 6 JVMs are going to disappear from the planet's face; businesses will just keep on using those.
There are large numbers of Very Important Programs that are still written in some old dialect of Fortran. It's not like the Java 6 JVMs are going to disappear from the planet's face; businesses will just keep on using those.
> It provides near-C++ performance too if you tweak your code a bit
You mean, of course, tweaking the C++ side as well... ;-)
I agree that in some cases you may get similar performance, but that usually means you are comparing superbly optimized Java code with horribly inefficient C++ code.
You mean, of course, tweaking the C++ side as well... ;-)
I agree that in some cases you may get similar performance, but that usually means you are comparing superbly optimized Java code with horribly inefficient C++ code.
Actually, I think that most people overestimate performance of C++. Using C++ the way authors intend almost invariably leads to gigantic binaries with large amounts of duplicated and also unnecessary autogenerated code. It is not too hard to believe that reasonable JIT can outperform that.
It is not too difficult to generate small binaries from C++ code; modern C++ toolchains have link-time optimization (http://en.wikipedia.org/wiki/Link-time_optimization) and can optimize for size (-Os). Code size is rarely an issue in the C++ projects I work on (numerical and discrete event simulations).
I don't know about any toolchain that is able to collapse multiple instantiations of same template with different types but otherwise identical code (ie. std::vector<Foo> and std::vector<Bar>) and on many codebases I've found out that these template instantiations are large part of resulting binary size.
While it's probably simple to write programs that results in small binaries it probably involves not using large parts of language. In my opinion it is often more reasonable to use straight C (which also makes performance characteristics of program more obvious in any case).
While it's probably simple to write programs that results in small binaries it probably involves not using large parts of language. In my opinion it is often more reasonable to use straight C (which also makes performance characteristics of program more obvious in any case).
You mean identical source code or identical assembly code?
I would expect that compiler strip away typdef'ing so unless Foo and Bar are really different, only one copy of the code should exist.
Yes, you can probably defeat this heuristic by doing a couple of pathalogical things, but I expect it work unless you're actively trying to defeat the system.
I would expect that compiler strip away typdef'ing so unless Foo and Bar are really different, only one copy of the code should exist.
Yes, you can probably defeat this heuristic by doing a couple of pathalogical things, but I expect it work unless you're actively trying to defeat the system.
identical assembly. No C++ compiler that I'm aware of does that.
e.g., std::vector<Foo * > and std::vector<Bar * > generate identical code for whatever you do, as they both only deal with the pointer, never dereference it in any way. Also, in code like
No C++ compiler that I'm aware of folds these cases into one; The C# generics do (not sure about non-generic code with identical final machine code). I would be surprised if idiomatic C++ code could be shortened by more than 50% by a compiler that did. However, if you write your code for column-major access, the binary can go down 90% if the compiler did that.
edit:formatting
e.g., std::vector<Foo * > and std::vector<Bar * > generate identical code for whatever you do, as they both only deal with the pointer, never dereference it in any way. Also, in code like
template <class T> T get(T x[], int i) { return x[i]; }
No C++ compiler that I'm aware of folds these cases into one; The C# generics do (not sure about non-generic code with identical final machine code). I would be surprised if idiomatic C++ code could be shortened by more than 50% by a compiler that did. However, if you write your code for column-major access, the binary can go down 90% if the compiler did that.
edit:formatting
The C++ committee answer to this is to use "partial template specialization". I'm hoping all the standard libraries I use such as Boost etc have already done this to avoid code bloat.
But I agree that it would be nice if the compiler did this automatically.
But I agree that it would be nice if the compiler did this automatically.
C++ was designed in a way where only the features you use have overhead, so it is fairly easy to write the most computationally intense parts in C while using higher level abstractions everywhere else. This is something I missed a lot in Java when trying to write high performance code.
But most of this design was done 20 years ago and so used assumptions about CPU performance are mostly wrong for both modern CPUs and modern operating systems. For example overhead of calling virtual and non-virtual method across library boundary on ELF based system on reasonably modern CPU is essentially same.
This is a very minor detail - so an optimization that was made 20 years ago is no longer relevant. Neither is it harmful or especially expensive.
> Using C++ the way authors intend
Like I said, you can write horribly inefficient C++ code if you really want, but that's not a fault of the tool. The fact remains you can write small and efficient C++ code, but that it's devilishly hard to do it with Java.
Or C#, BTW ;-)
Like I said, you can write horribly inefficient C++ code if you really want, but that's not a fault of the tool. The fact remains you can write small and efficient C++ code, but that it's devilishly hard to do it with Java.
Or C#, BTW ;-)
There are also many optimizations that a JIT can do that cannot be done with a static compiler.
The optimizations will basically claim back the inefficiencies introduced by the compiler/vm stack. I am not sure those run-time optimizations allow you to beat reasonably optimal C++ code. Remember that many JIT optimizations apply only to interpreted code and would not be required with native code.
>Remember that many JIT optimizations apply only to interpreted code and would not be required with native code.
No, I'm talking about things like being able to skip virtual table lookups for method calls, you can't do that in C++. You can't short circuit them either. You can in a JIT. You also get superior garbage collection performance with a JIT compared to static compiling.
No, I'm talking about things like being able to skip virtual table lookups for method calls, you can't do that in C++. You can't short circuit them either. You can in a JIT. You also get superior garbage collection performance with a JIT compared to static compiling.
Many of them are possible in theory. Few are implemented in practice, and even fewer apply in code found in the wild.
e.g. promoting an Integer[] array to an int[] array is something that Java will not do, although in some cases it is theoretically possible (and LuaJIT2 comes close to doing something equivalent).
e.g. promoting an Integer[] array to an int[] array is something that Java will not do, although in some cases it is theoretically possible (and LuaJIT2 comes close to doing something equivalent).
Was thinking this too, but I wouldn't forget Apache has also been working on Thrift:
http://wiki.apache.org/thrift
http://wiki.apache.org/thrift
Oracle is succeeding in a few short months at a task that Microsoft (through malice) and Sun (through incompetence) failed to perform in over 15 years: the killing of the Java platform.
A question I have found myself asking recently is: "Why not a fork?" Can someone explain to me why Apache shouldn't just rename Java to, say Jive (okay, bad example) and proceed with putting out its own certification tests?
All Jive code could at the beginning run on JVM 6, and later the Jive VM would be the place for new feature development.
Google would get behind this, I bet. Many developers could be induced to stick with the free, Non-Oracle version of the world, especially this year.
So, what am I missing?
All Jive code could at the beginning run on JVM 6, and later the Jive VM would be the place for new feature development.
Google would get behind this, I bet. Many developers could be induced to stick with the free, Non-Oracle version of the world, especially this year.
So, what am I missing?
this is what google did with dalvik/android. They are being sued for that basically.
Working on openjdk gives you a patent grant, working on a fork which is not java does not, apparently.
As I understand it, that's not quite true: You write conforming Java code and compile that to JVM bytecode. That bytecode is then translated into Dalvik VM bytecode. Java (the language and the compiler) is still an integral part of the toolchain, there's just no Java-the-VM on the target device.
Google could, perhaps should, have gone for a Go -> Dalvik compiler and avoided all this.
Google could, perhaps should, have gone for a Go -> Dalvik compiler and avoided all this.
The Oracle-Google lawsuit is about patent claims over implementation details in Dalvik and the standard library. While all your details are correct, they're not at issue.
Getting back to the OP's point -- any Java-clone will run afoul of Oracle's patents even more so than Google has with Dalvik. Even Microsoft's .NET CLR likely violates some of these patents.
Getting back to the OP's point -- any Java-clone will run afoul of Oracle's patents even more so than Google has with Dalvik. Even Microsoft's .NET CLR likely violates some of these patents.
Exactly. Google's run around also had to do specifically with Java Mobile restrictions -- something Sun wanted Google to pay for.
The question Oracle's lawsuit raises is whether or not it's possible to compile Java without infringing on their patents. I still think my question has more merit than wmf suggests -- MS did essentially what I'm suggesting with C#.
The question Oracle's lawsuit raises is whether or not it's possible to compile Java without infringing on their patents. I still think my question has more merit than wmf suggests -- MS did essentially what I'm suggesting with C#.
but the issue is not only about compiling is it?
I recall that a few of the patents (debatable as they are) specifically relate to runtime, such as the one about the security manager.
Such a patent would invalidate the whole runtime code as it was built around such a policy.
So if you want to avoid being sued you need to use a different language, a different compiler and a different runtime, which is what MS did with C#.
But then why would you need a patent-minefield such as Jive-the-forked-java in the first place?
So if you want to avoid being sued you need to use a different language, a different compiler and a different runtime, which is what MS did with C#.
But then why would you need a patent-minefield such as Jive-the-forked-java in the first place?
A lot of power in the JVM comes from the JIT. To repro that, you're likely to run into patent lawsuits from Oracle even if you do discover/implement the optimizations in a clean-room.
I think we discussed this 13 hours ago. http://news.ycombinator.com/item?id=1889030
Yet here we are. Politics. Politics and business pissing contests. If they do ruin or derail Java, can you imagine the amount of lost capital? The amount of man-centuries of work that would at the very least now have to be ported?
Of course, I don't think that will happen. The momentum is too large. But it could, and the fact that you have a bunch of salesman-type assholes threatening to destroy billions (or more) in value in order to measure the length of their dicks is sickening.
Politics is sort of like farting. Yes, everyone does it. Yes, it is normal. But it smells, and the people who do it a lot are kind of gross.