1. It includes jdk13 package to make the jar usable.
2. It excludes e4x classes as they are useless without xbean.jar and xbean
is several times bigger then the whole js.jar.
New interface RefCallable simplifies implementation of function-call-as-rvalue
in Java code. In addition native objects is required to implemet only Callable
interface, not Function, to serve as target of () operator.
2. Context.getApplicationClassLoader() now uses ContextFactory.getApplicationClassLoader() and also tries ContextFactory subclass as the last resort of loader guessing.
> I work in a group that re-packages the Rhino Debugger as part of a set
> of "C"/JavaScript-based configuration tools for developing embedded
> software. We have had a long-standing problem with setting
> breakOnException, breakOnEnter, and breakOnReturn flags within the debug
> engine and not having them in sync with the gui debug menu checkboxes. I
> have fixed this for our use and have attached the updated Main.java
> file. The change simply sets the checkbox selected state along with the
> dim flags.
Patch for wrapping unchecked exceptions from Java method invocations
Recently we had a problem with a NPE occurring in a Java method - it wasn't
wrapped into WrappedException and subsequently we did not see the interpreter
script stack traces. This is because unchecked throwables aren't wrapped into
InvocationTargetException. I changed the relevant code in MemberBox.java to
wrap all exceptions (checked and unchecked) into WrappedException. BTW, this is
now consistent with how JavaMembers.get() and JavaMembers.put() work - they
also wrap all exceptions into WrappedException, not just
InvocationTargetException.
"Scriptable target" argument to Ref.(get|set|has|delete) methods. The idea was
to optimize away in many cases creation of Ref instances, but given that modern
JVM can GC short-lived objects efficiently it does not sound right to have code
complexity now in the hope of slightly more efficient implementation later.
I assume "functionName" in BaseFunction could also undergo a similar treatment
of being replaced with an abstract getFunctionName() method, couldn't it? The
function name is either calculable from other data (FieldAndMethods, overloaded
case of NativeJavaMethod*, NativeJavaConstructor, InterpetedFunction) or fixed
(NativeRegExpCtor) in lots of subclasses.
