Linked by Thom Holwerda on Wed 10th Oct 2012 23:47 UTC, submitted by MOS6510
Java "Java is a programming language that allows developers to write once and deploy everywhere - from high-end gaming desktops to smartphones. Its OS-agnostic and widespread nature is one of its strongest selling points, but one area where it can fall flat is performance. Generally, Java applications are not going to perform as well as native applications written for a specific OS. However, thanks to Project Sumatra that performance gap may soon become less of an issue."
Order by: Score:
mc
by gloucestershrubhill on Thu 11th Oct 2012 00:10 UTC
gloucestershrubhill
Member since:
2010-08-10

Oooh, less laggy Minecraft...

Reply Score: 1

Security
by WorknMan on Thu 11th Oct 2012 01:04 UTC
WorknMan
Member since:
2005-11-13

Is it even possible to run Java securely on a desktop these days, especially as a browser plugin? Mind you, I'm not trolling here... I'm genuinely asking, based on all the zero-day Java attacks I've been reading about lately.

Reply Score: 2

RE: Security
by kaiwai on Thu 11th Oct 2012 02:31 UTC in reply to "Security"
kaiwai Member since:
2005-07-06

Is it even possible to run Java securely on a desktop these days, especially as a browser plugin? Mind you, I'm not trolling here... I'm genuinely asking, based on all the zero-day Java attacks I've been reading about lately.


The first thing I did when I had a Mac was to delete the Java plug in (although it was a stub in recent versions which pointed to Mac OS X downloading the latest version I still didn't like it 'there'). I guess you could do the same with Java on Windows (I don't have it installed) by disabling the Java plugin in both Internet Explorer and NPAPI browsers.

Reply Score: 2

RE: Security
by Alfman on Thu 11th Oct 2012 03:50 UTC in reply to "Security"
Alfman Member since:
2011-01-28

WorknMan,

"Is it even possible to run Java securely on a desktop these days, especially as a browser plugin?"

I don't know how well the java browser plugin security is faring these days?

However as a local desktop platform I don't think Java deserves too much criticism since the language has never been less secure than native apps in the first place. Consider that anything which manages to break out of the java sandbox through a java vulnerability is still access-limited by the same user-space restrictions as a non-VM language like C. While a vulnerability is disappointing, the worst case scenario is that the java app gains access to the same userland syscalls that a native C app can access anyways.

Browsers are at risk because they run untrusted arbitrary code from the internet and they rely on the VM to isolate applets from the main browser process.


Edit: This may be a bit tangential, but another security consideration might be to factor in the likelihood of code written in language X or Y to contain vulnerabilities. I'd assume that Java's strict typecasting and bounds checking rules, as well as general lack of pointer arithmetic make it less likely for Java applications to contain severe (non language related) vulnerabilities.

Edited 2012-10-11 04:05 UTC

Reply Score: 4

RE[2]: Security
by kwan_e on Thu 11th Oct 2012 04:01 UTC in reply to "RE: Security"
kwan_e Member since:
2007-02-18

I'm not a security expert:

While a vulnerability is disappointing, the worst case scenario is that the java app gains access to the same userland syscalls that a native C app can access anyways.


Except with Java, isn't the vulnerability potentially cross platform? Whereas with native exploits, you'd have to write one for each different platform.

Reply Score: 2

RE[3]: Security
by Alfman on Thu 11th Oct 2012 04:58 UTC in reply to "RE[2]: Security"
Alfman Member since:
2011-01-28

kwan_e,


"Except with Java, isn't the vulnerability potentially cross platform? Whereas with native exploits, you'd have to write one for each different platform."

Hmm, I'm not exactly sure what you mean. If you're talking about a vulnerability in code written in java, then yes that would probably be vulnerable on every platform supporting java. However this would not be an instance of a bug in the Java VM, but rather an application specific bug.


If your talking about a vulnerability in the Java VM, then it may or may not be a cross platform vulnerability. Remember that the VM itself is a native application that has to be written to support every target platform. A bug in the just-in-time-compiler for x86 isn't necessarily going to appear in the JIT compiler for x86-64 or ARM.

For the sake of argument though, let's pretend Java contained a backdoor and there was *zero* security in the VM...this would preclude Java as a viable platform for browser applets since malicious websites could gain access to your local account using the backdoor.

