4 ms·

Do you really think they just forget about it? It has a purpose: https://mail.openjdk.org/pipermail/amber-dev/2020-April/005899.html https://mail.openjdk.org/pi

by krzyk 4y ago

Do you really think they just forget about it? It has a purpose: https://mail.openjdk.org/pipermail/amber-dev/2020-April/005899.html https://mail.openjdk.org/pipermail/amber-dev/2020-April/0058...

imoverclocked 4y ago
That’s the fun thing about backward compatibility. You can never clean up technically supported things that were never intended. It would be cool if we could have some kind of pragma or alternate syntax (file extension?) that gets rid of these unwanted ambiguities every decade or so. How to do that while avoiding the whole “Perl 6” can of worms might be the hard part though.
- KptMarchewa 4y ago
  Rust editions? They work on per crate, rather than per file level though.
  - pron 4y ago
    In Java you set the language version per source file, and there are occasional and uncommon source incompatibilities, but it's still not worth it to introduce a common incompatibility (which isn't really the case here, anyway).
    - KptMarchewa 4y ago
      They still all compile to some set bytecode version, right?
      - pron 4y ago
        The target bytecode/standard library version can also be specified on a per-file basis (we have both -source and -target options). But while the VM can load a classfile of any version since the beginning of time, the javac compiler supports only a certain number of versions back in terms of source version and target version (e.g. you can't use a JDK 19 compiler to target JDK 7, but you can ask for the same language, API, and bytecode level as 15).
- nativecoinc 4y ago
  Perl 5 has that. Perl 5 seems to have all these annoying boilerplate lines that you need to add to every file in order to get “Perl The Good Parts”. But I think (I read) that they managed to boil it down to just one line.
javier2 4y ago
These things are what I love the most about JEPs. Someone already discussed it.
xg15 4y ago
Thanks for digging out that thread, that really gives some insight! I still disagree though. First, there is precedent with interfaces and abstract methods, which also leave out the method body and terminate with a semicolon. Second, the point here is that you almost always leave the body of a record empty, while you rarely do so for a class or method. They are worried that if you use arcane constructs like non-static initializers, the syntax might become confusing - but are fine if you have clutter in the common case. That seems backwards to me. Edit: You can construct the exact same confusing situation that the thread warns against already today, with abstract methods: public abstract void foo(); { System.out.print("I don't have anything to do with foo!"); } Somehow we still lived.
- pron 4y ago
  > You can construct the exact same confusing situation that the thread warns against already today, with abstract methods The email exchange didn't talk about that kind of confusion; in fact, it said `;` was an option. It just said that saving one or two keystrokes isn't worth it to break the rule that type declarations end in `}` while statements end in `;`. > there is precedent with interfaces and abstract methods, which also leave out the method body and terminate with a semicolon. Abstract methods aren't type declarations and they have no body. Also, they've been in Java since day one. It's conceivable that down the line, people will be so used to records that we'll allow `;` to terminate the definition. It's just that we've gone down from a page of code to one line, and adding another rule to save one character isn't worth it at this time.
  - xg15 4y ago
    First of all, thanks a lot for the reply. I didn't expect to get an answer by the actual authors of the feature :) I think it's not really about the keystrokes (though { } is harder to type on my keyboard than ; ) but more that this technically opens a new class block, which gets treated as such by build tools, IDEs, etc. E.g. formatters want to put the braces on different lines by default and are generally tuned to put class blocks front and center - because with all the other occurrences of class blocks, that's the sensible thing to do. With records, it just undoes the neat "just one line" property. Yes, you can add custom formatting rules to stop that, but that's additional effort - you also have to ensure everyone uses the new formatting, etc. It's also more cognitive effort to parse the code: Imagine the GROUP BY clause were mandatory in SQL and if you didn't want to use grouping in your query, you'd have to write something like "GROUP BY 1". Certainly doable but makes queries harder to read. > type declarations end in `}` while statements end in `;`. That rule already has lots of exceptions, e.g. methods are not type declarations (like you said) and neither are initializers. Nevertheless, both use braces and leave out the ; at the end.
adrianmsmith 4y ago
There is plenty of precedent for using ; instead of { } if the { } is empty, e.g. interface methods, or "while (foo());"

by krzyk 4y ago

Do you really think they just forget about it? It has a purpose: https://mail.openjdk.org/pipermail/amber-dev/2020-April/005899.html https://mail.openjdk.org/pipermail/amber-dev/2020-April/0058...

imoverclocked 4y ago

That’s the fun thing about backward compatibility. You can never clean up technically supported things that were never intended. It would be cool if we could have some kind of pragma or alternate syntax (file extension?) that gets rid of these unwanted ambiguities every decade or so. How to do that while avoiding the whole “Perl 6” can of worms might be the hard part though.

KptMarchewa 4y ago
Rust editions? They work on per crate, rather than per file level though.
- pron 4y ago
  In Java you set the language version per source file, and there are occasional and uncommon source incompatibilities, but it's still not worth it to introduce a common incompatibility (which isn't really the case here, anyway).
  - KptMarchewa 4y ago
    They still all compile to some set bytecode version, right?
    - pron 4y ago
      The target bytecode/standard library version can also be specified on a per-file basis (we have both -source and -target options). But while the VM can load a classfile of any version since the beginning of time, the javac compiler supports only a certain number of versions back in terms of source version and target version (e.g. you can't use a JDK 19 compiler to target JDK 7, but you can ask for the same language, API, and bytecode level as 15).
nativecoinc 4y ago
Perl 5 has that. Perl 5 seems to have all these annoying boilerplate lines that you need to add to every file in order to get “Perl The Good Parts”. But I think (I read) that they managed to boil it down to just one line.

javier2 4y ago

These things are what I love the most about JEPs. Someone already discussed it.

xg15 4y ago

Thanks for digging out that thread, that really gives some insight! I still disagree though. First, there is precedent with interfaces and abstract methods, which also leave out the method body and terminate with a semicolon. Second, the point here is that you almost always leave the body of a record empty, while you rarely do so for a class or method. They are worried that if you use arcane constructs like non-static initializers, the syntax might become confusing - but are fine if you have clutter in the common case. That seems backwards to me. Edit: You can construct the exact same confusing situation that the thread warns against already today, with abstract methods: public abstract void foo(); { System.out.print("I don't have anything to do with foo!"); } Somehow we still lived.

pron 4y ago
> You can construct the exact same confusing situation that the thread warns against already today, with abstract methods The email exchange didn't talk about that kind of confusion; in fact, it said `;` was an option. It just said that saving one or two keystrokes isn't worth it to break the rule that type declarations end in `}` while statements end in `;`. > there is precedent with interfaces and abstract methods, which also leave out the method body and terminate with a semicolon. Abstract methods aren't type declarations and they have no body. Also, they've been in Java since day one. It's conceivable that down the line, people will be so used to records that we'll allow `;` to terminate the definition. It's just that we've gone down from a page of code to one line, and adding another rule to save one character isn't worth it at this time.
- xg15 4y ago
  First of all, thanks a lot for the reply. I didn't expect to get an answer by the actual authors of the feature :) I think it's not really about the keystrokes (though { } is harder to type on my keyboard than ; ) but more that this technically opens a new class block, which gets treated as such by build tools, IDEs, etc. E.g. formatters want to put the braces on different lines by default and are generally tuned to put class blocks front and center - because with all the other occurrences of class blocks, that's the sensible thing to do. With records, it just undoes the neat "just one line" property. Yes, you can add custom formatting rules to stop that, but that's additional effort - you also have to ensure everyone uses the new formatting, etc. It's also more cognitive effort to parse the code: Imagine the GROUP BY clause were mandatory in SQL and if you didn't want to use grouping in your query, you'd have to write something like "GROUP BY 1". Certainly doable but makes queries harder to read. > type declarations end in `}` while statements end in `;`. That rule already has lots of exceptions, e.g. methods are not type declarations (like you said) and neither are initializers. Nevertheless, both use braces and leave out the ; at the end.

adrianmsmith 4y ago

There is plenty of precedent for using ; instead of { } if the { } is empty, e.g. interface methods, or "while (foo());"