6 ms·

One of the primary features I'm holding out hope for eventually making it into the language is ValueTypes: http://cr.openjdk.java.net/~jrose/values/values-0.htm

One of the primary features I'm holding out hope for eventually making it into the language is ValueTypes: http://cr.openjdk.java.net/~jrose/values/values-0.html http://cr.openjdk.java.net/~jrose/values/values-0.html and the current Valhalla Project: https://wiki.openjdk.java.net/display/valhalla/Main https://wiki.openjdk.java.net/display/valhalla/Main The simplest example of why this would be valuable (edit: this was not an intentional pun), the Optional type could become stack based, such that you could ensure that the variable referring to the Optional type is never null. This would help reduce a common class of bugs in Java code stemming from NPE's.

voidfunc 6y ago
You don't really need to hold out hope for this... it is coming and soon. It's been in active progress for years now (its a huge undertaking).
- bluejekyll 6y ago
  Is there an update somewhere that I've missed? I keep looking for updates and haven't seen them. (And yes, I know it's a huge effort, I was definitely not trying to say that it should be an easy change to get into the language)
  - craigacp 6y ago
    There are JEPs out for parts of it now - Primitive Objects (which is the new name for value types) https://openjdk.java.net/jeps/401 https://openjdk.java.net/jeps/401 and Unify the basic primitives with objects https://openjdk.java.net/jeps/402 https://openjdk.java.net/jeps/402
    - Yeroc 6y ago
      I haven't read up on the details of these but this is a huge step in the right direction if pulled off properly. The dichotomy between primitive and non-primitive types in Java is a real rough spot. I'd have to see how they deal with null values though because the introduction of auto-boxing certainly introduced a new area for NullPointerExceptions to catch the unwary off-guard.
      - craigacp 6y ago
        There is extensive discussion of that topic in the valhalla-dev and valhalla-spec-experts mailing lists, but I think the details are still being worked out.
- coldtea 6y ago
  >It's been in active progress for years now And it might be in "active progress" for years more, seeing that we were promised it would come a decade ago.
  - isbvhodnvemrwvn 6y ago
    I recall someone in /r/java saying that I should stick with Java for the new project because project loom is just around the corner. The system has been in production for 3 or 4 years by now.
nlitened 6y ago
I am not sure I understand, why would you want Optional type to never be null? Isn't it being null sometimes — the whole point?
- wffurr 6y ago
  There's a big difference between the Optional containing null (useful) and the Optional itself being null (but why).
- wtetzner 6y ago
  Say you have: public void doSomething(Optional<String> foo) { ... } You want `foo` to be `Optional.empty()` or `Optional.of("some string")`. The way things currently work, `foo` could also be `null`.
  - nitrogen 6y ago
    Kotlin's approach of making null act kind of like Optional is pretty nice, but I wish there was a strict option for interacting with Java types -- by default, all Java-native types (type names ending with !) can be null and are not null checked at compile time.
    - Larrikin 6y ago
      In our code base we just throw a `?:` after any type that shows up as Type! and handle it immediately. If you actually expect a null value you can also use `?: null`
  - savanu 6y ago
    How does making Optionals allocated on the stack (value types) prevent this? Or rather why do you need value types to accomplish this?
    - bluejekyll 6y ago
      Perhaps this example will make it more obvious: boolean truthy = false; truthy = null; // compilation failure, type mismatch vs. the Boolean type Boolean truthy = new Boolean(false); truthy = null; // compiles just fine The reason Boolean (and other boxed primitive types) exist is because it is an Object (a reference type) and that allows them to be used in things like collections that expect Objects and not primitive types. Looking at https://openjdk.java.net/jeps/401 https://openjdk.java.net/jeps/401 it's not totally clear to me at the moment how you can use ValueTypes (primitive keyword) in Collections. Might be that you'll need to take a reference to them with Type.ref (but I need to read 401 in more detail to understand that). Hope that helps.
layer8 6y ago
Even more useful will be a Mandatory<T> type. Maybe with “T!” and implicit conversion to T as syntactic sugar. Edit: Unfortunately it would have the drawback of nonoverloadability due to type erasure.
halfmatthalfcat 6y ago
Or use Scala :)
- kaba0 6y ago
  Which doesn’t have value types because it should be implemented in the JVM?
  - halfmatthalfcat 6y ago
    It has Value Classes which are essentially the same thing. They transpile down into the value itself but wrap the value in extra functionality if you so choose.
    - kaba0 6y ago
      They can only wrap a single primitive type - it’s a nice feature but nothing extraordinary. When Java implements primitive types, Scala will probably use this same construct. But the change have to come from the runtime level.
