On 4/07/2018 6:21 PM, Lindenmaier, Goetz wrote:
Hi,
Volker, thanks for improving on my original change and
implementing David's and Karen's proposals.
David, I think the change addresses a row of your concerns.
proposal - it just moves the "field" from the Java side to the VM side.
No, the s
On 07/04/2018 09:22 AM, Zheka Kozlov wrote:
> Oh yes, you are right. Then this is not dead code, just a useless null
> check.
My vague recollection is that the check was there to ensure that the
block was identical to those in the other methods when considering ways
to factor it out (none of which
Just as a note, it is reasonable to make value “final” so that value can not be
nulled out between the test and its use.
Cheers,
— Jim
> On Jul 4, 2018, at 10:22 AM, Zheka Kozlov wrote:
>
> Oh yes, you are right. Then this is not dead code, just a useless null
> check.
>
> 2018-07-04 19:55
On 07/04/2018 02:41 PM, Nasser Ebrahim wrote:
Please share your thoughts on your preferred option and list out any other
options which I missed out. Thank you for your time.
Could you use the platform iconv implementation instead? That would
avoid shipping the tables in the JDK.
Thanks,
Flo
Oh yes, you are right. Then this is not dead code, just a useless null
check.
2018-07-04 19:55 GMT+07:00 Scott Palmer :
> On Jul 4, 2018, at 5:42 AM, Zheka Kozlov wrote:
> >
> > I noticed dead code in java.util.HashMap.merge():
> >
> > public V merge(K key, V value,
> > BiFunct
On Jul 4, 2018, at 5:42 AM, Zheka Kozlov wrote:
>
> I noticed dead code in java.util.HashMap.merge():
>
> public V merge(K key, V value,
> BiFunction
> remappingFunction) {
>if (value == null)
>throw new NullPointerException();
>
>...
>
>if (value != null)
Hello,
Am starting this mail thread to discuss about adding new IBM extended
charsets. The questions is whether we need to add the new extended
charsets to jdk.charsets or to a new separate charset provider/module like
jdk.ibmcharsets. This discussion is in continuation of the suggestion from
+1
> On Jul 4, 2018, at 8:25 AM, Srinivas Dama wrote:
>
> Hi,
>
> Please review
> webrev: http://cr.openjdk.java.net/~sdama/8198819/webrev.01/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8198819
>
> Modified test to work only on modules extracted using jimage instead of
> considering
Hi,
Please review
webrev: http://cr.openjdk.java.net/~sdama/8198819/webrev.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8198819
Modified test to work only on modules extracted using jimage instead of
considering already existing files
in current directory and treating them as bad Modules
Hi Volker,
It occurred to me that getting rid of backtrace-s of cause(s)/suppressed
exception(s) might not be enough to prevent ClassLoader leaks...
On 07/04/2018 10:21 AM, Lindenmaier, Goetz wrote:
dealing with backtrace and stackTrace. I have to wonder why nothing in
Throwable clears the ba
I noticed dead code in java.util.HashMap.merge():
public V merge(K key, V value,
BiFunction
remappingFunction) {
if (value == null)
throw new NullPointerException();
...
if (value != null) { *// Condition ' value != null' is always true*
if (t != nu
Hi,
Volker, thanks for improving on my original change and
implementing David's and Karen's proposals.
David, I think the change addresses a row of your concerns.
> proposal - it just moves the "field" from the Java side to the VM side.
No, the space overhead in case of successful initializatio
12 matches
Mail list logo
