10 ms·

Java finally gets what's been available in Scala (case classes), C# (structs or maybe properties), Kotlin (data classes) and others for a very long time .. so l

Java finally gets what's been available in Scala (case classes), C# (structs or maybe properties), Kotlin (data classes) and others for a very long time .. so long we already have tools like Immutables and Lombok to get past this really dumb limitation in Java. I was really surprised to learn that the Java compiler/VM, when it sees the patterns "somevar" and functions "getSomeVar" and "setSomeVar" doing purely getter/setter stuff, removes the actual function calls and silently changes them in the background to field lookups for speed. If you attach a debugger or memory profiler, is changes them back to functions and slows them down. I'm not sure if this is still true; saw an example of this at a meetup back in the Java 8 days.

apta 7y ago
> C# (structs or maybe properties) Those are not directly analogous to records. As a matter of fact, C# is getting records as well: https://blog.cdemi.io/whats-coming-in-c-8-0-records/ https://blog.cdemi.io/whats-coming-in-c-8-0-records/
- statictype 7y ago
  This looks like syntactic sugar for comcepts that already exist? I think in Java’s case, its only mow getting struct-like semantics edit I may be wrong. It could be a purely syntax level feature in Java as well.
  - paulddraper 7y ago
    Java records are syntax sugar. Value semantics are proposed in JEP 169 [1] and are part of Project Valhalla. [2] [1] https://openjdk.java.net/jeps/169 https://openjdk.java.net/jeps/169 [2] https://wiki.openjdk.java.net/display/valhalla/Main https://wiki.openjdk.java.net/display/valhalla/Main
- to11mtm 7y ago
  C# has had records slated for years without delivery, alas. Thankfully we do finally have a version in testing. In any case to answer GP, structs should not be considered a valid substitute for records, they are 'value types' so passing them around means you copy all the data every time you pass (i.e. lots of allocations if the record is larger than 1 or 2 fields) Properties get you 'closer'. You can do some code Which is a good bit less than Java by default (i.e. not Lombok or similar) F# does have Records, and technically there's nothing stopping you from declaring your records in F# and importing them into C#... but that may not be ideal. I don't think you get the full benefits (like copying a record with specific properties changed)
crystaldev 7y ago
In Java years, Kotlin hasn't had anything for a "long time," the language itself is still a baby. Most Java shops are still living in the "Java 8 days."
lennydizzy 7y ago
C# struct is a value type, the Java Record is not a value type, right?
- pjmlp 7y ago
  Right, inline classes are the value types (as part of Valhalla).
pron 7y ago
> Java finally gets what's been available in ... and others for a very long time You seem to think that the goal is to get as many features as possible, as quickly as possible. Maybe some languages have that goal, but Java's design philosophy -- from its inception [1] -- has been to be a conservative language that only adopts features that have become familiar to programmers and stood the test of time in providing a good cost/benefit. Java hasn't always done this, but that's the aspiration. Worked out pretty well, I think. Given Java's design philosophy, the far more interesting question is which features of those more adventurous languages Java does not intend to adopt. > Java compiler/VM, when it sees the patterns "somevar" and functions "getSomeVar" and "setSomeVar" doing purely getter/setter stuff, removes the actual function calls and silently changes them in the background to field lookups for speed. If you attach a debugger or memory profiler, is changes them back to functions and slows them down. It's true, and the optimizing JIT compiler does much more than just that. It performs deep speculative optimizations, like inlining virtual calls and removing untaken branches, reverting them (using a process called deoptimization) either for debugging or when it detects its assumptions are false. What you're referring to is just an instance of inlining. [1]: https://www.win.tue.nl/~evink/education/avp/pdf/feel-of-java.pdf https://www.win.tue.nl/~evink/education/avp/pdf/feel-of-java...
- tomcam 7y ago
  > deep speculative optimizations my new blog title
- Cladode 7y ago
  Worked out pretty well, I think. Au contraire mon ami! ML was better than most of its successors, including Java, which held programming back. Milner's ML avoided some of Java's glaring mistakes (e.g. exception specifications, lack of generics, non-uniform treatment of types, lack of higher-order functions, lack of pattern matching) from the start. Xavier Leroy showed how efficiently to compile ML in the 1990s. The main thing ML lacked (w.r.t sequential computing), was a good integration with OO and HKTs. That was solved by Scala.
  - pron 7y ago
