6 ms·

I don't think this is going to happen with Brian Goetz as language architect. He refuses to add many features that would address everyday pain points such as:

I don't think this is going to happen with Brian Goetz as language architect. He refuses to add many features that would address everyday pain points such as: * null safe navigation operator * properties * mutable records * a way to ignore checked exceptions (or at least having the stream API take functional interfaces that can throw exceptions) * adding functional methods like .filter()/.map() directly to collections instead of having to .stream().map(..).collect(toList())

nikeee 5y ago
IMHO safe navigation only makes sense when the compiler is able to reason about nullability, meaning nullability is rooted in the type system. That's the case for Kotlin and not for Java. Otherwise, you've got a high risk of developers inserting a ? to fix a bug, which only fixes the symptoms. As of now, Optional#map seems to be the way to go.
bestinterest 5y ago
Is that true though? nullability is a area I've heard /u/pron mention may be tackled in the future, mutable records seem like they will be tackled with the 'withers' concept in the future. Checked exceptions + changing the sugar of .stream().map I don't see ever changing. Properties I am unsure of.
- cogman10 5y ago
  AFAIK, the fate of nullability is tied pretty directly to Valhalla. It's constantly being brought up there.
- laurent92 5y ago
  Why should it be in the future. The syntax of .stream() has been awfully verbose since Java 8: in the middle of “.stream()….collect(toList())”, you need to squint to find the actual function name being applied between the flood of polluting calls, which loses the appeal of functional programming. In my company we have f(list).map(…), which is a wrapper for the streams. But newcomers don’t like it because it’s not the standard.
