In general, I think Objects.requireNonNull() should often be considered
idiomatic Java.
If the constant-folding is to be avoided, I would prefer to see
"foo".toString();
have a comment like
"foo".toString(); // Avoid mandatory constant propagation
-Joe
On 04/27/2014 08:05 PM, Otávio
On 2014-04-30 13:08, Remi Forax wrote:
On 04/29/2014 11:20 AM, Claes Redestad wrote:
On 2014-04-29 09:31, Remi Forax wrote:
On 04/28/2014 05:43 PM, Claes Redestad wrote:
On 04/28/2014 08:57 AM, David Holmes wrote:
On 28/04/2014 1:05 PM, Otávio Gonçalves de Santana wrote:
In my opinion not,
On 04/29/2014 11:20 AM, Claes Redestad wrote:
On 2014-04-29 09:31, Remi Forax wrote:
On 04/28/2014 05:43 PM, Claes Redestad wrote:
On 04/28/2014 08:57 AM, David Holmes wrote:
On 28/04/2014 1:05 PM, Otávio Gonçalves de Santana wrote:
In my opinion not, because Objects.requireNonNull is more re
On 04/29/2014 10:58 AM, David Holmes wrote:
> On 29/04/2014 7:40 PM, Andrew Haley wrote:
>> On 04/28/2014 07:57 AM, David Holmes wrote:
>>> On 28/04/2014 1:05 PM, Otávio Gonçalves de Santana wrote:
In my opinion not, because Objects.requireNonNull is more readable than
just string.toStrin
On 29/04/2014 7:40 PM, Andrew Haley wrote:
On 04/28/2014 07:57 AM, David Holmes wrote:
On 28/04/2014 1:05 PM, Otávio Gonçalves de Santana wrote:
In my opinion not, because Objects.requireNonNull is more readable than
just string.toString. This way is more understandable which field is
required
On 04/28/2014 07:57 AM, David Holmes wrote:
> On 28/04/2014 1:05 PM, Otávio Gonçalves de Santana wrote:
>> In my opinion not, because Objects.requireNonNull is more readable than
>> just string.toString. This way is more understandable which field is
>> required and doesn't impact on performance.
>
On 2014-04-29 09:31, Remi Forax wrote:
On 04/28/2014 05:43 PM, Claes Redestad wrote:
On 04/28/2014 08:57 AM, David Holmes wrote:
On 28/04/2014 1:05 PM, Otávio Gonçalves de Santana wrote:
In my opinion not, because Objects.requireNonNull is more readable
than
just string.toString. This way is
On 04/29/2014 12:43 AM, Jim Graham wrote:
We refer to these strings as constants in many places. If you have:
class Foo {
static final String bar = "";
}
class Blah {
// uses Foo.bar
}
Then Blah will incorporate that string by content, not by reference.
I don't know why this is done
On 04/28/2014 05:43 PM, Claes Redestad wrote:
On 04/28/2014 08:57 AM, David Holmes wrote:
On 28/04/2014 1:05 PM, Otávio Gonçalves de Santana wrote:
In my opinion not, because Objects.requireNonNull is more readable than
just string.toString. This way is more understandable which field is
requir
We refer to these strings as constants in many places. If you have:
class Foo {
static final String bar = "";
}
class Blah {
// uses Foo.bar
}
Then Blah will incorporate that string by content, not by reference. I
don't know why this is done this way, but Strings are special in that
I am quite sure that you are right that these were deliberate so
I am adding Jim who was the author of all of the 2d ones to explain the
intent.
BTW Otávio, changes in 2D code like this should not slip by on the
core-libs list.
It ought to go to 2d-dev.
-phil.
On 4/28/2014 9:24 AM, Louis Wa
On 04/28/2014 08:57 AM, David Holmes wrote:
On 28/04/2014 1:05 PM, Otávio Gonçalves de Santana wrote:
In my opinion not, because Objects.requireNonNull is more readable than
just string.toString. This way is more understandable which field is
required and doesn't impact on performance.
An invo
I have to say that the expected NPE is quite "hidden" in the current code.
I am actually surprised someone was able to catch that. The use of
Objects.requreNonNull() is way more clear and I prefer that approach for
the sake of clarity.
On Mon, Apr 28, 2014 at 8:28 AM, Otávio Gonçalves de Santana
Done.
Link:
https://dl.dropboxusercontent.com/u/16109193/open_jdk/string_to_string_uncessary.zip
On Mon, Apr 28, 2014 at 4:34 AM, Paul Sandoz wrote:
> Hi Otávio,
>
> Is there anyway you can experiment with publishing a webrev to dropbox or
> github, preferably so that it is browsable, otherwise
Yes you are right, but I mean it doesn't too much expensive enough to don't
use the requireNonNull.
IMHO.
On Mon, Apr 28, 2014 at 3:57 AM, David Holmes wrote:
> On 28/04/2014 1:05 PM, Otávio Gonçalves de Santana wrote:
>
>> In my opinion not, because Objects.requireNonNull is more readable than
On 28/04/2014 1:05 PM, Otávio Gonçalves de Santana wrote:
In my opinion not, because Objects.requireNonNull is more readable than
just string.toString. This way is more understandable which field is
required and doesn't impact on performance.
An invocation of requireNonNull is potentially more
Hi Otávio,
Is there anyway you can experiment with publishing a webrev to dropbox or
github, preferably so that it is browsable, otherwise the zip?
Unfortunately the patches are hard to review, especially in response to reviews
where code is updated.
I realize until you have an openjdk account
In my opinion not, because Objects.requireNonNull is more readable than
just string.toString. This way is more understandable which field is
required and doesn't impact on performance.
On Sun, Apr 27, 2014 at 11:33 PM, David Holmes wrote:
> On 28/04/2014 3:41 AM, Otávio Gonçalves de Santana wrot
On 28/04/2014 3:41 AM, Otávio Gonçalves de Santana wrote:
sorry.
I tried answer and the message was twice.
But Yes when has null pointer possibility I replaced to
Objects.requireNonNull.
In my opinion that is making the code worse not better.
David
-
I am review the code again.
The cod
sorry.
I tried answer and the message was twice.
But Yes when has null pointer possibility I replaced to
Objects.requireNonNull.
I am review the code again.
The code below:
diff -r e323c74edabd
src/share/classes/com/sun/tools/example/debug/tty/Commands.java
--- a/src/share/classes/com/sun/tools/e
On 04/27/2014 03:15 PM, Otávio Gonçalves de Santana wrote:
There is an issue that was opened to remove redundant calls of toString()
on String objects. [1]
I went deep on all JVM sources and I found all, 32 changes.
[1]https://bugs.openjdk.java.net/browse/JDK-8015470
Otavio,
calling toString(
21 matches
Mail list logo
