Issue1729

I got a report from a team using a tool I develop that the tool fails to start with this error:

  IllegalArgumentException: Signal already used by VM: INT

This error occurs when the tool registers signal handlers with signal.signal. The code already catches ValueError which this method is documented to possibly raise [1] but obviously IllegalArgumentException goes through.

I looked at the source of signal module distributed with Jython 2.5.1 and noticed that it calls sun.misc.Signal.handle. I then looked at its documentation [2] which tells this in the beginning of the module doc:

"""Java code cannot register a handler for signals that are already used by the Java VM implementation. The Signal.handle function raises an IllegalArgumentException if such an attempt is made."""

It seems to me that calls to sun.misc.Signal.handle should be wrapped with try/except and possible IllegalArgumentException then reraised as a ValueError. I can provide a patch if this sounds like a good idea.

[1] http://docs.python.org/library/signal.html#signal.signal
[2] http://www.docjar.com/docs/api/sun/misc/Signal.html

According to this StackOverflow question the underlying IllegalArgumentException problem is JVM specific:

http://stackoverflow.com/questions/1050370/java-error-java-lang-illegalargumentexception-signal-already-used-by-vm-int

Sounds good to me

A patch that wraps all sun.misc.Signal methods that may raise IllegalArgumentException with try/except that reraises them as ValueErrors is attached. As a result also signal.getsignal and signal.alarm may raise ValueError which they aren't documented to do, but that's probably better than raising equally undocumented Java based IAE.

I would have liked to create unit tests for these fixes but couldn't figure any easy way to do that. Probably tests could temporarily replace sun.misch.Signal.handle with a method that always raises an IAE but I'm not sure is that worth the effort.

IMHO, we should not be shipping or supporting anything in the sun.* namespace. Jython is sufficiently powerful that users are free and empowered to make use of these non-standard facilities if they wish. 

But they should not be part of the core platform, which should rely only on java.*, javax.* or open source components in other namespaces. sun.misc has no place in jython.

For example, what happens if the code is run on a IBM JVM? Should we support sun.misc.* there?

If users wish to use JVM-specific facilities, they should be prepared to deal with the consequences.

My €0,02.

signal is the one case we use sun.misc services directlty in Jython, but they are also used in JFFI and Guava if available. However, this requires importing signal, so it's not an issue on unsupported platforms.

Fixed as of https://hg.python.org/jython/rev/e909a4641731

Thanks for merging the patch Jim! If I would have implemented it now, I probably would have used a context manager like this instead:

from contextlib import contextmanager

@contextmanager
def map_java_exception(exception_map):
    try:
        yield
    except tuple(exception_map) as err:
        exp = exception_map[type(err)]
        raise exp(err.getMessage())

with map_java_exception({IllegalArgumentException: ValueError}):
    # ...