krzyk 5y ago
He does not refuse, but needs to look at bigger picture. Some features are low hanging fruit, some are proposed small changes that actually should be defined a bit differently to be better and they will take more effort. But even small hanging fruits means that they need to chose which ones to do. Should they delay pattern matching by 6 months to get elvis operator? I wouldn't like it, pattern matching is more important. Basically they have limited resources and have to chose what to work on.
pron 5y ago
Thank god for that, because those feature are either horrible on their own or superseded by better ones. You're getting a car and complaining for not getting faster horses. The features Java has adopted -- specifically, algebraic data types and pattern-matching -- will lead to better development practices, rather than making it easier to work with inferior ones.
- xpressvideoz 5y ago
  I can understand the hate behind null-safe operators, but why properties? Why is bad to have an ability to "upgrade" a member variable into a property, without breaking any existing contracts? I really hate that I need to resort to using setters and getters in Java because those are bad for searchability.
  - pron 5y ago
    Properties are probably the worst feature on that list, and no experienced language designer would add them to Java. They make it easier to work with setters, while the goal is to reduce their usage altogether! Records achieve that much better. Unencapsulated component access is standardised on classes with good contracts (construction and deconstruction are duals for records) and will work well with patterns, all while avoiding unnecessary mutation for such classes (instead, we'll have "withers" or "reconstructors": https://github.com/openjdk/amber-docs/blob/master/eg-drafts/reconstruction-records-and-classes.md https://github.com/openjdk/amber-docs/blob/master/eg-drafts/...). So we're killing two birds with one stone: making it easier to work with "simple data" while also reducing reliance on getters and setters. On the other hand, C# finds itself needing to add more and more capabilities to this feature, while Java dodged that bullet.
    - xpressvideoz 5y ago
      Thanks for the thorough explanation. Now I understand where Java is heading for. The aesthetics regarding withers concerns me a bit though, because I don't like prepending anything to the name of an acceessor (a transformer, in this case?), which was why I liked the idea of properties in the first place. I hope both Java and Kotlin can converge into a common coding style. As you said regarding C#, Kotlin's emphasis on properties makes it easier to use getters and setters and thus may hinder getting rid of them in the Java ecosystem. I'm not sure if I should support Kotlin's success at this point.
oftenwrong 5y ago
Stream has been given a `toList()` convenience method: https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/stream/Stream.html#toList https://docs.oracle.com/en/java/javase/17/docs/api/java.base...()
throwaway2037 5y ago
Re: Properties: What is the gain? What is the "pain point"? More typing? Can you share a language where you feel properties is a significant gain? (C#?) Re: Streams API that allows checked exceptions. Brian Goetz has written about this issue. (Search StackOverflow.com) They did not allow because of the optionally parallel (threaded) nature of streams. If multiple parallel streams throw an exception, when/when/where/how are the exceptions re-thrown? Moving exceptions across thread boundaries is a tricky thing in any language. If you don't care about parallel streams, there are many open source projects that effective create a nearly identical Streams API but allow throws Exception everywhere. Are these open source solutions insufficient for your needs? Re: adding functional methods like... Is there an advantage other than typing nine less characters?
- int_19h 5y ago
  > Moving exceptions across thread boundaries is a tricky thing in any language. Not really. C++ has std::exception_ptr for that exact reason, and C# has ExceptionDispatchInfo. Both are very straightforward - you catch the exception, get a handle for it, and then re-throw that handle in another context, with original stack trace preserved. Multiple concurrent exceptions is also a solved problem. In C#, if you do something like Task.WhenAll(), and one or more task throws, you get back an AggregateException, which can be inspected to see which task threw what. The same can be applied to async streams.

nikeee 5y ago

IMHO safe navigation only makes sense when the compiler is able to reason about nullability, meaning nullability is rooted in the type system. That's the case for Kotlin and not for Java. Otherwise, you've got a high risk of developers inserting a ? to fix a bug, which only fixes the symptoms. As of now, Optional#map seems to be the way to go.

bestinterest 5y ago

Is that true though? nullability is a area I've heard /u/pron mention may be tackled in the future, mutable records seem like they will be tackled with the 'withers' concept in the future. Checked exceptions + changing the sugar of .stream().map I don't see ever changing. Properties I am unsure of.

cogman10 5y ago
AFAIK, the fate of nullability is tied pretty directly to Valhalla. It's constantly being brought up there.
laurent92 5y ago
Why should it be in the future. The syntax of .stream() has been awfully verbose since Java 8: in the middle of “.stream()….collect(toList())”, you need to squint to find the actual function name being applied between the flood of polluting calls, which loses the appeal of functional programming. In my company we have f(list).map(…), which is a wrapper for the streams. But newcomers don’t like it because it’s not the standard.

krzyk 5y ago

He does not refuse, but needs to look at bigger picture. Some features are low hanging fruit, some are proposed small changes that actually should be defined a bit differently to be better and they will take more effort. But even small hanging fruits means that they need to chose which ones to do. Should they delay pattern matching by 6 months to get elvis operator? I wouldn't like it, pattern matching is more important. Basically they have limited resources and have to chose what to work on.

pron 5y ago

Thank god for that, because those feature are either horrible on their own or superseded by better ones. You're getting a car and complaining for not getting faster horses. The features Java has adopted -- specifically, algebraic data types and pattern-matching -- will lead to better development practices, rather than making it easier to work with inferior ones.

xpressvideoz 5y ago
I can understand the hate behind null-safe operators, but why properties? Why is bad to have an ability to "upgrade" a member variable into a property, without breaking any existing contracts? I really hate that I need to resort to using setters and getters in Java because those are bad for searchability.
- pron 5y ago
  Properties are probably the worst feature on that list, and no experienced language designer would add them to Java. They make it easier to work with setters, while the goal is to reduce their usage altogether! Records achieve that much better. Unencapsulated component access is standardised on classes with good contracts (construction and deconstruction are duals for records) and will work well with patterns, all while avoiding unnecessary mutation for such classes (instead, we'll have "withers" or "reconstructors": https://github.com/openjdk/amber-docs/blob/master/eg-drafts/reconstruction-records-and-classes.md https://github.com/openjdk/amber-docs/blob/master/eg-drafts/...). So we're killing two birds with one stone: making it easier to work with "simple data" while also reducing reliance on getters and setters. On the other hand, C# finds itself needing to add more and more capabilities to this feature, while Java dodged that bullet.
  - xpressvideoz 5y ago
    Thanks for the thorough explanation. Now I understand where Java is heading for. The aesthetics regarding withers concerns me a bit though, because I don't like prepending anything to the name of an acceessor (a transformer, in this case?), which was why I liked the idea of properties in the first place. I hope both Java and Kotlin can converge into a common coding style. As you said regarding C#, Kotlin's emphasis on properties makes it easier to use getters and setters and thus may hinder getting rid of them in the Java ecosystem. I'm not sure if I should support Kotlin's success at this point.

oftenwrong 5y ago

Stream has been given a `toList()` convenience method: https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/stream/Stream.html#toList https://docs.oracle.com/en/java/javase/17/docs/api/java.base...()

throwaway2037 5y ago

Re: Properties: What is the gain? What is the "pain point"? More typing? Can you share a language where you feel properties is a significant gain? (C#?) Re: Streams API that allows checked exceptions. Brian Goetz has written about this issue. (Search StackOverflow.com) They did not allow because of the optionally parallel (threaded) nature of streams. If multiple parallel streams throw an exception, when/when/where/how are the exceptions re-thrown? Moving exceptions across thread boundaries is a tricky thing in any language. If you don't care about parallel streams, there are many open source projects that effective create a nearly identical Streams API but allow throws Exception everywhere. Are these open source solutions insufficient for your needs? Re: adding functional methods like... Is there an advantage other than typing nine less characters?

int_19h 5y ago
> Moving exceptions across thread boundaries is a tricky thing in any language. Not really. C++ has std::exception_ptr for that exact reason, and C# has ExceptionDispatchInfo. Both are very straightforward - you catch the exception, get a handle for it, and then re-throw that handle in another context, with original stack trace preserved. Multiple concurrent exceptions is also a solved problem. In C#, if you do something like Task.WhenAll(), and one or more task throws, you get back an AggregateException, which can be inspected to see which task threw what. The same can be applied to async streams.