Hi,
i wanted to start a discussion/review-process for JDK5108778 some
time ago. Please see a previous try below. The patches are now pretty
old, and I will rebase and update them to the created sub-issues
- JDK-8143008 (jaxp)
- JDK-8143009 (jaxws)
- JDK-8143010 (corba)
for a sub-repo-discussion/
Hi,
postponed this, for a later try.
I created 3 subtasks:
https://bugs.openjdk.java.net/browse/JDK-8143008(jaxp)
https://bugs.openjdk.java.net/browse/JDK-8143009(jaxws)
https://bugs.openjdk.java.net/browse/JDK-8143010(corba)
and documented my patches and linked the related discussio
Hi,
i wanted to start a discussion/review-process some time ago, see the
second-try below.
Is there someone who wants to discuss/review/sponsor these changes?
Else, should i link my result as reference into the JBS?
For the two other affected mailing-lists/repos
(macos-port-dev[0],net-dev[1]) i
Hello,
Actually I am searching through the JBS for low hanging fruits.
Right now i am looking through the openjdk-sources and try to evaluate
if i can make something about JDK-5108778.
Please find my webrevs for the jaxp, jaxws and corba repos at:
http://cr.openjdk.java.net/~sebastian/5108778/ja
On 10/9/15 12:23 PM, Sebastian Sickelmann wrote:
I'll file a bug on the JLS for this.
What is the Bug-Number. Maybe i can watch and comment on this.
https://bugs.openjdk.java.net/browse/JDK-8139324
s'marks
On 10/09/2015 08:58 PM, Stuart Marks wrote:
> On 10/9/15 4:16 AM, Aleksey Shipilev wrote:
>> Please note that "static final Boolean myBool = new
>> Boolean(true).booleanValue()" is a spec-recommended way to avoid binary
>> incompatibilities caused by conditional compilation. See JLS 13.4.9.
>> Ther
On 10/9/15 4:16 AM, Aleksey Shipilev wrote:
Please note that "static final Boolean myBool = new
Boolean(true).booleanValue()" is a spec-recommended way to avoid binary
incompatibilities caused by conditional compilation. See JLS 13.4.9.
Therefore, deprecating Boolean constructors is a spec issue
On 10/08/2015 09:58 PM, Stuart Marks wrote:
> On 10/7/15 12:59 PM, Sebastian Sickelmann wrote:
>> http://cr.openjdk.java.net/~sebastian/5108778/core-libs/webrev.00/
>>
>> jdk:
>> The Boolean constructors are @Deprecated now so that we get
>> compile-warnings for the uses. See also [0] and [1]
>>
>>
On 10/08/2015 08:58 PM, Stuart Marks wrote:
> On 10/7/15 12:59 PM, Sebastian Sickelmann wrote:
>> http://cr.openjdk.java.net/~sebastian/5108778/core-libs/webrev.00/
>>
>> jdk:
>> The Boolean constructors are @Deprecated now so that we get
>> compile-warnings for the uses. See also [0] and [1]
>>
>>
Hi Fabian,
As you might have seen from my message to Sebastian, I agree that the Boolean
constructors shouldn't be deprecated -- at least not with deprecation in its
current form.
The idea is eventually to mark them somehow, in a way that warns developers that
other APIs are preferable, but
On 10/7/15 12:59 PM, Sebastian Sickelmann wrote:
http://cr.openjdk.java.net/~sebastian/5108778/core-libs/webrev.00/
jdk:
The Boolean constructors are @Deprecated now so that we get
compile-warnings for the uses. See also [0] and [1]
[0]
http://mail.openjdk.java.net/pipermail/discuss/2015-Septem
Hi Sebastian,
I am all for micro optimizations that do make sense, even if their impact
might be low, but I disagree with deprecating the Boolean constructor.
Using it, while not being the most efficient, is not a problem, and I would
say in almost all application and workloads not an issue worth
Hello,
Actually I am searching through the JBS for low hanging fruits.
Right now i am looking through the openjdk-sources and try to evaluate
if i can make something about JDK-5108778.
Please find my webrevs for the jdk, jaxp, jaxws and corba repos at:
http://cr.openjdk.java.net/~sebastian/51087
13 matches
Mail list logo