dfox 7y ago
I believe that the JIT does not remove get/setFoo by matching the naming pattern, but simply because these methods are trivial and usually not polymorphic and thus prime candidates for speculative inlining.
anthonybsd 7y ago
>Java finally gets what's been available in Scala (case classes), C# (structs or maybe properties), Kotlin (data classes) and others for a very long time .. so long we already have tools like Immutables and Lombok to get past this really dumb limitation in Java. All the ones you named are fairly new languages, and C# does not have anything even remotely like records (structs are value types, and properties are fields) so what's your point? Java historically has been very conservative with implementing things because they usually try to get it right (generics non-withstanding). For that matter C# rushed into a few things too and screwed the pooch badly on them.
- nightski 7y ago
  I'd be curious which features you think C# messed up on. I have been using C# professionally since 2000 in it's first beta and can't think of a newer feature that would meet this criteria? That said you are correct about records. Although it is getting them also.
  - anthonybsd 7y ago
    The one that annoys me the most in C# on a day-to-day basis is Nullable<T>. Java took their time with Optional<T> but once it was released it was great. Can be used in lambdas, all libraries are modified and aware of it etc. C# Nullable<T> is near useless because it only works on value types. I.e., you know, the types that are least likely to generate NullReferenceException for you.
    - wvenable 7y ago
      In both C# and Java, reference types are nullable. Nullable<T> exists in C# to provide for nullable value types. It's not comparable to Optional<T> as that's an entirely different feature.
      - anthonybsd 7y ago
        They aren’t “entirely different feature”. Why do you think C#8 introduced Nullable reference types that work exactly like Java Optional ? https://docs.microsoft.com/en-us/dotnet/csharp/nullable-references https://docs.microsoft.com/en-us/dotnet/csharp/nullable-refe...
nitwit005 7y ago
I believe it's not explicitly looking for get/set strings in method names, but generally inlining trivial methods. There is (or was, last time I checked) a -XX:MaxTrivialSize option to set the size. Debugging optimized code awkward as compilers will inline and eliminate many functions. I assume the debugger is being nice to you and undoing the optimizations to make things more intuitive.
bitL 7y ago
LOL, record was an intentional omission during designing Java, similar to output parameters in function calls. It's not like James didn't know about them or couldn't implement them. The only truly problematic thing in the original Java design was type erasure, leading to mess in all JVM-based languages like Scala, Kotlin or Clojure, but it saved some memory, so it was a design compromise. C#/CLR chose the other option, making their VM more flexible.
- pron 7y ago
  Type erasure of generic parameters is what allows the Java language, Kotlin, Clojure, JavaScript and other Java platform languages to interoperate so well and share data types with no runtime conversions despite having different variance strategies. By baking variance into the VM, .NET is much less flexible, as can be seen by how cumbersome it is to share data structures among different languages.
  - dwohnitmok 7y ago
    How is that? I don't have as much experience with .NET languages so I'm not sure of what difficulties lie in .NET interop, but from my very cursory experience with F# And C# I didn't find anything particularly difficult about using one's data structures in the other (granted they don't have different variance strategies). What about Java's type erasure lets languages play better with variance strategies and data structures? It's not apparent to me that e.g. IronPython has a hard time sharing data structures with C# (although I haven't actually used IronPython FWIW). Why doesn't the usual strategy of upcast everything to `Collection<Object>` within a language where collections are covariant and then downcast as needed in a language that doesn't care about variance (e.g. a dynamic language) work?
    - pron 7y ago
      > granted they don't have different variance strategies ... because it's baked into the platform. > It's not apparent to me that e.g. IronPython has a hard time sharing data structures with C# https://ironpython.net/documentation/dotnet/dotnet.html#accessing-generic-types https://ironpython.net/documentation/dotnet/dotnet.html#acce... > Why doesn't the usual strategy of upcast everything to `Collection<Object>` within a language where collections are covariant and then downcast as needed in a language that doesn't care about variance (e.g. a dynamic language) work? Because that does not work for mutable collections, or even for immutable collections created by, say, an untyped language. Clojure can create a list of strings and pass it to a Java method expecting a List<String>.
