Re:Rust vs C Pitfalls
by EugeneOZ on Wednesday December 28, 2016 @02:56AM
(#13269112)
Java has not so great reputation about safety.
[ Parent
| on HN ]
Java's bad safety reputation comes mostly from the Java plugin, where many inventive ways to bypass its sandbox have been discovered. When used as a normal programming language, without depending on it for sandboxing (that is, when all code running in the JVM is trusted), its safety is quite good.
(Java also has a not so great reputation about speed. That one also comes from the Java plugin, which often took minutes to start up, while keeping the Netscape browser UI locked up.)
Re:Rust vs C Pitfalls
by the_why_of_y on Wednesday December 28, 2016 @07:28AM
(#13270070)
... and just to add to that, if you look at the other popular sandboxed client-side runtimes, i.e., Adobe Flash and various JavaScript-enabled browsers (all of them implemented in C++), you will find a similar number of critical vulnerabilities.
I see a lot of NPE in IntelliJ IDEA, especially EAPs. It's not browser's plugin.
NPEs are not a security issue in the same sense as a buffer overflow or null pointer dereference.
That's interesting because it is based on the same principles of not letting developers do harmful thing as a way to guarantee security.
Rust uses RAII for memory-safety, not just language constructions to raise some limitations.
Please expound on that. Garbage collection, no pointer arithmetic, and array bounds checking seems like good safety features.
No sum types (the Java alternative to Rust enums is the horribly verbose visitor pattern, so a lot of the time people don't bother). null. A verbose and unabstractable "checked exception" system (that the standard library uses poorly in places) that leaves many users resorting to unchecked exceptions (panics) instead. Uninitialized field problems because methods are virtual even when called from superclass constructors. Excessive overhead to custom types that leads to using weakly typed Strings etc. rather than domain types. Poor abstraction facilities that lead to a culture of "magic" annotations and runtime reflection (or worse, proxies and bytecode manipulation) e.g. @Transactional, @Inject.
Java is safer than C, but it's a long way behind a modern functional language like Rust.
Re:Rust vs C Pitfalls
by duneroadrunner on Wednesday December 28, 2016 @03:44AM
(#13269314)
Well, I don't know about java's reputation, but there's this:
http://www.cvedetails.com/product/19117/Oracle-JRE.html?vend...
http://www.cvedetails.com/product/1526/SUN-JRE.html?vendor_i...
Security exploits say nothing about the language's memory safety design. Java still qualifies as a safe language.
As a safe language from race conditions or memory leaks?
The Java VM is written in C though.
There are many java vms
The most popular(hotspot/openjdk) is written in c++/assembly
GC is not about safety at all, sorry.
I'm not going to start flamewar, but just to answer your question:
https://www.google.com/#newwindow=1&q=null+pointer+exception
You can't say NPEs are an example that Java is unsafe. The propegation is Nulls isn't Java's fault and Java's evolving currently to make use of Optionals as we speak to attempt to avoid this.