5 ms·

One of the most under appreciated things about the JVM is its well-defined memory model.

• swiftcoder 2y ago
  Unfortunately immediately undermined by the decision to not address nullability out of the gate. It's fantastic that null pointer exceptions are well-defined on the JVM - but they still tend to bring your program to a screaming halt.
  • writebetterc 2y ago
    I believe that the parent is talking about how Java, and in turn the JVM, defines its memory model, which describes formally how memory reads and writes occur in the presence of multiple threads of execution. For example, data races are well-defined in Java: Either you read the old or the new value, you'll never read a mix of two values. Having a well-defined memory model is important when running on infra with very different models, such as x86 and aarch64.
    • swiftcoder 2y ago
      [flagged]
      • writebetterc 2y ago
        No reason to be rude, it was really not clear that you knew that as null pointers have nothing to do with memory models.
  • GoblinSlayer 2y ago
    Is it a big difference if you have ValueNotPresentException from nullable unwrap instead of NullPointerException? Oh, wait, it exists https://docs.oracle.com/javase/8/docs/api/java/util/Optional.html https://docs.oracle.com/javase/8/docs/api/java/util/Optional...
    • swiftcoder 2y ago
      The big difference is that Optional has ergonomic features like .map(), .ifPresent(), .orElse(), that reduce the verbosity of repeated if blocks checking if values are present or not.
    • edflsafoiewq 2y ago
      The problem is basically every type is implicitly Optional and basically every operation implicitly unwraps, instead of only the cases where nullability is actually desired.
• tcoff91 2y ago
  After the log4j vulnerability, I’d say that despite having good memory safety I would say the JVM’s powerful serialization primitives make me pretty leery of it as far as security goes.
  • MattPalmer1086 2y ago
    The log4j vulnerability was due to Java code, not in the JVM. But I get that people mostly conflate the two.
  • bruce343434 2y ago
    The log4j vulnerability happened because the log4j programmers made an overly generalized "do anything and everything" software. The kind of architecture that is made to be so generic that the software accidentally gains emergent properties (=not thought of/realized/considered execution paths and interactions). Although the desire to write software like that might have arisen under the influence of the object oriented mindset, I'm sure it could have happened in any other language.
  • aeonik 2y ago
    You can do the same thing in Rust as Log4J. I haven't tested this code, and definitely don't do this. This code is intended to lets attackers run any shell command by sending JSON with a "debug_command" field - similar to Log4J, it's a "feature" being misused rather than a memory bug that Rust would catch. ```rust use serde_json::Value; use std::process::Command; fn process_log_entry(log: &str) { // UNSAFE: Allows command injection if let Ok(json) = serde_json::from_str::<Value>(log) { if let Some(cmd) = json.get("debug_command") { Command::new("sh") .arg("-c") .arg(cmd.as_str().unwrap_or("")) .output() .unwrap(); } } } ```
    • d3nj4l 2y ago
      That's not the same thing. You can call a shell command from any language. The log4j problem was that you could load arbitrary classes from the internet into the memory of the current process, which is a much more severe problem.