Now consider an application you download to run locally, you have the choice of either a native binary or a java version. Can you see why having a backdoor in the Java VM isn't an additional security risk compared to the native version? Even with the VM backdoor, the java application would be on equal footing with the native application security-wise. Both would be subject to the same userspace access as imposed by the kernel.

Reply Score: 2

RE[4]: Security
by moondevil on Thu 11th Oct 2012 05:55 UTC in reply to "RE[3]: Security"
moondevil Member since:
2005-07-08

If your talking about a vulnerability in the Java VM, then it may or may not be a cross platform vulnerability. Remember that the VM itself is a native application that has to be written to support every target platform. A bug in the just-in-time-compiler for x86 isn't necessarily going to appear in the JIT compiler for x86-64 or ARM.


At least in OpenJDK/JVM this might improve when project Graal gets integrated.

Graal is the project to integrate Maxime JIT which is 100% Java code.

The idea is to follow Jikes, Maxime and Squawk VM projects where the Java was used to write the VM, with a very minimal set of native code.

Reply Score: 2

RE[5]: Security
by Alfman on Thu 11th Oct 2012 14:34 UTC in reply to "RE[4]: Security"
Alfman Member since:
2011-01-28

moondevil,

"Graal is the project to integrate Maxime JIT which is 100% Java code."

I wasn't aware, that's very interesting. I wonder how you bootstrap such a thing. Do you need another VM to bootstrap the Maxime JIT's code?

Nice diagram for a project you mentioned:
http://labs.oracle.com/projects/squawk/squawk-rjvm.html


"Even with VM exploits it depends on which VM you are using, there are many more out there, besides Oracle's."

I'm not ready to stop calling it Sun's VM ;)

Reply Score: 2

RE[6]: Security
by moondevil on Thu 11th Oct 2012 18:55 UTC in reply to "RE[5]: Security"
moondevil Member since:
2005-07-08

Graal:
http://openjdk.java.net/projects/graal/
http://www.oracle.com/technetwork/java/javase/community/jvmls2012-1...


Graal is based on Maxime's work,
https://wikis.oracle.com/display/MaxineVM/Home

I wasn't aware, that's very interesting. I wonder how you bootstrap such a thing. Do you need another VM to bootstrap the Maxime JIT's code?


In a way yes.

This paper provides a nice overview how bootstraping works,
https://wikis.oracle.com/display/MaxineVM/Technical+Report

The idea is quite simple, you use the JIT compiler offline to generate the basic VM image for the classes that take care of the VM ground work.

The compiler recognises special annotations that allow trusted Java code to perform unsafe operations, this minimizes the requirements to native methods.

Additionally you have a thin layer for the native methods.

Another example is the Jikes RVM,
http://jikesrvm.org/Presentations

What I miss is that the official JDK still lacks an AOT compiler, while other vendors do offer them. It is not easy to convince project managers to pay for native code compilers for Java, unless the project really requires them.

I'm not ready to stop calling it Sun's VM ;)


I used to write Sun/Oracle VM in the last months, but one needs to face the sad reality that Sun is gone.

Reply Score: 2

RE[3]: Security
by JAlexoid on Thu 11th Oct 2012 12:25 UTC in reply to "RE[2]: Security"
JAlexoid Member since:
2009-05-19

Except with Java, isn't the vulnerability potentially cross platform?

You have to break out of the sandbox and what you do afterwards is platform dependent.

Reply Score: 2

RE[4]: Security
by kwan_e on Thu 11th Oct 2012 15:20 UTC in reply to "RE[3]: Security"
kwan_e Member since:
2007-02-18

"Except with Java, isn't the vulnerability potentially cross platform?

You have to break out of the sandbox and what you do afterwards is platform dependent.
"

But does it? If a Java vulnerability allows the VM itself to be controlled, the exploit can just run Java code with full permissions.

Much like how in the past, MS Office's Visual Basic potentially allowed malware to run on a Mac (again, not a security expert, so I don't know if it ended up being just hype, like Y2K).

Reply Score: 2

RE[5]: Security
by JAlexoid on Thu 11th Oct 2012 15:36 UTC in reply to "RE[4]: Security"
JAlexoid Member since:
2009-05-19

