7 ms·

Java: New Draft JEP: “Computed Constants”

64 points by mfiguiere 3y ago

java-man 3y ago
Wouldn't this be better: private static final Log log = const Log.getLog("yo"); instead of all that rigmarole around ComputedConstants?
- lolinder 3y ago
  This proposal is trying to implement lazy evaluation without adding any new syntax. Your version would require a change to the parser, where this is just a new standard class. A commenter above points out that there's a competing proposal that does introduce new syntax in the form of a `lazy` keyword: https://news.ycombinator.com/item?id=36993023 https://news.ycombinator.com/item?id=36993023
- samus 3y ago
  The architects are wary about introducing new syntax into the Language. If it can be accomplished with an API, it should be done that way. Also, this keyword would probably use something like ComputedConstants in the background, and doing it this way would sweep that under the rug, which is also generally not how most Java features work. The delayed nature of this initialization is also not explicitly highlighted (unlike the lambda we would have to use with ComputedConstants), which will eventually bite people.
recursivedoubts 3y ago
please for the love of gosling give us reasonable data structure literals nobody cares about this stuff i just want to be able to create a map or list w/o ceremony please
- thfuran 3y ago
  You mean List.of and Map.of?
  - recursivedoubts 3y ago
    yes, but real syntax
- whywhywhydude 3y ago
  Perhaps you are using the wrong language. You should probably just stick with python or javascript where they just have simple lists and maps and pretty much nothing else.
  - quickthrower2 3y ago
    Boss says ... ... "no"
  - coldtea 3y ago
    A Java programmer feeling superior? Who would have though the day will come. In all seriousness, this is grade school BS. (a) Literals are a syntax improvement. Much more serious languages than Java have them. (b) What Python and JS have don't amount to "simple lists and maps". They have the full gamut (including constructor based instantiation of different types). (c) Literals don't have to be a single ("simple" or not) type. They can be whatever, and in Java these could include different classes of lists and maps initialized with the same literal syntax based on the assigned variable's type. (d) When Oracle gives literals, Java programmers not familiar with them in other languages will suddenly love them too, and they'd not just be "for Python and Javascript" anymore.
  - imtringued 3y ago
    You can build a named parameter+varargs based syntax on the JVM that is applicable to every container with the appropriate constructor.
- ptx 3y ago
  Kotlin (which has very smooth interoperability with Java) makes it pretty easy: mapOf("a" to 1, "b" to 2) ...where "to" is actually an infix extension function that creates a Pair object, so there is no special syntax for maps.
- kasperni 3y ago
  Plenty of people care about native images/Project Leyden which this proposal is an integral part of.
p2detar 3y ago
Looks similar to the java.util.function.Supplier interface.
- samus 3y ago
  It's that, plus caching. It's basically what a thunk is called in Haskell land. You could also describe it as a Future, but with a vastly simplified API (no exceptions to catch when calling `get()`) thanks to being intended for the single-threaded case.
  - hueho 3y ago
    As far as I understood this is very much intended to be used in multi-threaded code as well. If you are sure that your object won't be called in multiple threads you can just do the simple "if(ref == null)" without locking and it should be reasonably fast - just not constant-foldable by the JVM.
    - samus 3y ago
      The ComputedConstant indeed has to be threadsafe, but the proposal reads as its initializer would be executed on the thread of the caller of get(), and other callers would have to wait until initialization has completed. Indeed very useful for multithreaded programs as well.
lolinder 3y ago
It looks like this is going to be the Java version of Kotlin's lazy [0] and Scala's lazy val [1]. [0] https://kotlinlang.org/docs/delegated-properties.html#lazy-properties https://kotlinlang.org/docs/delegated-properties.html#lazy-p... [1] https://www.baeldung.com/scala/lazy-val https://www.baeldung.com/scala/lazy-val
- mfiguiere 3y ago
  There were another JEP draft [1] recently that was proposing to introduce a lazy keyword for static fields. This new JEP looks like an alternative without any language change, and seems more likely to prevail. [1] JEP draft: Lazy Static Final Fields - https://openjdk.org/jeps/8209964 https://openjdk.org/jeps/8209964
- paulirwin 3y ago
  It also seems very similar to .NET's Lazy<T>: https://learn.microsoft.com/en-us/dotnet/api/system.lazy-1?view=net-7.0 https://learn.microsoft.com/en-us/dotnet/api/system.lazy-1?v...
- pron 3y ago
  Not quite. You need to have control over the JVM to do what this class does. The whole point of this class is a lazy value that interacts with the JIT in desirable ways.
  - lolinder 3y ago
    Sure, but that's an (important) implementation detail. If this JEP is merged both Scala and Kotlin could implement their respective features in terms of ComputedConstant and get the performance enhancements for free. Meaning it's semantically the same, with non-functional benefits.
snihalani 3y ago
[flagged]
- vore 3y ago
  Pros: maybe subjectively feels better for some people? Cons: extremely painful amounts of churn for everyone
- marginalia_nu 3y ago
  So code in jython?
