From: Erik H. <eh...@gm...> - 2009-02-22 20:26:39
|
I'd like to propose to remove the signal catching native code. Why? Well, 1) Because it's Unix specific, meaning Windows will work differently than Unix 2) Because it needs a C compiler to be installed (which the rest of ABCL doesn't require) 3) Because it's bad manners for a library to install a signal handler (which is a global variable) in an application it doesn't own 4) Because there's a pure Java method: sun.misc.Signal and sun.misc.SignalHandler Comments? Bye, Erik. |
From: Ville V. <vil...@gm...> - 2009-02-23 08:44:20
|
On Sun, Feb 22, 2009 at 10:26 PM, Erik Huelsmann <eh...@gm...> wrote: > I'd like to propose to remove the signal catching native code. Why? Well, > 1) Because it's Unix specific, meaning Windows will work differently than Unix > 2) Because it needs a C compiler to be installed (which the rest of > ABCL doesn't require) > 3) Because it's bad manners for a library to install a signal handler > (which is a global variable) in an application it doesn't own > 4) Because there's a pure Java method: sun.misc.Signal and > sun.misc.SignalHandler > Comments? Reason 3 is quite severe, I don't feel comfortable with installing signal handlers in a library. We should check whether it's for REPL only. If not, removal is well justified. I also don't feel comfortable with using sun.* classes. All in all, the significance/usefulness of that code seems questionable, so I think removing it is a good idea. |
From: Alessio S. <ale...@gm...> - 2009-02-23 11:29:14
|
On Mon, Feb 23, 2009 at 9:44 AM, Ville Voutilainen <vil...@gm...> wrote: > On Sun, Feb 22, 2009 at 10:26 PM, Erik Huelsmann <eh...@gm...> wrote: >> I'd like to propose to remove the signal catching native code. Why? Well, >> 1) Because it's Unix specific, meaning Windows will work differently than Unix >> 2) Because it needs a C compiler to be installed (which the rest of >> ABCL doesn't require) >> 3) Because it's bad manners for a library to install a signal handler >> (which is a global variable) in an application it doesn't own >> 4) Because there's a pure Java method: sun.misc.Signal and >> sun.misc.SignalHandler >> Comments? > > Reason 3 is quite severe, I don't feel comfortable with installing > signal handlers > in a library. We should check whether it's for REPL only. If not, > removal is well > justified. > > I also don't feel comfortable with using sun.* classes. Reason 1-3 are all quite severe imho. But I suspect that using those sun.* classes you actually do install signal handlers, albeit using a Java interface, so reason 3) would not really be solved by this. Probably it would be better to drop support for handling signals altogether, if it has sufficiently low impact. Just my €.02 Alessio > All in all, the significance/usefulness of that code seems > questionable, so I think > removing it is a good idea. > |
From: Ville V. <vil...@gm...> - 2009-02-23 13:18:18
|
On Mon, Feb 23, 2009 at 1:29 PM, Alessio Stalla <ale...@gm...> wrote: > Reason 1-3 are all quite severe imho. But I suspect that using those > sun.* classes you actually do install signal handlers, albeit using a > Java interface, so reason 3) would not really be solved by this. Exactly right. It just allows installing a handler without resorting to C code. |
From: Erik H. <eh...@gm...> - 2009-02-23 21:28:52
|
On Mon, Feb 23, 2009 at 2:18 PM, Ville Voutilainen <vil...@gm...> wrote: > On Mon, Feb 23, 2009 at 1:29 PM, Alessio Stalla <ale...@gm...> wrote: >> Reason 1-3 are all quite severe imho. But I suspect that using those >> sun.* classes you actually do install signal handlers, albeit using a >> Java interface, so reason 3) would not really be solved by this. > > Exactly right. It just allows installing a handler without resorting to C code. > Done. It's gone. Weird side note: "Native" wasn't found outside Native.java by NetBeans. Makes me wonder if this ever worked... Bye, Erik. |