number
of years, so it's entirely possible that it is a non-issue now :)
Regards
Heinz
--
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java(tm) Specialists' Newsletter"
Sun/Oracle Java Champion since 2005
JavaOne Rock Star Speaker 2012
http://www.javaspecialists.eu
Tel: +
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
is out of reach of most programmers.
Regards
Heinz
--
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java(tm) Specialists' Newsletter"
Oracle Java Champion 2005-2013
JavaOne Rock Star Speaker 2012
http://www.javaspecialists.eu
Tel: +30 69 75 595 262
Skype: kabutz
Paul Sandoz wr
Plus, monitors can get optimized beautifully when there is no
contention, although that falls away for the code that uses
monitorEnter/monitorExit calls directly as far as I could tell.
Regards
Heinz
--
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java(tm) Specialists' Newslett
With a curious 9 months old crawling around the house, I've just moved
the sharp knives to the top draw in the kitchen - out of reach. I don't
think we should be encouraging people to use monitor.tryLock() for
various reasons:
1. We have a richer interface with Lock/ReentrantLock, including b
On 04/03/2014, David Holmes wrote:
> On 3/03/2014 10:56 PM, David M. Lloyd wrote:
>> Yes, that would necessarily be the contract of a Monitors class, just as
>> it is part of the contract of Lock today. If your argument is that it
>> shouldn't be allowed because it might be used wrong, we might a
your one, but I forgot to
reply and without Martijn's prompting it would have escaped into the
mists of time.
Regards
Heinz
--
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java(tm) Specialists' Newsletter"
Sun Java Champion
IEEE Certified Software Deve
; ThreadLocalRandom included the padding fields, I guess they should have
> been transient in the original implementation.
>
> -Alan.
>
--
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java(tm) Specialists' Newsletter"
Sun Java Champion
IEEE Certified Software Development Professional
http://www.javaspecialists.eu
Tel: +30 69 75 595 262
Skype: kabutz
ow a
> singleton, and add the SUID with the previous value.
>
> -Aleksey.
>
--
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java(tm) Specialists' Newsletter"
Sun Java Champion
IEEE Certified Software Development Professional
http://www.javaspecialists.eu
Tel: +30 69 75 595 262
Skype: kabutz
p avoid
>> any potential issues like this in the future. I can help implement
>> this on top of your patch if you like.
>
> Oh, please go ahead. That's the learning opportunity for me (never used
> sPF before, ready to learn from masters).
>
> -Aleksey.
>
--
Dr
Doug Lea wrote:
On 01/14/13 17:58, Chris Hegarty wrote:
I'm not sure what we are saving here. Since new TLR is a singleton, we
save ~64 bytes per classloader. Worth messing with advanced
serialization mechanics? Probably not. I'll publish a revised webrev
soon.
serialPersistentFields is real
Chris Hegarty wrote:
Updated webrev:
http://cr.openjdk.java.net/~chegar/8005926/webrev.01/webrev/
* based on Aleksey initial webrev
* applied serialPersistentFields, writeObject, readResolve
( as suggested by Heinz )
* did not apply readObject. It is unnecessary, defaultReadObject
wil
tsuba and Toom-Cook squaring) and said they were
>> "very clean." I also ran hundreds of gigabytes of test cases through it
>> (repeatedly,) taking many days, and cross-checked my multiplication
>> routines against several other packages including GMP and previous
>> ver
"I know 7u6 was the first version of JDK to fully support OS X."
I think that's the key to the puzzle, David! It is definitely an OS X
issue. I didn't see this happen on any other platform.
Regards
Heinz
--
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java(tm
Just my 2c :-)
Regards
Heinz
--
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java(tm) Specialists' Newsletter"
Oracle Java Champion 2005-2013
JavaOne Rock Star Speaker 2012
http://www.javaspecialists.eu
Tel: +30 69 75 595 262
Skype: kabutz
Peter Levart wrote:
Hi,
I know that @Calle
Remi Forax wrote:
On 06/26/2013 03:10 AM, Dr Heinz M. Kabutz wrote:
Hi Peter,
here is another use case, where someone might want to use this:
3 - in a static context, find out what the class is that you are in.
For example, if you want to create a logger, instead of doing this:
private
Alan Bateman wrote:
On 25/05/2013 12:35, Alan Bateman wrote:
On 24/05/2013 19:14, Martin Buchholz wrote:
:
Alan, you're telling everyone there's no need for Thread.stop, but
you are replacing usages in tests with calls to Unsafe, which is not
available to normal code. So you have a kind of
closed in the reverse order in which they
are opened and an exception in the middle of the creation chain does not
prevent the earlier resources from being closed.
Regards
Heinz
--
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java(tm) Specialists' Newsletter"
Oracle Java C
Tom Hawtin wrote:
On 09/10/2013 19:00, Dr Heinz M. Kabutz wrote:
That way, the resources are closed in the reverse order in which they
are opened and an exception in the middle of the creation chain does not
prevent the earlier resources from being closed.
But there is only one resource
oes not have to, whereas the
filter() method seems to suggest that it would be a new stream objects,
but it also does not prescribe that it absolutely has to be.
How important is the white-box testing with the streams? And could we
perhaps make special cases for empty streams?
Regards
Hein
Since documentation on that is scarce, I would
appreciate a bit of guidance on how to fix those.
Regards
Heinz
--
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java™ Specialists' Newsletter" - www.javaspecialists.eu
Java Champion - www.javachampions.org
JavaOne Rock Star Speake
your ideas about this idea.
Regards
Heinz
--
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java™ Specialists' Newsletter" - www.javaspecialists.eu
Java Champion - www.javachampions.org
JavaOne Rock Star Speaker
Tel: +30 69 75 595 262
Skype: kabutz
22 matches
Mail list logo
