4 ms·

My problem with Optional<T> is that it basically makes overloaded Java methods impossible because of erasure. I'm worried that it is going to start getting over

My problem with Optional<T> is that it basically makes overloaded Java methods impossible because of erasure. I'm worried that it is going to start getting overused; the JDK developers really only intended for its use in the Streams API.

tel 12y ago
Could you explain that a little bit more? I'm using to Maybe from Haskell and am curious what might be missing from Java's Optional.
- deleted 12y ago
  [deleted]
- matwood 12y ago
  Basically, because of type erasure you cannot have overloaded methods using different Optional types. So test(Optional<A> a); is the same method as test(Optional<B> b); I think you can define the types to get around it, but that is messy and a PITA. For example, class OptionalA extends Optional<A>.
  - dignati 12y ago
    Wow that's a real pain point. Why would they even do that, is there a use case?
    - ZoFreX 12y ago
      Backward compatibility - you could run an application that uses generics, introduced in Java 1.5, on a Java 1.4 VM. At the time that was pretty amazing. These days, with so many backward compatibility-breaking changes being introduced, it doesn't feel so great.
      - deleted 12y ago
        [deleted]
      - mcculley 12y ago
        That was the original plan, but it never worked in my experience. The compiler as shipped required that -source 1.5 use -target 1.5. So hobbling the language this way served no benefit in the end.
    - im3w1l 12y ago
      In my opinion, no it really isn't. You can just create a method with a different name or a static constructing method if you need to overload constructors. The major pain point with generics is that they don't work with primitives.
    - tomp 12y ago
      Btw, type erasure is only a problem for Java because it supports runtime type information (which is incomplete, because of type erasure), and overloading (which I have no idea why the compiler can't handle). For languages like ML and Haskell, type erasure is no problem, because you can't access the types at runtime anyways.
  - tel 12y ago
    That doesn't seem so bad to my eye, though. In Haskell terms it just means that any overloaded operators on Optional have to respect parametricity. If you need something more specifically typed then you can just use a new name. Is there a particular use case?
- deleted 12y ago
  [deleted]
- im3w1l 12y ago
  Because of type erasure, all Optional<T> are the same type at runtime, so Optional<Integer> can't be overloaded with Optional<Boolean>, because at runtime it will be impossible to tell which method should be caled.
rat87 12y ago
I was wondering why Optional support which I was so interested in seemed so quickly inserted/poorly thought out. There's no equivalent of scala's orElse(returning a second optional if the first one is null) and since default methods while useful don't allow adding things to types you don't own you can't use an method like notation for the best you can get is static importing and wrapping a function around it). ofNullable(creating an empty Optional from a null instead of throwing) isn't the default(of which throws is). Also Optional isn't an Iterator which is disappointing since using it with a for loop can be useful if you want to avoid nested closures. But worst of all it's like they haven't started slowly deprecating most of the standard library(anything that makes sense to pass null to or that it makes sense to return null in some cases according to the api. Option types are arguably the best solution for the null problem at least for statically typed languages but having null still be possible while having Option is arguably the worst of both worlds, in my understanding scala deals with this by almost never using Null except for java compatibility and tries to create Options as soon as possible if calling a java function that may return null. Basically I think they need to make some sort of standard Nullable and NotNullable annotations, add it to everything in the std library, and have some sort of package annotation that tells the ides to check every call to a Nullable and bug you to wrap it in Optional.ofNullable. Then deprecate those methods with Nullables by java 10 or 11 with strong warnings for ths who call them(or possible forcing a special compiler flag/package annotation to use them). Even not doing that they are still adding methods that return null(such as Hashtable::computeIfAbsent) instead of Optional. Why for fcks sake?
deleted 12y ago
[deleted]
rat87 12y ago
I was wondering why Optional support which I was so interested in seemed so quickly inserted/poorly thought out. There's no equivalent of scala's orElse(returning a second optional if the first one is null) and since default methods while useful don't allow adding things to types you don't own you can't use an method like notation for the best you can get is static importing and wrapping a function around it). ofNullable(creating an empty Optional from a null instead of throwing) isn't the default(of which throws is). Also Optional isn't an Iterator which is disappointing since using it with a for loop can be useful if you want to avoid nested closures. But worst of all it's like they haven't started slowly deprecating most of the standard library(anything that makes sense to pass null to or that it makes sense to return null in some cases according to the api. Option types are arguably the best solution for the null problem at least for statically typed languages but having null still be possible while having Option is arguably the worst of both worlds, in my understanding scala deals with this by almost never using Null except for java compatibility and tries to create Options as soon as possible if calling a java function that may return null. Basically I think they need to make some sort of standard Nullable and NotNullable annotations, add it to everything in the std library, and have some sort of package annotation that tells the ides to check every call to a Nullable and bug you to wrap it in Optional.ofNullable. Then deprecate those methods with Nullables by java 10 or 11 with strong warnings for ths who call them(or possible forcing a special compiler flag/package annotation to use them). Even not doing that they are still adding methods that return null(such as Hashtable::computeIfAbsent) instead of Optional. Why for f@@cks sake?

tel 12y ago

Could you explain that a little bit more? I'm using to Maybe from Haskell and am curious what might be missing from Java's Optional.

deleted 12y ago
[deleted]
matwood 12y ago
Basically, because of type erasure you cannot have overloaded methods using different Optional types. So test(Optional<A> a); is the same method as test(Optional<B> b); I think you can define the types to get around it, but that is messy and a PITA. For example, class OptionalA extends Optional<A>.
- dignati 12y ago
  Wow that's a real pain point. Why would they even do that, is there a use case?
  - ZoFreX 12y ago
    Backward compatibility - you could run an application that uses generics, introduced in Java 1.5, on a Java 1.4 VM. At the time that was pretty amazing. These days, with so many backward compatibility-breaking changes being introduced, it doesn't feel so great.
    - deleted 12y ago
      [deleted]
    - mcculley 12y ago
      That was the original plan, but it never worked in my experience. The compiler as shipped required that -source 1.5 use -target 1.5. So hobbling the language this way served no benefit in the end.
  - im3w1l 12y ago
    In my opinion, no it really isn't. You can just create a method with a different name or a static constructing method if you need to overload constructors. The major pain point with generics is that they don't work with primitives.
  - tomp 12y ago
    Btw, type erasure is only a problem for Java because it supports runtime type information (which is incomplete, because of type erasure), and overloading (which I have no idea why the compiler can't handle). For languages like ML and Haskell, type erasure is no problem, because you can't access the types at runtime anyways.
- tel 12y ago
  That doesn't seem so bad to my eye, though. In Haskell terms it just means that any overloaded operators on Optional have to respect parametricity. If you need something more specifically typed then you can just use a new name. Is there a particular use case?
deleted 12y ago
[deleted]
im3w1l 12y ago
Because of type erasure, all Optional<T> are the same type at runtime, so Optional<Integer> can't be overloaded with Optional<Boolean>, because at runtime it will be impossible to tell which method should be caled.

rat87 12y ago

I was wondering why Optional support which I was so interested in seemed so quickly inserted/poorly thought out. There's no equivalent of scala's orElse(returning a second optional if the first one is null) and since default methods while useful don't allow adding things to types you don't own you can't use an method like notation for the best you can get is static importing and wrapping a function around it). ofNullable(creating an empty Optional from a null instead of throwing) isn't the default(of which throws is). Also Optional isn't an Iterator which is disappointing since using it with a for loop can be useful if you want to avoid nested closures. But worst of all it's like they haven't started slowly deprecating most of the standard library(anything that makes sense to pass null to or that it makes sense to return null in some cases according to the api. Option types are arguably the best solution for the null problem at least for statically typed languages but having null still be possible while having Option is arguably the worst of both worlds, in my understanding scala deals with this by almost never using Null except for java compatibility and tries to create Options as soon as possible if calling a java function that may return null. Basically I think they need to make some sort of standard Nullable and NotNullable annotations, add it to everything in the std library, and have some sort of package annotation that tells the ides to check every call to a Nullable and bug you to wrap it in Optional.ofNullable. Then deprecate those methods with Nullables by java 10 or 11 with strong warnings for ths who call them(or possible forcing a special compiler flag/package annotation to use them). Even not doing that they are still adding methods that return null(such as Hashtable::computeIfAbsent) instead of Optional. Why for fcks sake?

deleted 12y ago

[deleted]

rat87 12y ago