| News | Features | Interviews |
| Blog | Contact | Editorials |
| Project Sumatra improves Java performance with OpenCL |
| By Thom Holwerda, submitted by MOS6510 on 2012-10-10 23:47:06 |
| "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." |
|
| mc |
| By gloucestershrubhill on 2012-10-11 00:10:03 |
| Oooh, less laggy Minecraft... |
 - Score: 1 |
| Security |
| By WorknMan on 2012-10-11 01:04:47 |
| 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. |
| - Score: 2 |
| RE: Security |
| By kaiwai on 2012-10-11 02:31:41 |
|
> 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. |
| - Score: 2 |
| RE: Security |
| By Alfman on 2012-10-11 03:50:35 |
|
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 |
| - Score: 4 |
| RE[2]: Security |
| By kwan_e on 2012-10-11 04:01:47 |
|
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. |
| - Score: 2 |
| RE[3]: Security |
| By Alfman on 2012-10-11 04:58:44 |
|
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. |
| - Score: 2 |
| RE[4]: Security |
| By moondevil on 2012-10-11 05:55:20 |
|
> 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. |
| - Score: 2 |
| RE: Security |
| By moondevil on 2012-10-11 06:01:56 |
|
> 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. |
| - Score: 2 |
| I would prefer ... |
| By fithisux on 2012-10-11 07:39:37 |
| 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. |
| - Score: 2 |
| RE: Security |
| By lucas_maximus on 2012-10-11 07:52:48 |
| Just disable the plugin or only let it run on certain domains. |
| - Score: 2 |
| News | Features | Interviews |
| Blog | Contact | Editorials |