5 ms·

`map()` makes Optional congruent with java Streams. Optionals are very frequently used with Streams, eg: someList.stream().map(Thing::foo).findFirst().map(

`map()` makes Optional congruent with java Streams. Optionals are very frequently used with Streams, eg: someList.stream().map(Thing::foo).findFirst().map(Other::bar)... And checked exceptions are a scourge. There's a reason post-Java languages like C#, Scala, and Kotlin abandoned them. Even lombok offers @SneakyThrows. The Java Optional<?> is pretty good as-is. The main improvement I'm make is that it needs to be Serializable. And woven into the core collection classes.

crummy 2y ago
Why do you want Optional to implement Serializable?
- Timwi 2y ago
  To make it able to be serialized?... Am I missing something?
  - evidencetamper 2y ago
    You don't need your optional to be serialized - it's just a container. You need what's inside your optional to be serialized.
  - crummy 2y ago
    Most of the serialization libraries I use (Jackson, gson) ignore the Serialization interface. I think it's only used for Java's now-rarely-used native serialization functionality.
  - lucumo 2y ago
    Only Java's built-in serialization still requires Serializable. And Java's built-in serialization is fundamentally vulnerable and should never be used. Newer libraries dropped the need for Serializable, because whether or not an object is serializable is not just dependent on its class, but also on the features the serialization library supports.
    - stickfigure 2y ago
      > Java's built-in serialization is fundamentally vulnerable and should never be used If you added "...for public APIs" then I would agree. But that represents only a tiny portion of the use cases for serializing objects. Java serialization excels at many of them.
      - lucumo 2y ago
        If you have FULL control over the serializing code and the serialized file during the entire time between serialization and deserialization, it can be safe. Put the file on the filesystem with incorrect permissions, transfer it over unencrypted HTTP, or do any number of things that allow others to mess with your data and you're screwed. Don't use it. It relies on the unsafe data to tell it what class to unmarshall to. If any class on your classpath does anything weird in its deserializing code, you've lost. Nowadays it's possible to filter the classes that can get deserialized, but: 1) there's still way too much Java 8 code around that doesn't have that filter; 2) those were the same JDK-wide until Java 17; and 3) worst of all, nobody uses them. Using Java serialization is like playing the knife game. You can win. But you'd better not make even a tiny mistake.
        stickfigure 2y ago
        This is dumb. If you're using it for internal RPC, or putting it in a message queue, or putting it in memcache, etc etc then you control both sides. A huge amount of business processing works like this. It's totally fine. Not every protocol needs to be designed for the REST use case. We have REST (and gRPC, and thrift, and avro, and many other protocols) for that. Use the correct tools for the job and stop the FUD.
        lucumo 2y ago
        Defense in depth is a thing. Trusting the message queue to be the only security barrier into your system is not great. Wouldn't be the first time one of those gets misconfigured. When that happens, using Java serialization leaves your system open in a way that other serialization libraries just don't.
- stickfigure 2y ago
  Literally to make it able to be serialized by Java. There are many legitimate applications for Java serialization which do not suffer security concerns. You should never expose serialization for public APIs but that leaves private APIs and private storage systems (think message queues, disk caches, internal RPC, etc). For private serialization, Java serialization has many advantages over something like JSON. You can serialize object graphs without concern for cycles. The contract is simple (it serializes fields, as opposed to dealing with weird bean naming conventions). It handles types and structures automatically. `transient` is built into the language. Polymorphism just works. We use it heavily for ephemeral storage. It's great.

crummy 2y ago

Why do you want Optional to implement Serializable?

Timwi 2y ago
To make it able to be serialized?... Am I missing something?
- evidencetamper 2y ago
  You don't need your optional to be serialized - it's just a container. You need what's inside your optional to be serialized.
- crummy 2y ago
  Most of the serialization libraries I use (Jackson, gson) ignore the Serialization interface. I think it's only used for Java's now-rarely-used native serialization functionality.
- lucumo 2y ago
  Only Java's built-in serialization still requires Serializable. And Java's built-in serialization is fundamentally vulnerable and should never be used. Newer libraries dropped the need for Serializable, because whether or not an object is serializable is not just dependent on its class, but also on the features the serialization library supports.
  - stickfigure 2y ago
    > Java's built-in serialization is fundamentally vulnerable and should never be used If you added "...for public APIs" then I would agree. But that represents only a tiny portion of the use cases for serializing objects. Java serialization excels at many of them.
    - lucumo 2y ago
      If you have FULL control over the serializing code and the serialized file during the entire time between serialization and deserialization, it can be safe. Put the file on the filesystem with incorrect permissions, transfer it over unencrypted HTTP, or do any number of things that allow others to mess with your data and you're screwed. Don't use it. It relies on the unsafe data to tell it what class to unmarshall to. If any class on your classpath does anything weird in its deserializing code, you've lost. Nowadays it's possible to filter the classes that can get deserialized, but: 1) there's still way too much Java 8 code around that doesn't have that filter; 2) those were the same JDK-wide until Java 17; and 3) worst of all, nobody uses them. Using Java serialization is like playing the knife game. You can win. But you'd better not make even a tiny mistake.
      - stickfigure 2y ago
        This is dumb. If you're using it for internal RPC, or putting it in a message queue, or putting it in memcache, etc etc then you control both sides. A huge amount of business processing works like this. It's totally fine. Not every protocol needs to be designed for the REST use case. We have REST (and gRPC, and thrift, and avro, and many other protocols) for that. Use the correct tools for the job and stop the FUD.
        lucumo 2y ago
        Defense in depth is a thing. Trusting the message queue to be the only security barrier into your system is not great. Wouldn't be the first time one of those gets misconfigured. When that happens, using Java serialization leaves your system open in a way that other serialization libraries just don't.
stickfigure 2y ago
Literally to make it able to be serialized by Java. There are many legitimate applications for Java serialization which do not suffer security concerns. You should never expose serialization for public APIs but that leaves private APIs and private storage systems (think message queues, disk caches, internal RPC, etc). For private serialization, Java serialization has many advantages over something like JSON. You can serialize object graphs without concern for cycles. The contract is simple (it serializes fields, as opposed to dealing with weird bean naming conventions). It handles types and structures automatically. `transient` is built into the language. Polymorphism just works. We use it heavily for ephemeral storage. It's great.