On 4/17/16 4:05 PM, David Holmes wrote:
On 14/04/2016 11:50 AM, Stuart Marks wrote:
The methods being deprecated with forRemoval=true are listed below. All
of these methods have already been deprecated. They are all ill-defined,
or they don't work, or they don't do anything useful.
Surprised
Hi Stuart,
On 14/04/2016 11:50 AM, Stuart Marks wrote:
Hi all,
Please review this first round of deprecation changes for the java.lang
package. This changeset includes the following:
- a set of APIs being newly deprecated
- a set of already-deprecated APIs that are "upgraded" to forRemoval
I don't think it's practical to ever remove the boxed primitive constructors.
Even less so for String, because the String(String) constructor used
to be an important optimization!
On Thu, Apr 14, 2016 at 4:25 PM, Stuart Marks wrote:
> On 4/14/16 10:10 AM, Martin Buchholz wrote:
>>
>> I've been te
On 4/15/16 3:38 AM, Lance Andersen wrote:
Yes I am fine with the change. I can go back and do this after your push if
you prefer, just let me know
Thanks. I'm going to post an updated webrev with some other changes, so I'll
just include the cleanups that Paul suggested.
s'marks
Hi Stephen, Remi,
I would *love* to just get rid of the caches of integral boxed types and get rid
of their constructors. Unfortunately people have been using the constructors for
20 years, but the valueOf(i) methods were added with autoboxing in Java 5,
"only" 11.5 years ago.
We did think a
On 4/14/16 10:26 PM, Dr Heinz M. Kabutz wrote:
Vladimir Ivanov wrote:
I'd say it's a motivating example to improve EA implementation in C2, but not
to avoid deprecation of public constructors in primitive type boxes. It
shouldn't matter for C2 whether Integer.valueOf() or Integer:: is used.
If
Partial review. The changes to j.l.Thread* look good to me.
-Chris.
On 14 Apr 2016, at 02:50, Stuart Marks wrote:
> Hi all,
>
> Please review this first round of deprecation changes for the java.lang
> package. This changeset includes the following:
>
> - a set of APIs being newly deprecated
I had a sidebar with Shipilev on this, and this is indeed still
potentially an issue. Alexey's example was:
set.contains(new Integer(i)) // 1
vs
set.contains(Integer.valueOf(i)) // 2
EA is able to optimize away the allocation in line 1, but the additional
complexity of dealin
bout EA, do you agree that if the set is declared as a
> Set, there is no such issue anymore ?
>
> Rémi
>
> - Mail original -
>> De: "Dr Heinz M. Kabutz"
>> À: "Vladimir Ivanov"
>> Cc: "core-libs-dev"
>> Envoyé
Hi Stuart,
Yes I am fine with the change. I can go back and do this after your push if
you prefer, just let me know
Best
Lance
> On Apr 14, 2016, at 7:13 PM, Stuart Marks wrote:
>
>
>
> On 4/14/16 8:30 AM, Paul Sandoz wrote:
>> CachedRowSetImpl
>> —
>>
>> 1966 return ((Float.v
example about EA, do you agree that if the set is declared as a
Set, there is no such issue anymore ?
Rémi
- Mail original -
> De: "Dr Heinz M. Kabutz"
> À: "Vladimir Ivanov"
> Cc: "core-libs-dev"
> Envoyé: Vendredi 15 Avril 2016 07:26:03
>
- Mail original -
> De: "Brian Goetz"
> À: "Rémi Forax"
> Cc: "Stuart Marks" , "core-libs-dev"
>
> Envoyé: Jeudi 14 Avril 2016 21:06:28
> Objet: Re: RFR(m): 8145468 deprecations for java.lang
>
> Sure, there is some in
Vladimir Ivanov wrote:
On 4/14/16 7:37 AM, Dr Heinz M. Kabutz wrote:
in previous versions of Java, escape analysis did not seem to work
particularly
well with Integer.valueOf(int) values, since the objects of course
could come
from the Integer Cache. Thus if the Integer object did not escape
f
On 4/14/16 10:10 AM, Martin Buchholz wrote:
I've been tempted by the dark side, when a class needs a value AND a
lock (or an "identity"). Instead of doing
final String val = "foo";
final Object lock = new Object();
one can "optimize" this ("why can't we have both?") to
final String valAndLock
On 4/14/16 8:30 AM, Paul Sandoz wrote:
CachedRowSetImpl
—
1966 return ((Float.valueOf(value.toString())).floatValue());
Use Float.parseFloat ?
2010 return
((Double.valueOf(value.toString().trim())).doubleValue());
Use Double.parseDouble ?
I'm mostly reluctant to
On 4/14/16 7:37 AM, Dr Heinz M. Kabutz wrote:
in previous versions of Java, escape analysis did not seem to work
particularly
well with Integer.valueOf(int) values, since the objects of course
could come
from the Integer Cache. Thus if the Integer object did not escape
from your
method, it coul
On 4/14/16 7:37 AM, Dr Heinz M. Kabutz wrote:
in previous versions of Java, escape analysis did not seem to work particularly
well with Integer.valueOf(int) values, since the objects of course could come
from the Integer Cache. Thus if the Integer object did not escape from your
method, it cou
On 4/14/16 6:49 AM, Lance Andersen wrote:
Outside of the comments from Remi regarding ASM, the other changes look fine to
me and the wordsmithing looks good.
Hi Lance, thanks for the looking this over.
I assume we are going to want to go back and add the JDK release of deprecation
for all m
On 4/14/16 6:21 AM, Remi Forax wrote:
you are not the first one to try to change the integers defined in
org.objectweb.asm.Opcodes, those values are compared by ref (not by value)
inside ASM.
You're patch will change the behavior of any Interpreters that also use some
Integers created by Integ
by Integer.valueOf() because valueOf may
>> cache the Integer references.
>>>
>>> I will add a comment in the ASM trunk for avoid such refactoring in
>> the future.
>>>
>>> reagrds,
>>> Rémi
>>>
>>>
>>> -
M trunk for avoid such refactoring in
>the future.
>>
>> reagrds,
>> Rémi
>>
>>
>> - Mail original -----
>>> De: "Stuart Marks"
>>> À: "core-libs-dev"
>>> Envoyé: Jeudi 14 Avril 2016 03:50:14
>>>
.
>
> reagrds,
> Rémi
>
>
> - Mail original -
>> De: "Stuart Marks"
>> À: "core-libs-dev"
>> Envoyé: Jeudi 14 Avril 2016 03:50:14
>> Objet: RFR(m): 8145468 deprecations for java.lang
>>
>> Hi all,
>>
>&g
I've been tempted by the dark side, when a class needs a value AND a
lock (or an "identity"). Instead of doing
final String val = "foo";
final Object lock = new Object();
one can "optimize" this ("why can't we have both?") to
final String valAndLock = new String("foo");
and there are surely fo
Hi,
Looks good. Minor comments.
CachedRowSetImpl
—
1966 return ((Float.valueOf(value.toString())).floatValue());
Use Float.parseFloat ?
2010 return
((Double.valueOf(value.toString().trim())).doubleValue());
Use Double.parseDouble ?
ExpressionExecuter
—
86
On 14/04/2016 02:50, Stuart Marks wrote:
Hi all,
Please review this first round of deprecation changes for the
java.lang package. This changeset includes the following:
- a set of APIs being newly deprecated
- a set of already-deprecated APIs that are "upgraded" to
forRemoval=true
- ad
Hi Stuart,
in previous versions of Java, escape analysis did not seem to work
particularly well with Integer.valueOf(int) values, since the objects of
course could come from the Integer Cache. Thus if the Integer object
did not escape from your method, it could get eliminated entirely. Not
Hi Stuart,
Outside of the comments from Remi regarding ASM, the other changes look fine to
me and the wordsmithing looks good.
I assume we are going to want to go back and add the JDK release of
deprecation for all methods. If so, I will get to the JDBC ones shortly.
Best
Lance
> On Apr 13
lueOf may cache the Integer
references.
I will add a comment in the ASM trunk for avoid such refactoring in the future.
reagrds,
Rémi
- Mail original -
> De: "Stuart Marks"
> À: "core-libs-dev"
> Envoyé: Jeudi 14 Avril 2016 03:50:14
> Objet: RFR(m
Hi all,
Please review this first round of deprecation changes for the java.lang package.
This changeset includes the following:
- a set of APIs being newly deprecated
- a set of already-deprecated APIs that are "upgraded" to forRemoval=true
- addition of the "since" element to all deprecati
29 matches
Mail list logo