hinkley 7y ago
Function inlining has been in Hotspot forever. Possibly day 1? In fact there was a point in time where polymorphic inlining was an active field of research and a number of people used the JVM to prototype their theories. Pretty sure a later version of Hotspot had polymorphic inlining as a feature.

apta 7y ago

> C# (structs or maybe properties) Those are not directly analogous to records. As a matter of fact, C# is getting records as well: https://blog.cdemi.io/whats-coming-in-c-8-0-records/ https://blog.cdemi.io/whats-coming-in-c-8-0-records/

statictype 7y ago
This looks like syntactic sugar for comcepts that already exist? I think in Java’s case, its only mow getting struct-like semantics edit I may be wrong. It could be a purely syntax level feature in Java as well.
- paulddraper 7y ago
  Java records are syntax sugar. Value semantics are proposed in JEP 169 [1] and are part of Project Valhalla. [2] [1] https://openjdk.java.net/jeps/169 https://openjdk.java.net/jeps/169 [2] https://wiki.openjdk.java.net/display/valhalla/Main https://wiki.openjdk.java.net/display/valhalla/Main
to11mtm 7y ago
C# has had records slated for years without delivery, alas. Thankfully we do finally have a version in testing. In any case to answer GP, structs should not be considered a valid substitute for records, they are 'value types' so passing them around means you copy all the data every time you pass (i.e. lots of allocations if the record is larger than 1 or 2 fields) Properties get you 'closer'. You can do some code Which is a good bit less than Java by default (i.e. not Lombok or similar) F# does have Records, and technically there's nothing stopping you from declaring your records in F# and importing them into C#... but that may not be ideal. I don't think you get the full benefits (like copying a record with specific properties changed)

crystaldev 7y ago

In Java years, Kotlin hasn't had anything for a "long time," the language itself is still a baby. Most Java shops are still living in the "Java 8 days."

lennydizzy 7y ago

C# struct is a value type, the Java Record is not a value type, right?

pjmlp 7y ago
Right, inline classes are the value types (as part of Valhalla).

pron 7y ago

> Java finally gets what's been available in ... and others for a very long time You seem to think that the goal is to get as many features as possible, as quickly as possible. Maybe some languages have that goal, but Java's design philosophy -- from its inception [1] -- has been to be a conservative language that only adopts features that have become familiar to programmers and stood the test of time in providing a good cost/benefit. Java hasn't always done this, but that's the aspiration. Worked out pretty well, I think. Given Java's design philosophy, the far more interesting question is which features of those more adventurous languages Java does not intend to adopt. > Java compiler/VM, when it sees the patterns "somevar" and functions "getSomeVar" and "setSomeVar" doing purely getter/setter stuff, removes the actual function calls and silently changes them in the background to field lookups for speed. If you attach a debugger or memory profiler, is changes them back to functions and slows them down. It's true, and the optimizing JIT compiler does much more than just that. It performs deep speculative optimizations, like inlining virtual calls and removing untaken branches, reverting them (using a process called deoptimization) either for debugging or when it detects its assumptions are false. What you're referring to is just an instance of inlining. [1]: https://www.win.tue.nl/~evink/education/avp/pdf/feel-of-java.pdf https://www.win.tue.nl/~evink/education/avp/pdf/feel-of-java...

tomcam 7y ago
> deep speculative optimizations my new blog title
Cladode 7y ago
Worked out pretty well, I think. Au contraire mon ami! ML was better than most of its successors, including Java, which held programming back. Milner's ML avoided some of Java's glaring mistakes (e.g. exception specifications, lack of generics, non-uniform treatment of types, lack of higher-order functions, lack of pattern matching) from the start. Xavier Leroy showed how efficiently to compile ML in the 1990s. The main thing ML lacked (w.r.t sequential computing), was a good integration with OO and HKTs. That was solved by Scala.
- pron 7y ago

dfox 7y ago

I believe that the JIT does not remove get/setFoo by matching the naming pattern, but simply because these methods are trivial and usually not polymorphic and thus prime candidates for speculative inlining.