kjeetgill 3y ago
A ton of comments are missing the point of this complaining about list/map syntax etc. I'm not sure if the kotlin lazy addresses this. The point is that static final variables interact especially well with the JIT's constant folding machinery. But lazy loading a constant necessitates that it can't be final: it's initially null until it's effectively final after the first lazy load. This finality is clear to the developer but not to the JVM. This is introduces a way to implement lazy constants via a blessed class that solves this. The article is pretty clear about what the point is — but does require some careful reading and context.
- bjourne 3y ago
  The example used is the venerable Logger class from the log4j package. It seem implausible that imprecise constant folding would cause a measurable performance decrease when using that class. So to me the point is not clear. A more convincing argument would be before and after stats of a benchmark showing x% performance increase.
  - appplication 3y ago
    Your other points aside, venerable might not be the right word for a package notorious for one of the most impactful zero days in recent memory.
spullara 3y ago
Ah, I wrote this and called it Lazy. Much better if the VM knows though! https://github.com/spullara/java-future-jdk8/blob/master/src/main/java/spullara/util/Lazy.java https://github.com/spullara/java-future-jdk8/blob/master/src...
zeroimpl 3y ago
Name seems a bit odd. The item it points at doesn’t have to be immutable. I’d rather something like LazyValue since Lazy is the important part.
- kasperni 3y ago
  It is not necessarily lazy. Computations might, for example, be time-shifted to link time instead of runtime. See some of the notes on project Leyden for more details [1]. https://openjdk.org/projects/leyden/notes/02-shift-and-constrain https://openjdk.org/projects/leyden/notes/02-shift-and-const...
liquid153 3y ago
Is this like constexpr in C++
naruhodo 3y ago
Interesting article. For collections, I can see myself using these instead of static initialiser blocks. And TIL about the holder idiom. [1] But for the love of Glob I wish web page authors would cease their contrast brinkmanship. Most of the text is barely discernible from the background. [1] https://en.wikipedia.org/wiki/Initialization-on-demand_holder_idiom https://en.wikipedia.org/wiki/Initialization-on-demand_holde...
fidgitkid 3y ago
[dead]
tagitfast 3y ago
[dead]
jiehong 3y ago
I get the idea, but the example itself about the logger is not great IMO. Any class doing IO is a dependency, so you normally would just inject it via the constructor of the class.
barelysapient 3y ago
This reminds me of 'sync.Once' from the Golang. Very nice to have this sort of functionality in the stdlib. Glad to see Java getting something similar.
spiralx 3y ago
What an awful text colour, had to do this just to read the article: $$('div, h1, h2').forEach(e => e.style.color = '#111')

64 points by mfiguiere 3y ago

Wouldn't this be better: private static final Log log = const Log.getLog("yo"); instead of all that rigmarole around ComputedConstants?

lolinder 3y ago
This proposal is trying to implement lazy evaluation without adding any new syntax. Your version would require a change to the parser, where this is just a new standard class. A commenter above points out that there's a competing proposal that does introduce new syntax in the form of a `lazy` keyword: https://news.ycombinator.com/item?id=36993023 https://news.ycombinator.com/item?id=36993023
samus 3y ago
The architects are wary about introducing new syntax into the Language. If it can be accomplished with an API, it should be done that way. Also, this keyword would probably use something like ComputedConstants in the background, and doing it this way would sweep that under the rug, which is also generally not how most Java features work. The delayed nature of this initialization is also not explicitly highlighted (unlike the lambda we would have to use with ComputedConstants), which will eventually bite people.

recursivedoubts 3y ago

please for the love of gosling give us reasonable data structure literals nobody cares about this stuff i just want to be able to create a map or list w/o ceremony please

thfuran 3y ago
You mean List.of and Map.of?
- recursivedoubts 3y ago
  yes, but real syntax
whywhywhydude 3y ago
Perhaps you are using the wrong language. You should probably just stick with python or javascript where they just have simple lists and maps and pretty much nothing else.
- quickthrower2 3y ago
  Boss says ... ... "no"
- coldtea 3y ago
  A Java programmer feeling superior? Who would have though the day will come. In all seriousness, this is grade school BS. (a) Literals are a syntax improvement. Much more serious languages than Java have them. (b) What Python and JS have don't amount to "simple lists and maps". They have the full gamut (including constructor based instantiation of different types). (c) Literals don't have to be a single ("simple" or not) type. They can be whatever, and in Java these could include different classes of lists and maps initialized with the same literal syntax based on the assigned variable's type. (d) When Oracle gives literals, Java programmers not familiar with them in other languages will suddenly love them too, and they'd not just be "for Python and Javascript" anymore.
- imtringued 3y ago
  You can build a named parameter+varargs based syntax on the JVM that is applicable to every container with the appropriate constructor.
ptx 3y ago
Kotlin (which has very smooth interoperability with Java) makes it pretty easy: mapOf("a" to 1, "b" to 2) ...where "to" is actually an infix extension function that creates a Pair object, so there is no special syntax for maps.
kasperni 3y ago
Plenty of people care about native images/Project Leyden which this proposal is an integral part of.