- chrisseaton 6y ago
  Does Scala have value types?
  - halfmatthalfcat 6y ago
    https://docs.scala-lang.org/sips/value-classes.html https://docs.scala-lang.org/sips/value-classes.html
    - chrisseaton 6y ago
      Ah right - that's not really what we're talking about here, even though they have the same name.
      - halfmatthalfcat 6y ago
thu2111 6y ago
I'm looking forward to Valhalla too, but I think it won't be as impactful as people think. In particular that use case is a poor fit for Valhalla and I don't think Optional will be widely adopted even post-value types. The intent here is to mark which parameters and return types can be null. A laudable goal. However: 1. You will still be using many, many libraries that pre-date cheap Optional. For those, the lack of Optional will NOT indicate the value is always present, it will mean "no optionality information available". Therefore by looking at an API you can't actually tell what the lack of Optional means: it could be deliberate, or it could be legacy. This will make the signal useless. 2. Optional is a very verbose, heavyweight syntax for handling optionality. Therefore some developers will not use it on the grounds that Java is already a very verbose language and it really doesn't need more. This will cause further divergence. 3. Many developers will want to preserve compatibility with old JVMs. Even though Optional is around a long time now, guaranteed cheap/fast Optional will take a long time to roll out and may never make it to Android at all. This will cause some library developers writing high performance code to shun it because null is as cheap as you can possibly get, and universally supported. Again, the lack of Optional will be meaningless. 4. The killer blow: adding Optional changes your function signatures and therefore breaks both binary and source compatibility. Many library developers want to keep a backwards compatible API, or are required to, and that includes for example the Java standard libraries. Therefore lack of Optional will NEVER mean "guaranteed to be present" in most Java code because the standard library won't use it that way. There is a far, far better way to handle this and it's what Kotlin did: 1. Integrate optionality into the language using lightweight syntax and type inference. 2. Use non-denotable flex-types at the edges, so missing optionality information is added transparently in the source code the first time a developer specifies a type explicitly. 3. Allow annotations to provide nullability information, preserving source and binary compatibility. Integrate it with IDE and compiler data flow analysis. IntelliJ already does this and you can make nullability violations hard errors today by adjusting your project preferences. 4. Finally, allow third party libraries that aren't being changed to be annotated using external annotation files.

voidfunc 6y ago

You don't really need to hold out hope for this... it is coming and soon. It's been in active progress for years now (its a huge undertaking).

bluejekyll 6y ago
Is there an update somewhere that I've missed? I keep looking for updates and haven't seen them. (And yes, I know it's a huge effort, I was definitely not trying to say that it should be an easy change to get into the language)
- craigacp 6y ago
  There are JEPs out for parts of it now - Primitive Objects (which is the new name for value types) https://openjdk.java.net/jeps/401 https://openjdk.java.net/jeps/401 and Unify the basic primitives with objects https://openjdk.java.net/jeps/402 https://openjdk.java.net/jeps/402
  - Yeroc 6y ago
    I haven't read up on the details of these but this is a huge step in the right direction if pulled off properly. The dichotomy between primitive and non-primitive types in Java is a real rough spot. I'd have to see how they deal with null values though because the introduction of auto-boxing certainly introduced a new area for NullPointerExceptions to catch the unwary off-guard.
    - craigacp 6y ago
      There is extensive discussion of that topic in the valhalla-dev and valhalla-spec-experts mailing lists, but I think the details are still being worked out.
coldtea 6y ago
>It's been in active progress for years now And it might be in "active progress" for years more, seeing that we were promised it would come a decade ago.
- isbvhodnvemrwvn 6y ago
  I recall someone in /r/java saying that I should stick with Java for the new project because project loom is just around the corner. The system has been in production for 3 or 4 years by now.

nlitened 6y ago

I am not sure I understand, why would you want Optional type to never be null? Isn't it being null sometimes — the whole point?

wffurr 6y ago
There's a big difference between the Optional containing null (useful) and the Optional itself being null (but why).
wtetzner 6y ago
Say you have: public void doSomething(Optional<String> foo) { ... } You want `foo` to be `Optional.empty()` or `Optional.of("some string")`. The way things currently work, `foo` could also be `null`.
- nitrogen 6y ago
  Kotlin's approach of making null act kind of like Optional is pretty nice, but I wish there was a strict option for interacting with Java types -- by default, all Java-native types (type names ending with !) can be null and are not null checked at compile time.
  - Larrikin 6y ago
    In our code base we just throw a `?:` after any type that shows up as Type! and handle it immediately. If you actually expect a null value you can also use `?: null`
- savanu 6y ago
  How does making Optionals allocated on the stack (value types) prevent this? Or rather why do you need value types to accomplish this?
  - bluejekyll 6y ago
    Perhaps this example will make it more obvious: boolean truthy = false; truthy = null; // compilation failure, type mismatch vs. the Boolean type Boolean truthy = new Boolean(false); truthy = null; // compiles just fine The reason Boolean (and other boxed primitive types) exist is because it is an Object (a reference type) and that allows them to be used in things like collections that expect Objects and not primitive types. Looking at https://openjdk.java.net/jeps/401 https://openjdk.java.net/jeps/401 it's not totally clear to me at the moment how you can use ValueTypes (primitive keyword) in Collections. Might be that you'll need to take a reference to them with Type.ref (but I need to read 401 in more detail to understand that). Hope that helps.

layer8 6y ago

Even more useful will be a Mandatory<T> type. Maybe with “T!” and implicit conversion to T as syntactic sugar. Edit: Unfortunately it would have the drawback of nonoverloadability due to type erasure.

halfmatthalfcat 6y ago

Or use Scala :)

