So what you're saying is....a year ago you didn't actually pay attention to current events? It's not like this hasn't been documentably been taking place since the warrant-less wiretapping + retroactive telecom immunity fiasco years ago (and then again with Thomas Drake's leaks).
From the perspective of most supercomputer users, the problem here is that you want to use something which is not Fortran or C. Very little hardcore numerical stuff is done outside of those two languages. I'm not saying that's a good thing, but it is the reason why there's so little incentive to have good compiler support.
...should be running on an operating system which is also correctly permissioned.
Why anyone would allow a user defined (end-user system defined).class file to run on it is beyond me too...but that is part of the design of Java.
That's part of the design of every language. Nothing stops a C programmer from calling "execvp", or a Python programmer from calling eval(), or a PHP programmer from using unsanitized user input to build an SQL query, except common sense and good education. With most languages we call people who execute untrusted code "dumb" (or soon-to-be-unemployed). With Java we call them that too, but some people apparently still think it's okay. Oracle's guidelines point out that if you're relying on the SecurityManager, you're probably doing it wrong (their actual words are "should be scrutinized" and "considered a last resort").
Can the Security Manager add a nice additional layer of protection if you use it correctly? Yes. Is it problematic that the Reflection APIs let you sidestep it? Yes. But if you're running Java in any kind of mission critical setting (i.e., enterprise/server apps), and that's all that stands between you and hostile code, you probably shouldn't have your job.
The article you just linked to is describing...wait for it...flaws in the security sandbox which is used for browser plugins. A standard JRE app is not sandboxed, unless you're using a custom ClassLoader for plugins or weird stuff like that. Can you give an example of a datacenter Java application where this would be relevant and how it would be exploited? Why a typical enterprise server app would be running user supplied.class files is beyond me.
[Citation needed]. I regularly see stories about nasty bugs in the Java plugin for web-browsers that allow drive-by downloads and code execution vulnerabilities. I've never heard of Java having to be pulled from a data-center. I'm not saying it isn't true, I'm just saying I'd like to see more info, because it's the first I've heard of this.
And you'll notice even on your linked counterexample there are 5/11 examples where Java is within the margin of error on CPU time. Take the time to go back and read the link I posted. "Java vs C" goes back and forth depending on the algorithm in question and the cache characteristics of the target platform.
Manual memory management is a whole class of bugs that Java doesn't have to deal with. A good C/C++ programmer shouldn't have *that* much difficulty, but it does add to debugging costs and detracts from mental focus on the algorithmic aspects of the problem.
Many JVM implementations can make use of SIMD at run time because they know what they're running on. Additionally, in many algorithms, the pointer indirection cost in C is higher than the bounds checking cost in Java (because pointers make life hard on optimizing compilers, and HotSpot doesn't have that disadvantage). Cache coherency also plays a big role. See the link in my reply to parent comment.
Wrong. This hasn't been true for more than 15 years 1996. It's a JIT-compiled language, which means it has a slow startup time, but once the VM is warm, it can actually outperform C on numerical code. Really.
....InPhase's tapestry was demonstrably there in 2008, and it was writable, but they went under due to bad management. I'm sure Sony & Panasonic aren't the current IP holders, so whatever they break to market is going to be technologically inferior to boot.
I understand the science here, and mostly agree with your statement, but your analogy is disingenous. Bear skin rugs are typically capable of neither reproduction nor mutation.
I'm not at all in favor of government subsidies, but I just needed to point out that....well....I dunno what rural-rich they're talking about. Sure we have the occasional successful author or entrepreneur, but they're vastly outnumbered by those living in poverty. Rural poverty looks completely different from urban poverty, but it's poverty nonetheless.
My "at" was actually a "that" with a thorn, which was stripped by/.'s filters. But that is also correct usage if you're an English speaker instead of Icelandic.
Oh, I'm not at all in the dark as to why people think it could work or where they get the ideas (and I'm a huge Ender's Game fan myself), but it's still a disturbingly common misconception that needs to be corrected.
So what you're saying is....a year ago you didn't actually pay attention to current events? It's not like this hasn't been documentably been taking place since the warrant-less wiretapping + retroactive telecom immunity fiasco years ago (and then again with Thomas Drake's leaks).
From the perspective of most supercomputer users, the problem here is that you want to use something which is not Fortran or C. Very little hardcore numerical stuff is done outside of those two languages. I'm not saying that's a good thing, but it is the reason why there's so little incentive to have good compiler support.
That's part of the design of every language. Nothing stops a C programmer from calling "execvp", or a Python programmer from calling eval(), or a PHP programmer from using unsanitized user input to build an SQL query, except common sense and good education. With most languages we call people who execute untrusted code "dumb" (or soon-to-be-unemployed). With Java we call them that too, but some people apparently still think it's okay. Oracle's guidelines point out that if you're relying on the SecurityManager, you're probably doing it wrong (their actual words are "should be scrutinized" and "considered a last resort").
Can the Security Manager add a nice additional layer of protection if you use it correctly? Yes. Is it problematic that the Reflection APIs let you sidestep it? Yes. But if you're running Java in any kind of mission critical setting (i.e., enterprise/server apps), and that's all that stands between you and hostile code, you probably shouldn't have your job.
The article you just linked to is describing...wait for it...flaws in the security sandbox which is used for browser plugins. A standard JRE app is not sandboxed, unless you're using a custom ClassLoader for plugins or weird stuff like that. Can you give an example of a datacenter Java application where this would be relevant and how it would be exploited? Why a typical enterprise server app would be running user supplied .class files is beyond me.
[Citation needed]. I regularly see stories about nasty bugs in the Java plugin for web-browsers that allow drive-by downloads and code execution vulnerabilities. I've never heard of Java having to be pulled from a data-center. I'm not saying it isn't true, I'm just saying I'd like to see more info, because it's the first I've heard of this.
Bingo.
And you'll notice even on your linked counterexample there are 5/11 examples where Java is within the margin of error on CPU time. Take the time to go back and read the link I posted. "Java vs C" goes back and forth depending on the algorithm in question and the cache characteristics of the target platform.
For applets in a web-browser. Running a Java server is a different beast with different concerns.
Manual memory management is a whole class of bugs that Java doesn't have to deal with. A good C/C++ programmer shouldn't have *that* much difficulty, but it does add to debugging costs and detracts from mental focus on the algorithmic aspects of the problem.
Many JVM implementations can make use of SIMD at run time because they know what they're running on. Additionally, in many algorithms, the pointer indirection cost in C is higher than the bounds checking cost in Java (because pointers make life hard on optimizing compilers, and HotSpot doesn't have that disadvantage). Cache coherency also plays a big role. See the link in my reply to parent comment.
Wrong. This hasn't been true for more than 15 years 1996. It's a JIT-compiled language, which means it has a slow startup time, but once the VM is warm, it can actually outperform C on numerical code. Really.
I've been waiting for this all year. I've got some fun stuff planned. Good luck to all contestants :)
....InPhase's tapestry was demonstrably there in 2008, and it was writable, but they went under due to bad management. I'm sure Sony & Panasonic aren't the current IP holders, so whatever they break to market is going to be technologically inferior to boot.
double woosh
I guess it was too early to expect that the researchers would have developed a reliable humor-recognition heuristic.
I understand the science here, and mostly agree with your statement, but your analogy is disingenous. Bear skin rugs are typically capable of neither reproduction nor mutation.
I'm not at all in favor of government subsidies, but I just needed to point out that....well....I dunno what rural-rich they're talking about. Sure we have the occasional successful author or entrepreneur, but they're vastly outnumbered by those living in poverty. Rural poverty looks completely different from urban poverty, but it's poverty nonetheless.
It means they don't want to have 84 hour work weeks for the rest of their lives.
My "at" was actually a "that" with a thorn, which was stripped by /.'s filters. But that is also correct usage if you're an English speaker instead of Icelandic.
A thorn can be either a voiced or voiceless dental fricative, even if modern Icelandic orthography only uses it for the former.
Not only at, but we already have two letters to solve ðis problem (although it would help if /. didn't delete the first one).
Every Mac I've ever used in the last 20 years has { and } on the keyboard. But we Americans don't have weird alphabets either ;).
Comtraya, to use the correct Altairan spelling. But I wish I had modpoints for you anyway.
I was thinking the second moreso than the first, but there are definitely people for whom the first is a problem as well.
Oh, I'm not at all in the dark as to why people think it could work or where they get the ideas (and I'm a huge Ender's Game fan myself), but it's still a disturbingly common misconception that needs to be corrected.