Hello everyone !
I looked for the answer in this list and did not find anything relevant.
I don't know it it's possible to close a Process et call shutdown hooks
automatically. I looked into the code and found it was not possible (in jdk7).
When we call destroy() on a Process, it will call
Hi Nicolas,
Looks like a well discussed question. On Posix systems, SIGTERM should work
for you. That's the default signal sent by the 'kill' command on Linux.
e.g. please take a look here:
http://stackoverflow.com/questions/2541597/how-to-gracefully-handle-the-sigkill-signal-in-java
- Kris
On
On 03/04/2014 02:41 AM, Jeroen Frijters wrote:
Brian Goetz wrote:
Embedded in this proposal is the desire to not provide a full-blown
lvalue form for variables; supporting any form of pass-by-reference at
the language level is a super-non-goal here.
Why is this? It solves these problems in an
On 04/03/2014 11:51, Krystal Mok wrote:
Hi Nicolas,
Looks like a well discussed question. On Posix systems, SIGTERM should work
for you. That's the default signal sent by the 'kill' command on Linux.
e.g. please take a look here:
I didn't know for jdk8 functions destroy and the new one destroyForcibly...
And Jonathan was right in his previous answer, I was looking for a solution in
Java, I mean a portable one like in Process class, like the
destroyGracefully.
I am looking to signals because it seems to be a simple way
On 03/04/2014 02:09 PM, LE PICARD NICOLAS wrote:
I didn't know for jdk8 functions destroy and the new one destroyForcibly...
And Jonathan was right in his previous answer, I was looking for a solution in Java, I
mean a portable one like in Process class, like the destroyGracefully.
I am
Exactly !
In fact, I'm in mastery of ... nothing ! But I tried to workaround this problem
and found that Java Process class lacks something ! I was working in Eclipse
and you can process while testing (the red button in console view) but shutdown
hooks are not called. So I dug a little to
On 03/04/2014 01:14 AM, Brian Burkhalter wrote:
- add AtomicReferenceFieldUpdater-type constant for stringCache initialization
Hi Brian,
By using volatile read and CAS, there's still a chance that multiple
concurrent threads will be invoking the layoutChars(true) concurrently,
but you
On 03/03/2014 09:45 PM, 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
On Mar 4 2014, at 07:13 , Peter Levart peter.lev...@gmail.com wrote:
On 03/04/2014 01:14 AM, Brian Burkhalter wrote:
- add AtomicReferenceFieldUpdater-type constant for stringCache
initialization
Hi Brian,
By using volatile read and CAS, there's still a chance that multiple
On Mar 3, 2014, at 11:37 AM, Brian Burkhalter wrote:
The fields bitCount, bitLength, and lowestSetBit appear in the serialized
form only for backward compatibility and are otherwise ignored, so their
@serialField entries should just say that instead of describing how they
were formerly
http://cr.openjdk.java.net/~vlivanov/8036117/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8036117
84 lines changed: 74 ins; 3 del; 7 mod
I have to revert a cleanup I did for 8027827.
MethodHandle.invokeWithArguments (and generic invocation) has unpleasant
peculiarity in behavior when
Out of curiosity, I looked at JAR files in all RPMs in Fedora rawhide
(the development version of Fedora that will turn into Fedora 21) and
counted the number of RPM packages which had Java classes referencing
individual methods in sun.misc.Unsafe. The attached table is sorted by
decreasing
Hi Brian,
Just a couple small items.
At line 4203, the type of magnitude should be byte[] instead of int[]. Whoops, I
could have sworn I wrote that in my previous review, but it must have gotten
dropped while I was editing. Sorry about that.
For the four compatibility fields in the serial
Hi Stuart,
On Mar 4, 2014, at 1:09 PM, Stuart Marks wrote:
Just a couple small items.
At line 4203, the type of magnitude should be byte[] instead of int[].
Whoops, I could have sworn I wrote that in my previous review, but it must
have gotten dropped while I was editing. Sorry about
On 03/03/2014 04:53 PM, David M. Lloyd wrote:
On 03/03/2014 04:25 PM, Brian Goetz wrote:
Posted: http://openjdk.java.net/jeps/193
Some follow-up thoughts on teasing apart the issues covered by this JEP.
There are three main layers of questions to answer:
1. How do we surface the various
OK, thanks for fixing up this stuff, even before I had mentioned it.
As far as I'm concerned the change is ready to go in, but as you mention we
still need to get (internal) approval for spec changes.
s'marks
On 3/4/14 1:12 PM, Brian Burkhalter wrote:
Hi Stuart,
On Mar 4, 2014, at 1:09 PM,
On Mar 4, 2014, at 1:38 PM, Stuart Marks wrote:
OK, thanks for fixing up this stuff, even before I had mentioned it.
This is a positive race condition!
As far as I'm concerned the change is ready to go in, but as you mention we
still need to get (internal) approval for spec changes.
OK.
On 03/04/2014 01:05 PM, Doug Lea wrote:
On 03/04/2014 02:41 AM, Jeroen Frijters wrote:
Brian Goetz wrote:
Embedded in this proposal is the desire to not provide a full-blown
lvalue form for variables; supporting any form of pass-by-reference at
the language level is a super-non-goal here.
On 03/04/2014 05:12 PM, Florian Weimer wrote:
On 03/04/2014 01:05 PM, Doug Lea wrote:
On 03/04/2014 02:41 AM, Jeroen Frijters wrote:
I understand pass-by-reference is an expensive feature, but IMNSHO
poluting
Java with this proposal will prove to be more expensive in the long
run. It's
like
Embedded in this proposal is the desire to not provide a
full-blown lvalue form for variables; supporting any form of
pass-by-reference at the language level is a super-non-goal here.
Why is this? It solves these problems in an extremely clean way and
also provides lots of other value (for
Hello,
Following up from the recent discussions around
JDK-8035452: Fix serial lint warnings in core libs
it turns out that java.util.TreeMap.NavigableSubMap, a package private
nested class used in the TreeMap implementation does indeed need to have
a serialVersionUID defined to allow
Hi Joe,
These changes are fine. You might want to update the copyright year of
ExceptionProxy.java though.
s'marks
On 3/3/14 10:05 PM, Joe Darcy wrote:
Hi Stuart,
Thanks for the careful review. I agree the case of TreeMap.NavigableSbugMap
requires some more investigation. In the meantime,
Hi Joe,
Fix looks good. I confirmed that the svuid value in your patch is the right one
to be compatible with 6 and 7, at least for all the versions of those releases
that I have at my fingertips (which is several). And yes, we need to figure out
how best to fix this in the 8 release family.
On 5/03/2014 1:32 AM, David M. Lloyd wrote:
On 03/03/2014 09:45 PM, 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
On Mar 4, 2014, at 7:41 PM, David Holmes david.hol...@oracle.com wrote:
I agree it is as unsafe as using Lock. I think not being able to forget to
unlock a monitor is more than just convenient. YMMV and obviously does.
That's why that unsafe kind of stuff currently lives in class unsafe.
Brian Goetz wrote:
Right now, the semantics of method calls in Java are simple --
everything (primitives, object references) is passed by value. Adding
pass-by-reference would add significant complexity. And method calls
are not a niche feature; that added complexity will be borne by every
Am 05.03.2014 um 08:40 schrieb Jeroen Frijters jer...@sumatra.nl:
My goal here is to make sure that expert users can get their job done
somehow, *without* making the job of mainstream developers harder. The
add lvalues to Java so experts can write CAS-libraries fails that test
miserably.
28 matches
Mail list logo