kaba0 6y ago
Which doesn’t have value types because it should be implemented in the JVM?
- halfmatthalfcat 6y ago
  It has Value Classes which are essentially the same thing. They transpile down into the value itself but wrap the value in extra functionality if you so choose.
  - kaba0 6y ago
    They can only wrap a single primitive type - it’s a nice feature but nothing extraordinary. When Java implements primitive types, Scala will probably use this same construct. But the change have to come from the runtime level.
chrisseaton 6y ago
Does Scala have value types?
- halfmatthalfcat 6y ago
  https://docs.scala-lang.org/sips/value-classes.html https://docs.scala-lang.org/sips/value-classes.html
  - chrisseaton 6y ago
    Ah right - that's not really what we're talking about here, even though they have the same name.
    - halfmatthalfcat 6y ago

thu2111 6y ago

I'm looking forward to Valhalla too, but I think it won't be as impactful as people think. In particular that use case is a poor fit for Valhalla and I don't think Optional will be widely adopted even post-value types. The intent here is to mark which parameters and return types can be null. A laudable goal. However: 1. You will still be using many, many libraries that pre-date cheap Optional. For those, the lack of Optional will NOT indicate the value is always present, it will mean "no optionality information available". Therefore by looking at an API you can't actually tell what the lack of Optional means: it could be deliberate, or it could be legacy. This will make the signal useless. 2. Optional is a very verbose, heavyweight syntax for handling optionality. Therefore some developers will not use it on the grounds that Java is already a very verbose language and it really doesn't need more. This will cause further divergence. 3. Many developers will want to preserve compatibility with old JVMs. Even though Optional is around a long time now, guaranteed cheap/fast Optional will take a long time to roll out and may never make it to Android at all. This will cause some library developers writing high performance code to shun it because null is as cheap as you can possibly get, and universally supported. Again, the lack of Optional will be meaningless. 4. The killer blow: adding Optional changes your function signatures and therefore breaks both binary and source compatibility. Many library developers want to keep a backwards compatible API, or are required to, and that includes for example the Java standard libraries. Therefore lack of Optional will NEVER mean "guaranteed to be present" in most Java code because the standard library won't use it that way. There is a far, far better way to handle this and it's what Kotlin did: 1. Integrate optionality into the language using lightweight syntax and type inference. 2. Use non-denotable flex-types at the edges, so missing optionality information is added transparently in the source code the first time a developer specifies a type explicitly. 3. Allow annotations to provide nullability information, preserving source and binary compatibility. Integrate it with IDE and compiler data flow analysis. IntelliJ already does this and you can make nullability violations hard errors today by adjusting your project preferences. 4. Finally, allow third party libraries that aren't being changed to be annotated using external annotation files.