Re: [concurrency-interest] Deprecate all java.util.concurrent.*FieldUpdater

[Stuart Marks]

On 10/5/16 10:04 AM, Andrew Haley wrote:

On 05/10/16 17:55, Vladimir Ivanov wrote:

On 10/5/16 7:39 AM, Justin Sampson wrote:

My interpretation of Martin's comment is that using deprecation for
things that aren't actually broken just means that people will live
with lots of deprecation warnings in their code for years to
come. This could be a perfect case for introducing a weaker
alternative to deprecation, saying "here's something better that you
should really be using for new code" -- e.g. ArrayList vs. Vector.

Doesn't enhanced deprecation [1] in 9 cover that?


I can't tell.  As far as I can see there is no annotation which
covers exactly our case:

the API is flawed and is impractical to fix,

usage of the API is likely to lead to errors,

the API has been superseded by another API,

the API is obsolete,

the API is experimental and is subject to incompatible changes,

or any combination of the above.

we'd perhaps need to add

this method over here is better in most cases

...which perhaps implies obsolescent rather than obsolete.



(Vladimir, thanks for mentioning JEP 277. [1])

Andrew, all,

The list of criteria from JEP 277 isn't intended to be restrictive. It turns out 
that the criteria for deprecating something are quite subjective, and it's 
really hard to boil them down to specific reasons or attributes or whatever.


To my eye, "has been superseded by" includes "this method over here is better in 
most cases" but I'm sure we could find differences if we went looking for them.


The main contribution of JEP 277 in this area is the addition of the boolean 
forRemoval element to the @Deprecated annotation. If true, it means there is a 
plan to remove the annotated API -- for the JDK, most likely in the next major 
release. If false, it means there are no plans to remove the API at present.


To get back to this specific case, if you're looking over the shoulder of 
someone who's using *FieldUpdater, and your reaction is "you should be using 
VarHandles instead" then that's an argument for deprecating the FieldUpdaters 
with forRemoval=false.


On the other hand, if there are still things you can do with FieldUpdaters that 
you cannot (yet) do with VarHandles or some other construct, that's an argument 
for *not* deprecating the FieldUpdaters (yet).


I'm not familiar enough with the current state of things in this area to make an 
informed recommendation here.


s'marks


[1] http://openjdk.java.net/jeps/277

Re: [concurrency-interest] Deprecate all java.util.concurrent.*FieldUpdater

[Andrew Haley]

On 05/10/16 17:55, Vladimir Ivanov wrote:
>>> My interpretation of Martin's comment is that using deprecation for
>>> things that aren't actually broken just means that people will live
>>> with lots of deprecation warnings in their code for years to
>>> come. This could be a perfect case for introducing a weaker
>>> alternative to deprecation, saying "here's something better that you
>>> should really be using for new code" -- e.g. ArrayList vs. Vector. I
>>> remember the Guava team talking about that a lot. Don't know if they
>>> ever implemented it.
>>
>> OK.  But we really do need a way to do that.
> Doesn't enhanced deprecation [1] in 9 cover that?

I can't tell.  As far as I can see there is no annotation which
covers exactly our case:

the API is flawed and is impractical to fix,

usage of the API is likely to lead to errors,

the API has been superseded by another API,

the API is obsolete,

the API is experimental and is subject to incompatible changes,

or any combination of the above.

we'd perhaps need to add

this method over here is better in most cases

...which perhaps implies obsolescent rather than obsolete.

Andrew.

Re: [concurrency-interest] Deprecate all java.util.concurrent.*FieldUpdater

[Vladimir Ivanov]

My interpretation of Martin's comment is that using deprecation for
things that aren't actually broken just means that people will live
with lots of deprecation warnings in their code for years to
come. This could be a perfect case for introducing a weaker
alternative to deprecation, saying "here's something better that you
should really be using for new code" -- e.g. ArrayList vs. Vector. I
remember the Guava team talking about that a lot. Don't know if they
ever implemented it.


OK.  But we really do need a way to do that.

Doesn't enhanced deprecation [1] in 9 cover that?

Best regards,
Vladimir Ivanov

[1] http://openjdk.java.net/jeps/277

RE: [concurrency-interest] Deprecate all java.util.concurrent.*FieldUpdater

[Justin Sampson]

Deprecation is stronger than that -- it says "we're going to remove this, or we 
wish we could remove it because it's broken, so you'd better change your code 
a.s.a.p." -- e.g. Thread.stop(). My interpretation of Martin's comment is that 
using deprecation for things that aren't actually broken just means that people 
will live with lots of deprecation warnings in their code for years to come. 
This could be a perfect case for introducing a weaker alternative to 
deprecation, saying "here's something better that you should really be using 
for new code" -- e.g. ArrayList vs. Vector. I remember the Guava team talking 
about that a lot. Don't know if they ever implemented it.

Cheers,
Justin


-Original Message-
From: Concurrency-interest [mailto:concurrency-interest-boun...@cs.oswego.edu] 
On Behalf Of Andrew Haley
Sent: Wednesday, October 05, 2016 1:19 AM
To: Martin Buchholz; Remi Forax; Paul Sandoz
Cc: core-libs-dev; concurrency-interest
Subject: Re: [concurrency-interest] Deprecate all 
java.util.concurrent.*FieldUpdater

On 04/10/16 22:19, Martin Buchholz wrote:
> VarHandle is a reasonable replacement for FieldUpdaters, but it's not yet
> complete (where is accumulateAndGet?), and when do you deprecate something
> when the replacement won't be ubiquitous for 10 years?

