cast until after the double in question has been determined to be
finite, not NaN, etc. This may make the code a little more XP for
platforms like BSD and Alpha Linux that don't like casting strange
values to int. Thanks go to Uncle George <gatgul@voicenet.com> and
hankin <hankin@consultco.com> for their porting work.
+ Changed the way JS wrapper functions for Java instance methods are constructed.
Previously, these were computed the first time that an instance method was
accessed for a particular JavaObject and cached in the native, private portion
of that JavaObject. However, the required call to JS_AddRoot() causes an root
to appear as a link in a cyclical graph, leading to uncollectible objects, i.e.
the JavaObject has a root pointer to the function object and the function has
a parent that points back to the JavaObject. Now, we compute the functions
at the time a class is reflected and use JS_CloneFunctionObject() each time
a JS wrapper function is needed, which is slower, but avoids this GC problem.
return the same Java object, both for efficiency and so that the '=='
operator works as expected in Java when comparing two JSObjects.
However, it is not possible to hold a reference to a Java object without
inhibiting GC of that object, at least not in a way that is portable
to all vendor's JVMs, i.e. a weak reference. So, for now, JSObject identity
is broken.
- Revise exception handling runtime info (now called trynotes a la srcnotes)
for more efficient loop control under JSOP_THROW. Avoid all uses of catch
and throw while at it, to make C++ lusers happy.
- Combine JSStackFrame.exception with rval, and rename
JSStackFrame.exceptPending to be ...throwing.
- Optimize JS_TypeOfValue a bit.
- Name, control flow, whitespace, etc. cleanup.
all element access expressions to strings, e.g. so that obj["3"] and
obj[3] refer to the same property for a JavaArray object.
= Return false when using 'delete' operator on JavaArray objects.
means that we had to switch from using NSPR hash tables to a private version.
The new jsj_hash.c file is derived from plhash.c, but it provides for an additional
argument to be passed to the hash key comparison function. This capability
is used to pass in the JNIEnv pointer.
On shutdown, LiveConnect now removes all references to Java objects and classes,
so that the JVM might be able to GC them.
command' hack - the resolver defined by js.c would get called to look
up 'assign' - and on Irix systems, it would find the 'assign' command
in the current path, and decide to define a function called 'assign'
in the global object that would run the assign command. Then when an
attempt was made to assign a property to the global object, the assign
command would get run, and unexpected behavior followed.
hint of JSTYPE_NUMBER. This is a case that nobody cares about, but it's
used in a LiveConnect test case.
Added more registered Java packages for reduced server-roundtrips. Also,
loosened restrictions on accessing unregistered packages under "java" and
some of the other packages, in case Sun or somebody adds a "java.fooBar"
package.
all enumerated property names as strings, as was the case in JS1.1, instead
of the modern (>=JS1.2) behavior of allowing either string or integer property
names.
These project files were just checked in temporarily and are replaced by the
LiveConnectShell project files located in the js/ref/liveconnect subdirectory.
This new vendor-neutral version of LiveConnect is designed to replace the older
one in the js/jsj directory, which only works with the Netscape JVM. It is part
of the OJI initiative.
There was a check in our mini-nspr against asking the OS time services
what the DST offset was for time 0... but the check didn't do what the
comment said it did. So we got the wrong DST offset for... (drum roll
please) the two seconds on either side of the eve of 1970 GMT.
I have a similar fix ready for prmjtime.c, but I'll wait until the
stability freeze settles down.
Fix 123724 hippo: problems declaring var in an eval statement
This ended up being more complex than I initially thought it would be.
See comments in jsparse.c.
This comment is for checkin of version 1.8: mistakenly gave wrong comment
for that version.
Fix 123724 hippo: problems declaring var in an eval statement
The problem was that Variable() in jsparse.c used the scope from calling
js_FindVariableScope to determine whether or not to convert the operator
to GETVAR, but LookupArgOrVar did not. This caused a mismatched set and
get in the code generated from the eval script due to the presence of the
var in the function frame.
on activation (120172, mlm).
- Use #ifdef CHECK_RETURN_EXPR to hide CheckFinalReturn as well as its calls.
- 80th column tyranny, typedef symmetry, other cosmetics.
treat all the 'arguments arguments' as if they were concatenated
together as a comma-separated list, and treat the list as if it were
the arguments list in a normal function declaration. That is, allow
comments, arbitrary whitespace, etc.
Fixed by introducing a TokenStream instance in the Function contructor
code.
It now passes all of the tests in 15.1.2.2-1 (except that parseInt
still has the .length property, which is a different bug) - so I'll
close the bug.
Still possibly at issue is whether we conform to ECMA language about
decimal numbers that are too large to fit in a double. I treat
decimal digits after the 20th as zero, but there could be some
floating-point rounding wackiness going on. In particular - are we
doing the right thing for numbers that are powers of 2, but larger
than 2^54, that are representable in a double?
Array.prototype.sort(comparefn) was casting the result of the compare
to an int, which lost when the compare function returned (ecma-valid)
strange double values. These now get clamped to -1, 0, 1.
Added support in the javascript shell for the #! unix script hack; if
the first line read by the shell (from a file, not interactive) starts
with #, the line is treated as a comment.
This should make
#!/usr/bin/js work...
character strings; added a js_DeflateString call. Thanks to gcc 2.8.1
for catching this - it complained about "char format, different type
arg (arg 4)" - which means that it looked in the (printf-style) format
string and checked type against it. Wow.
a localized string from the os for toLocaleString. The time struct
used to interface to the os time-formatting functions only takes a
16-bit year, so we map to an equivalent year (for getting the timezone
string) or clamp for years outside that range.
reserved words, and changed the versioning check that previously
applied to 'export' to accept any 'ecma' version... which means that
export becomes a keyword for the default version. Does this mean
we'll need to unreserve all the java keywords? Not sure we want to do
that...
