Summary

Reading the typed-null marker SomeJavaClass.null permanently breaks SomeJavaClass.valueOf(...) for the remaining life of the isolate — it silently starts returning null for every argument.

The .null getter deletes the class's Java static valueOf and replaces it with an internal shim that unconditionally returns null. Because the marker object is the constructor function itself, that shim lands directly on the class.

This is not specific to any one class; it hits any class that has both a static valueOf and gets a typed null taken from it. In practice java.lang.String.valueOf(...) is broken from app startup in most apps, because passing java.lang.String.null is the idiomatic way to disambiguate a null argument.

Reproduction

Any app, evaluated in the runtime (here via the inspector):

String(java.lang.Double.valueOf(1))   // "1.0"      <- correct
typeof java.lang.Double.null          // "function" <- touch the marker once
String(java.lang.Double.valueOf(1))   // "null"     <- now permanently broken
java.lang.Double.toString(1)          // "1.0"      <- other statics unaffected

The property is visibly deleted and re-added — valueOf moves from its metadata slot to the end of the key order:

Object.getOwnPropertyNames(java.lang.Double).indexOf("valueOf")  // 19 (of 35) before
Object.getOwnPropertyNames(java.lang.Double).indexOf("valueOf")  // 34 (of 35) after

java.lang.String shows the post-mutation shape from startup in any app that uses java.lang.String.null:

String(java.lang.String.valueOf(7))                 // "null"
Object.getOwnPropertyNames(java.lang.String)
// [... "copyValueOf", "format", "join", "extend", "CASE_INSENSITIVE_ORDER", "null", "class", "valueOf"]
//                                                                                          ^ moved to last

Expected vs actual

• Expected: java.lang.String.valueOf(42) → "42"; taking SomeClass.null has no effect on that class's static methods.
• Actual: returns null, silently, forever after the first read of .null on that class.

Root cause

test-app/runtime/src/main/cpp/MetadataNode.cpp, NullObjectAccessorGetterCallback (the getter installed for .null):

auto thiz = info.This();          // the class constructor function itself
...
auto funcTemplate = FunctionTemplate::New(isolate, MetadataNode::NullValueOfCallback);
thiz->Delete(context, V8StringConstants::GetValueOf(isolate));
thiz->Set(context, V8StringConstants::GetValueOf(isolate),
          funcTemplate->GetFunction(context).ToLocalChecked());
...
info.GetReturnValue().Set(thiz);  // the marker IS the ctor function

and NullValueOfCallback is simply:

args.GetReturnValue().SetNull();

So the "make this object read as null" shim is installed on the class object rather than on a distinct marker object, and it overwrites a real Java static of the same name. The guard around it (hiddenVal.IsEmpty()) only makes it happen once — it does not make it reversible.

Suggested direction

Return a dedicated marker object from the .null getter instead of the constructor function itself — e.g. an empty object carrying the same MetadataNodeKeys internal fields plus the null-node private value, with valueOf installed on that. The argument-resolution path already identifies typed nulls via the NULL_NODE_NAME private value, so it should not need the marker to be the class object.

Failing that, at minimum the shim should not clobber a name that exists in the class's metadata.

Affected versions

• Reproduced on @nativescript/android 9.0.x (V8 10.3.22), the currently published runtime.
• Also reproduces unchanged on a local branch running V8 14.9.207.39, so it is independent of the V8 version — this is long-standing, not a recent regression.

Tested on an API 35 arm64 emulator.