p2detar 3y ago

Looks similar to the java.util.function.Supplier interface.

samus 3y ago
It's that, plus caching. It's basically what a thunk is called in Haskell land. You could also describe it as a Future, but with a vastly simplified API (no exceptions to catch when calling `get()`) thanks to being intended for the single-threaded case.
- hueho 3y ago
  As far as I understood this is very much intended to be used in multi-threaded code as well. If you are sure that your object won't be called in multiple threads you can just do the simple "if(ref == null)" without locking and it should be reasonably fast - just not constant-foldable by the JVM.
  - samus 3y ago
    The ComputedConstant indeed has to be threadsafe, but the proposal reads as its initializer would be executed on the thread of the caller of get(), and other callers would have to wait until initialization has completed. Indeed very useful for multithreaded programs as well.

lolinder 3y ago

It looks like this is going to be the Java version of Kotlin's lazy [0] and Scala's lazy val [1]. [0] https://kotlinlang.org/docs/delegated-properties.html#lazy-properties https://kotlinlang.org/docs/delegated-properties.html#lazy-p... [1] https://www.baeldung.com/scala/lazy-val https://www.baeldung.com/scala/lazy-val

mfiguiere 3y ago
There were another JEP draft [1] recently that was proposing to introduce a lazy keyword for static fields. This new JEP looks like an alternative without any language change, and seems more likely to prevail. [1] JEP draft: Lazy Static Final Fields - https://openjdk.org/jeps/8209964 https://openjdk.org/jeps/8209964
paulirwin 3y ago
It also seems very similar to .NET's Lazy<T>: https://learn.microsoft.com/en-us/dotnet/api/system.lazy-1?view=net-7.0 https://learn.microsoft.com/en-us/dotnet/api/system.lazy-1?v...
pron 3y ago
Not quite. You need to have control over the JVM to do what this class does. The whole point of this class is a lazy value that interacts with the JIT in desirable ways.
- lolinder 3y ago
  Sure, but that's an (important) implementation detail. If this JEP is merged both Scala and Kotlin could implement their respective features in terms of ComputedConstant and get the performance enhancements for free. Meaning it's semantically the same, with non-functional benefits.

snihalani 3y ago

[flagged]

vore 3y ago
Pros: maybe subjectively feels better for some people? Cons: extremely painful amounts of churn for everyone
marginalia_nu 3y ago
So code in jython?

kjeetgill 3y ago

A ton of comments are missing the point of this complaining about list/map syntax etc. I'm not sure if the kotlin lazy addresses this. The point is that static final variables interact especially well with the JIT's constant folding machinery. But lazy loading a constant necessitates that it can't be final: it's initially null until it's effectively final after the first lazy load. This finality is clear to the developer but not to the JVM. This is introduces a way to implement lazy constants via a blessed class that solves this. The article is pretty clear about what the point is — but does require some careful reading and context.

bjourne 3y ago
The example used is the venerable Logger class from the log4j package. It seem implausible that imprecise constant folding would cause a measurable performance decrease when using that class. So to me the point is not clear. A more convincing argument would be before and after stats of a benchmark showing x% performance increase.
- appplication 3y ago
  Your other points aside, venerable might not be the right word for a package notorious for one of the most impactful zero days in recent memory.

spullara 3y ago

Ah, I wrote this and called it Lazy. Much better if the VM knows though! https://github.com/spullara/java-future-jdk8/blob/master/src/main/java/spullara/util/Lazy.java https://github.com/spullara/java-future-jdk8/blob/master/src...

zeroimpl 3y ago

Name seems a bit odd. The item it points at doesn’t have to be immutable. I’d rather something like LazyValue since Lazy is the important part.

kasperni 3y ago
It is not necessarily lazy. Computations might, for example, be time-shifted to link time instead of runtime. See some of the notes on project Leyden for more details [1]. https://openjdk.org/projects/leyden/notes/02-shift-and-constrain https://openjdk.org/projects/leyden/notes/02-shift-and-const...

liquid153 3y ago

Is this like constexpr in C++

naruhodo 3y ago

Interesting article. For collections, I can see myself using these instead of static initialiser blocks. And TIL about the holder idiom. [1] But for the love of Glob I wish web page authors would cease their contrast brinkmanship. Most of the text is barely discernible from the background. [1] https://en.wikipedia.org/wiki/Initialization-on-demand_holder_idiom https://en.wikipedia.org/wiki/Initialization-on-demand_holde...

fidgitkid 3y ago

[dead]

tagitfast 3y ago

[dead]

jiehong 3y ago

I get the idea, but the example itself about the logger is not great IMO. Any class doing IO is a dependency, so you normally would just inject it via the constructor of the class.

barelysapient 3y ago

This reminds me of 'sync.Once' from the Golang. Very nice to have this sort of functionality in the stdlib. Glad to see Java getting something similar.

spiralx 3y ago

What an awful text colour, had to do this just to read the article: $$('div, h1, h2').forEach(e => e.style.color = '#111')