Well you can't do anything useful for a malicious intent through Java.
(Unless you are going to send a few emails or something like it)

Edited 2012-10-11 15:36 UTC

Reply Score: 2

RE[6]: Security
by kwan_e on Thu 11th Oct 2012 15:57 UTC in reply to "RE[5]: Security"
kwan_e Member since:
2007-02-18

Well you can't do anything useful for a malicious intent through Java.
(Unless you are going to send a few emails or something like it)


What if the JVM is connected and authenticated to a database when the malicious program gets control. A malicious program can use JDBC to get sensitive information from that database without needing to go native.

Reply Score: 2

RE[7]: Security
by Alfman on Thu 11th Oct 2012 16:43 UTC in reply to "RE[6]: Security"
Alfman Member since:
2011-01-28

kwan_e,

"What if the JVM is connected and authenticated to a database when the malicious program gets control. A malicious program can use JDBC to get sensitive information from that database without needing to go native."

Can you elaborate the specifics of where this malicious program came from? The reason I ask is because we need to ask whether the same attack vector is significantly more likely to happen in java than a non-java program.

Did the administrator unknowingly install the malicious program in the first place? Did he install a trusted program that contains a remotely exploitable application vulnerability, which enables a remote attacker to install & execute the malicious instructions? Does the compiler contain a bug that can be exploited remotely execute malicious instructions?

All these things are possible, but ask yourself if Java is inherently less secure than other languages for running local programs. Escaping java's sandbox is bad, but are there any instances where using Java is worse for security than using another languages like C, which doesn't have any sandbox whatsoever? Is there something specific you think I'm overlooking?

Reply Score: 2

RE[7]: Security
by JAlexoid on Fri 12th Oct 2012 00:39 UTC in reply to "RE[6]: Security"
JAlexoid Member since:
2009-05-19

It's not like it's one JVM for the whole OS. And there is no local IPC mechanism in Java. If the JVM is connected to a DB, then you it's already within your sandbox.

At most what you could do is steal the encrypted trusted keystore at most(quite useless without a targeted attack).

Reply Score: 2

RE[2]: Security
by tracul on Thu 11th Oct 2012 09:16 UTC in reply to "RE: Security"
tracul Member since:
2011-08-21

However as a local desktop platform I don't think Java deserves too much criticism since the language has never been less secure than native apps in the first place. Consider that anything which manages to break out of the java sandbox through a java vulnerability is still access-limited by the same user-space restrictions as a non-VM language like C. While a vulnerability is disappointing, the worst case scenario is that the java app gains access to the same userland syscalls that a native C app can access anyways.


The difference is that you can write "perfect" java code and still your app will be potentially vulnerable (outside your control), whereas in C[++] it's all about the written code (under your control)

Reply Score: 1

RE[3]: Security
by the_trapper on Thu 11th Oct 2012 11:19 UTC in reply to "RE[2]: Security"
the_trapper Member since:
2005-07-07

The difference is that you can write "perfect" java code and still your app will be potentially vulnerable (outside your control), whereas in C[++] it's all about the written code (under your control)


Until you link against third party libraries. A lot of browser flaws aren't actually Microsoft, Mozilla, or Google's fault. They are due to flaws in things like libjpeg, libpng, or openssl. Java applications are no different, you can think of Java as a big third party library. Even drivers, firmwares, and BIOSes have been known to have remotely exploitable vulnerabilities in them.

As a programmer, you never have all the code "under your control" unless you go to extreme lengths like
designing your own hardware, firmware, and operating system from scratch.

Reply Score: 2

RE[3]: Security
by moondevil on Thu 11th Oct 2012 11:20 UTC in reply to "RE[2]: Security"
moondevil Member since:
2005-07-08

The difference is that you can write "perfect" java code and still your app will be potentially vulnerable (outside your control), whereas in C[++] it's all about the written code (under your control)


Can you enlighten me how are you able to have more control over libc, libstdc++, msvcrt,... than Java developers have over JRE?

Reply Score: 2

RE[3]: Security
by Alfman on Thu 11th Oct 2012 14:52 UTC in reply to "RE[2]: Security"
Alfman Member since:
2011-01-28