anthonybsd 7y ago

>Java finally gets what's been available in Scala (case classes), C# (structs or maybe properties), Kotlin (data classes) and others for a very long time .. so long we already have tools like Immutables and Lombok to get past this really dumb limitation in Java. All the ones you named are fairly new languages, and C# does not have anything even remotely like records (structs are value types, and properties are fields) so what's your point? Java historically has been very conservative with implementing things because they usually try to get it right (generics non-withstanding). For that matter C# rushed into a few things too and screwed the pooch badly on them.

nightski 7y ago
I'd be curious which features you think C# messed up on. I have been using C# professionally since 2000 in it's first beta and can't think of a newer feature that would meet this criteria? That said you are correct about records. Although it is getting them also.
- anthonybsd 7y ago
  The one that annoys me the most in C# on a day-to-day basis is Nullable<T>. Java took their time with Optional<T> but once it was released it was great. Can be used in lambdas, all libraries are modified and aware of it etc. C# Nullable<T> is near useless because it only works on value types. I.e., you know, the types that are least likely to generate NullReferenceException for you.
  - wvenable 7y ago
    In both C# and Java, reference types are nullable. Nullable<T> exists in C# to provide for nullable value types. It's not comparable to Optional<T> as that's an entirely different feature.
    - anthonybsd 7y ago
      They aren’t “entirely different feature”. Why do you think C#8 introduced Nullable reference types that work exactly like Java Optional ? https://docs.microsoft.com/en-us/dotnet/csharp/nullable-references https://docs.microsoft.com/en-us/dotnet/csharp/nullable-refe...

nitwit005 7y ago

I believe it's not explicitly looking for get/set strings in method names, but generally inlining trivial methods. There is (or was, last time I checked) a -XX:MaxTrivialSize option to set the size. Debugging optimized code awkward as compilers will inline and eliminate many functions. I assume the debugger is being nice to you and undoing the optimizations to make things more intuitive.

bitL 7y ago

LOL, record was an intentional omission during designing Java, similar to output parameters in function calls. It's not like James didn't know about them or couldn't implement them. The only truly problematic thing in the original Java design was type erasure, leading to mess in all JVM-based languages like Scala, Kotlin or Clojure, but it saved some memory, so it was a design compromise. C#/CLR chose the other option, making their VM more flexible.

pron 7y ago
Type erasure of generic parameters is what allows the Java language, Kotlin, Clojure, JavaScript and other Java platform languages to interoperate so well and share data types with no runtime conversions despite having different variance strategies. By baking variance into the VM, .NET is much less flexible, as can be seen by how cumbersome it is to share data structures among different languages.
- dwohnitmok 7y ago
  How is that? I don't have as much experience with .NET languages so I'm not sure of what difficulties lie in .NET interop, but from my very cursory experience with F# And C# I didn't find anything particularly difficult about using one's data structures in the other (granted they don't have different variance strategies). What about Java's type erasure lets languages play better with variance strategies and data structures? It's not apparent to me that e.g. IronPython has a hard time sharing data structures with C# (although I haven't actually used IronPython FWIW). Why doesn't the usual strategy of upcast everything to `Collection<Object>` within a language where collections are covariant and then downcast as needed in a language that doesn't care about variance (e.g. a dynamic language) work?
  - pron 7y ago
    > granted they don't have different variance strategies ... because it's baked into the platform. > It's not apparent to me that e.g. IronPython has a hard time sharing data structures with C# https://ironpython.net/documentation/dotnet/dotnet.html#accessing-generic-types https://ironpython.net/documentation/dotnet/dotnet.html#acce... > Why doesn't the usual strategy of upcast everything to `Collection<Object>` within a language where collections are covariant and then downcast as needed in a language that doesn't care about variance (e.g. a dynamic language) work? Because that does not work for mutable collections, or even for immutable collections created by, say, an untyped language. Clojure can create a list of strings and pass it to a Java method expecting a List<String>.

hinkley 7y ago

Function inlining has been in Hotspot forever. Possibly day 1? In fact there was a point in time where polymorphic inlining was an active field of research and a number of people used the JVM to prototype their theories. Pretty sure a later version of Hotspot had polymorphic inlining as a feature.