Re: RFR: 8276700: Improve java.lang.ref.Cleaner javadocs [v3]

2021-11-10 Thread Anthony Vanelverdinghe
On Wed, 10 Nov 2021 09:43:58 GMT, Hendrik Schreiber  
wrote:

>>> When I see ``, I'm just wondering what those <> type operators are 
>>> good for here...
>> 
>> What about just replacing `` with `...` then? The `State` 
>> constructor and its invocation also have an ellipsis.
>> 
>>> BUT, at least it's a working example and not some pseudo code.
>> 
>> The example is still not compilable due to the remaining ellipses.
>> 
>>> We do want to move to working example code long term, don't we?
>> 
>> I agree that examples should be compilable *in the raw Javadoc*. However, in 
>> the rendered Javadoc, using ellipses is a well-understood way to keep 
>> examples concise and devoid of irrelevant and/or usecase-dependent code. 
>> Moreover, when developers copy-paste the example, they'll immediately be 
>> pointed to all the places where they need to fill in the blanks, make a 
>> choice for a trade-off, etc. On the other hand, by hard-coding a 
>> (suboptimal) choice, developers who merely copy-paste the example are 
>> unlikely to reconsider the trade-off.
>> 
>>> The new example Cleaner instance _is_ shared, though on a pretty small 
>>> scale (just among instances of CleaningExample).
>> 
>> True, but my point was that the comment says "shared *within a library*". So 
>> to me it's confusing to have a comment saying "it's preferred to do A", and 
>> then have the code do B on the next line.
>> 
>> So I propose to either:
>> * revert the current change & simply replace `` with `...`
>> * update the comment to say: "A cleaner (preferably one shared within a 
>> library, but for the sake of example, a new one is created here)"
>> 
>> Actually, to have the line be compilable, and at the same time (attempt to) 
>> force developers to consider the trade-off, it could be changed to something 
>> like:
>> 
>> 
>> private static final Cleaner cleaner = createCleaner();
>> 
>> private static Cleaner createCleaner() {
>> // A cleaner, preferably one shared within a library
>> throw new UnsupportedOperationException("TBD");
>> }
>
> This is getting too complicated...
> 
> It's a code *example* with a very clear comment that explains a best practice:
> 
> // A cleaner, preferably one shared within a library
> private static final Cleaner cleaner = Cleaner.create();
> 
> 
> We cannot really show the best practice in this example without making the 
> example itself more complicated. IMHO, introducing an extra factory method 
> here adds nothing but complexity and makes the example more difficult to 
> understand (that aside, it should probably be something like 
> `MyLibrary.getCleaner()` and not a `createXyz()` method).
> 
> I still much more prefer `cleaner = Cleaner.create();` over `cleaner = 
> ` (which really is no better in any way, shape or form and creates 
> more questions than it provides answers) or `cleaner = ...`, which again does 
> not answer the question of how to get a cleaner instance—something I asked 
> myself when trying to use the API. In fact *how to get a cleaner instance* is 
> not explained by the current javadocs *at all* and it's something one *must* 
> know to use this API.
> 
> Here's our chance to show how it *can* be done, even if it's not ideal, 
> because it does not demonstrate the one-cleaner per library recommendation 
> (only mentions it).
> 
> And yes, those ellipsis in the `State` class code—I'd love for them to be 
> gone, too. It would make the example less abstract and easier to understand 
> (what's this state anyway? in most cases it's probably a reference to a 
> state, e.g. a native pointer, i.e. a `long`). But, admittedly, that's 
> difficult.
> 
> So, to summarize, there is always a tradeoff between making an example easy 
> to understand, not too complex, but still conveying the most important 
> information and best practices. In the end it's a matter of opinion. In this 
> case, I will stick to my original code change suggestion, because it adds 
> value (answers the question of how to get/create a cleaner instance).

In short: the current code


// A cleaner, preferably one shared within a library
private static final Cleaner cleaner = ;


is unhelpful to you, and the proposed code


// A cleaner, preferably one shared within a library
private static final Cleaner cleaner = Cleaner.create();


is confusing to me.

Trying to find a compromise, I'm merely asking that the comment be clarified:


// A cleaner (preferably one shared within a library, but for the sake of 
example, a new one is created here)
private static final Cleaner cleaner = Cleaner.create();


What do you think?

-

PR: https://git.openjdk.java.net/jdk/pull/6076


Re: RFR: 8276700: Improve java.lang.ref.Cleaner javadocs [v3]

2021-11-10 Thread Hendrik Schreiber
> Trivial improvement.
> 
> Explicitly show how to create a `Cleaner` instance using `Cleaner.create()`.
> Repeat (again) in the code example that the `State` `Runnable `should be 
> implemented as static class and not reference the instance to be cleaned, to 
> make the point even more clear to those people who never read the javadoc 
> *prose*.
> 
> I have signed the OCA a while back as 
> [hschreiber](https://openjdk.java.net/census#hschreiber).

Hendrik Schreiber has updated the pull request incrementally with one 
additional commit since the last revision:

  Removed duplicate info from comment.

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6076/files
  - new: https://git.openjdk.java.net/jdk/pull/6076/files/3a552acc..f5d4ee92

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6076&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6076&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6076.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6076/head:pull/6076

PR: https://git.openjdk.java.net/jdk/pull/6076