Surely you have to start somewhere: deprecation is no more than saying
to programmers "Don't use this, use that."  And if you were leaning
over someone's shoulder that's what you would say.

Andrew.


___
Concurrency-interest mailing list
concurrency-inter...@cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

Re: [concurrency-interest] Deprecate all java.util.concurrent.*FieldUpdater

[Andrew Haley]

On 05/10/16 15:39, Justin Sampson wrote:

> Deprecation is stronger than that -- it says "we're going to remove
> this, or we wish we could remove it because it's broken, so you'd
> better change your code a.s.a.p." -- e.g. Thread.stop().

We're moving Java to support some new ways of working, and these
changes will inevitably mean that some parts of the project will be
obsolescent.  We need to be able to flag the old ways of doing things
in some way.

Deprecation is a way to do that.  I don't think that Thread.stop() is
a typical case.

> My interpretation of Martin's comment is that using deprecation for
> things that aren't actually broken just means that people will live
> with lots of deprecation warnings in their code for years to
> come. This could be a perfect case for introducing a weaker
> alternative to deprecation, saying "here's something better that you
> should really be using for new code" -- e.g. ArrayList vs. Vector. I
> remember the Guava team talking about that a lot. Don't know if they
> ever implemented it.

OK.  But we really do need a way to do that.

Andrew.

Re: Deprecate all java.util.concurrent.*FieldUpdater

[David M. Lloyd]

I'm sure I recall an email from the past few months which proposed that 
*FieldUpdater are still going to be recommended in many cases over 
VarHandle because the latter is probably too low-level for casual uses. 
It was (IIRC) an argument in favor of more advanced fence methods or 
something like that.


Am I imagining it?

On 10/04/2016 04:19 PM, Martin Buchholz wrote:

VarHandle is a reasonable replacement for FieldUpdaters, but it's not yet
complete (where is accumulateAndGet?), and when do you deprecate something
when the replacement won't be ubiquitous for 10 years?

On Tue, Oct 4, 2016 at 1:32 PM, Remi Forax  wrote:


Given that Java 9 introduces a faster way to emit things like
compareAndSet by using the VarHandke API and that AtomiReference (and
likes) are now rewritten to use VarHandles directly,
i think it's time to deprecate all *FieldUpdater with something saying
that they have been superseded by the VarHandle API.

Rémi
substitute dr deprecator



--
- DML

Re: Deprecate all java.util.concurrent.*FieldUpdater

[Remi Forax]

Hi Martin,

On October 4, 2016 11:19:33 PM GMT+02:00, Martin Buchholz  
wrote:
>VarHandle is a reasonable replacement for FieldUpdaters, but it's not
>yet
>complete (where is accumulateAndGet?), 

Seems to be a feature for me :)
I've never liked the methods that takes a lambda in FieldUpdater. If you're 
using a FieldUpdater, you are in the basement, you want a reliable performance 
model. The JLS does not guarantee that a side effect free lambda will be always 
inlined.

>and when do you deprecate
>something
>when the replacement won't be ubiquitous for 10 years?

The right answer is the one from Andrew but i can not resisrt, here is my 
answer:
when you hope that it will not take 10 years to be ubiquitous.

regards,
Remi

>
>On Tue, Oct 4, 2016 at 1:32 PM, Remi Forax  wrote:
>
>> Given that Java 9 introduces a faster way to emit things like
>> compareAndSet by using the VarHandke API and that AtomiReference (and
>> likes) are now rewritten to use VarHandles directly,
>> i think it's time to deprecate all *FieldUpdater with something
>saying
>> that they have been superseded by the VarHandle API.
>>
>> Rémi
>> substitute dr deprecator
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [concurrency-interest] Deprecate all java.util.concurrent.*FieldUpdater

[Andrew Haley]

On 04/10/16 22:19, Martin Buchholz wrote:
> VarHandle is a reasonable replacement for FieldUpdaters, but it's not yet
> complete (where is accumulateAndGet?), and when do you deprecate something
> when the replacement won't be ubiquitous for 10 years?

Surely you have to start somewhere: deprecation is no more than saying
to programmers "Don't use this, use that."  And if you were leaning
over someone's shoulder that's what you would say.

Andrew.

Re: Deprecate all java.util.concurrent.*FieldUpdater

[Martin Buchholz]

VarHandle is a reasonable replacement for FieldUpdaters, but it's not yet
complete (where is accumulateAndGet?), and when do you deprecate something
when the replacement won't be ubiquitous for 10 years?

On Tue, Oct 4, 2016 at 1:32 PM, Remi Forax  wrote:

> Given that Java 9 introduces a faster way to emit things like
> compareAndSet by using the VarHandke API and that AtomiReference (and
> likes) are now rewritten to use VarHandles directly,
> i think it's time to deprecate all *FieldUpdater with something saying
> that they have been superseded by the VarHandle API.
>
> Rémi
> substitute dr deprecator
>

Deprecate all java.util.concurrent.*FieldUpdater

[Remi Forax]

Given that Java 9 introduces a faster way to emit things like compareAndSet by 
using the VarHandke API and that AtomiReference (and likes) are now rewritten 
to use VarHandles directly,
i think it's time to deprecate all *FieldUpdater with something saying that 
they have been superseded by the VarHandle API.

Rémi
substitute dr deprecator