tracul,

"The difference is that you can write 'perfect' java code and still your app will be potentially vulnerable (outside your control), whereas in C[++] it's all about the written code (under your control)"

I disagree. A "perfect" ANSI-C program can still be vulnerable to libc bugs (aka malloc, fscanf, etc).

Also, modern C code compilation can be incredibly complex. There are memory barriers, aliasing constraints, auto SIMD/pipelining, overflow assumptions, threading related bugs, etc. A bug or bad assumption in any of these features might be remotely exploitable (ie a JPEG rasterization library).

To the extent that a JIT compiler is more complex, I'll grant you that it is more likely to contain bugs, but bugs are inherently possible whether the code compilation happens ahead of time or at run time.

Reply Score: 2

RE: Security
by moondevil on Thu 11th Oct 2012 06:01 UTC in reply to "Security"
moondevil Member since:
2005-07-08

Is it even possible to run Java securely on a desktop these days, especially as a browser plugin? Mind you, I'm not trolling here... I'm genuinely asking, based on all the zero-day Java attacks I've been reading about lately.


As secure as any C or C++ application.

Press always fails to mention that the Java security exploits are not in the language, rather in the native code that compromisses the virtual machine, in case a VM is used at all.

When a VM is used, then the exploit is done via the data the methods implemented in C/C++ expect, or by trying to find out bytecode sequences that the VM's verifier assumes are safe but are not.

Even with VM exploits it depends on which VM you are using, there are many more out there, besides Oracle's.

Reply Score: 2

RE: Security
by lucas_maximus on Thu 11th Oct 2012 07:52 UTC in reply to "Security"
lucas_maximus Member since:
2009-08-18

Just disable the plugin or only let it run on certain domains.

Reply Score: 2

I would prefer ...
by fithisux on Thu 11th Oct 2012 07:39 UTC
fithisux
Member since:
2006-01-22

if they made java compile with mingw on Windows and finish the tigershark port. OpenCL these days on GPU rely on closed drivers or open with partial documentation. Projects like (hopefully not vaporware) Parallela or Open Graphics aim to solve these problems. But until opencl/and hardwrae become open (in terms of HW interface, not necessarily inner workings) I believe manpower should be invested elsewhere. But it is their time spent and it was not easy. For this, congratulations are suitable.

Reply Score: 2

Java performance
by dsmogor on Thu 11th Oct 2012 10:37 UTC
dsmogor
Member since:
2005-09-01

The crux if java performance problems comes not from its raw number crunching abilities (it stands agains c++ in micro benchmarks) but its style of memory mamagement. Moreover JIT has its own memory overhead (runtime performance metrics, heaily instrumented code). Managing memory in pressured conditions takes time, not being able to share heavy runtime between processes adds to it.
Having jit take care of branch optimization also made priogrammers prefer more dynamic style (virtual by default). If they used it in C++ (with GC) the resulting runtime performance would be worse.
Is summ practical java lower performance is a price paid for programmers convenience more than inherent platform flaw.

Reply Score: 2

RE: Java performance
by JAlexoid on Thu 11th Oct 2012 12:22 UTC in reply to "Java performance"
JAlexoid Member since:
2009-05-19

Managing memory in pressured conditions takes time

Yep. Java definitely has issues with deterministic performance, but so do most GC'd platforms.

Reply Score: 2

Performance is not definitive
by JAlexoid on Thu 11th Oct 2012 12:18 UTC
JAlexoid
Member since:
2009-05-19

Java performance is not an issue, it's better than most languanges(there's a ton of benchmarks). The issue is JNI performance and deterministic(aka real-time) performance.

Edited 2012-10-11 12:19 UTC

Reply Score: 2

RE: Performance is not definitive
by Soulbender on Sun 14th Oct 2012 03:28 UTC in reply to "Performance is not definitive"
Soulbender Member since:
2005-08-18

Java performance is not an issue


If it feels slow and reacts slow...then it is slow.
Pretty much every single Java application I've ever used, server as well as desktop, pretty much used up all the RAM and ran like molasses.

(there's a ton of benchmarks


Benchmarks are like asshole; everybody has one and you'll be happier caring only about your own.

Reply Score: 2