3 ms·

Please expound on that. Garbage collection, no pointer arithmetic, and array bounds checking seems like good safety features.

by copperx 10y ago

duneroadrunner 10y ago
Well, I don't know about java's reputation, but there's this: http://www.cvedetails.com/product/19117/Oracle-JRE.html?vendor_id=93 http://www.cvedetails.com/product/19117/Oracle-JRE.html?vend... http://www.cvedetails.com/product/1526/SUN-JRE.html?vendor_id=5 http://www.cvedetails.com/product/1526/SUN-JRE.html?vendor_i...
- chungy 10y ago
  Security exploits say nothing about the language's memory safety design. Java still qualifies as a safe language.
  - EugeneOZ 10y ago
    As a safe language from race conditions or memory leaks?
- adrianN 10y ago
  The Java VM is written in C though.
  - rat87 10y ago
    There are many java vms The most popular(hotspot/openjdk) is written in c++/assembly
EugeneOZ 10y ago
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 https://www.google.com/#newwindow=1&q=null+pointer+exception
- gravypod 10y ago
  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.
  - EugeneOZ 10y ago
    I can say it.
lmm 10y ago
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.

Please expound on that. Garbage collection, no pointer arithmetic, and array bounds checking seems like good safety features.

by copperx 10y ago

Please expound on that. Garbage collection, no pointer arithmetic, and array bounds checking seems like good safety features.

duneroadrunner 10y ago

Well, I don't know about java's reputation, but there's this: http://www.cvedetails.com/product/19117/Oracle-JRE.html?vendor_id=93 http://www.cvedetails.com/product/19117/Oracle-JRE.html?vend... http://www.cvedetails.com/product/1526/SUN-JRE.html?vendor_id=5 http://www.cvedetails.com/product/1526/SUN-JRE.html?vendor_i...

chungy 10y ago
Security exploits say nothing about the language's memory safety design. Java still qualifies as a safe language.
- EugeneOZ 10y ago
  As a safe language from race conditions or memory leaks?
adrianN 10y ago
The Java VM is written in C though.
- rat87 10y ago
  There are many java vms The most popular(hotspot/openjdk) is written in c++/assembly

EugeneOZ 10y ago

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 https://www.google.com/#newwindow=1&q=null+pointer+exception

gravypod 10y ago
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.
- EugeneOZ 10y ago
  I can say it.

lmm 10y ago

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.