From 560ded50127b12bd8168f8ae2bada47253f15bc8 Mon Sep 17 00:00:00 2001 From: Reinier Zwitserloot Date: Tue, 8 Feb 2022 06:02:27 +0100 Subject: [PATCH] [website] slight feature documentation updates (Just bringing them in line with reality) --- website/templates/features/experimental/FieldDefaults.html | 6 ++---- .../templates/features/experimental/StandardException.html | 2 ++ website/templates/features/experimental/index.html | 7 +++---- 3 files changed, 7 insertions(+), 8 deletions(-) diff --git a/website/templates/features/experimental/FieldDefaults.html b/website/templates/features/experimental/FieldDefaults.html index c0d3db9602..b4b582e978 100644 --- a/website/templates/features/experimental/FieldDefaults.html +++ b/website/templates/features/experimental/FieldDefaults.html @@ -10,14 +10,12 @@ <@f.experimental> - Current status: positive - Currently we feel this feature may move out of experimental status with no or minor changes soon. + Current status: neutral - Currently we feel this feature may not move out of experimental status without changes. <@f.overview> diff --git a/website/templates/features/experimental/StandardException.html b/website/templates/features/experimental/StandardException.html index 1484154d6c..c7fc40fe2a 100644 --- a/website/templates/features/experimental/StandardException.html +++ b/website/templates/features/experimental/StandardException.html @@ -48,6 +48,8 @@ There is a very slight functional difference: Normally, invoking new SomeException(message, null) will initialize the cause to be no cause, and this cannot be later changed by invoking initCause. However, lombok's standard exceptions do let you overwrite an explicit no-cause with initCause later. +

+ A second slight functional difference: Normally, invoking new SomeException(cause), if implemented as super(cause);, will set the message to be equal to the message of the cause. However, lombok does not do this - it leaves the exception as having no message at all. We think inheriting the message is fundamentally wrong - messages are not guaranteed to be sensible in the absence of the context of the exception-type. The cause ought to be listed anywhere where it is relevant; if you are using messages as direct user feedback (which is rare, in the java community), @StandardException can't really help you anyway; the infrastructure of e.g. getLocalizedMessage() is too complicated.

diff --git a/website/templates/features/experimental/index.html b/website/templates/features/experimental/index.html index a8430d8d70..a50a467006 100644 --- a/website/templates/features/experimental/index.html +++ b/website/templates/features/experimental/index.html @@ -28,10 +28,6 @@

- <@main.feature title="var" href="var"> - Modifiable local variables with a type inferred by assigning value. - - <@main.feature title="@Accessors" href="Accessors"> A more fluent API for getters and setters. @@ -101,6 +97,9 @@

Putting the "Ex" in "Experimental": promoted or deleted <@main.feature title="@Wither: renamed to @With, and promoted" href="/features/With"> Immutable 'setters' - methods that create a clone but with one changed field. + <@main.feature title="var" href="/features/var"> + Modifiable local variables with a type inferred by assigning value. +