There is a not-so-pretty workaround though. Nashorn routes delete on jdk.nashorn.api.scripting.JSObject instances to removeMember method.
If you can wrap your Java objects as JSObjects [ may be just for delete], then you can customize delete on your objects. var myJavaObj = .... ; // myJavaObj is an instance of MyJavaObject linked by pluggable Dynalink linker MyJavaObjectLinker myJavaObj.foo = "hello"; // set property handled by MyJavaObjectLinker delete jsObj(myJavaObj).foo; // jsObj is a function returns a JSObject wrapper of myJavaObj. The JSObject wrapper can override removeMember. // or a special property on myJavaObj to return a JSObject wrapper delete myJavaObj._.foo; // "_" property returns a JSObject wrapper on myJavaObject which then takes care of "delete" -Sundar On 5/25/2016 9:50 AM, Sundararajan Athijegannathan wrote: > I recall that we did discuss about the StandardOperation set. "delete" > and "iterator" were discussed at one point. But, languages are very > different and difficult to generalize to include all operations. For eg. > Python's del does not return boolean, ECMAScript delete returns boolean > and sometime throws TypeError (strict mode)! > > Hence dynalink has Operation as interface and StandardOperation as one > implementation. In the hindsight, it *may* be desirable to include > delete. But, it is too late for jdk9 to update dynalink API :( > > Best, > > -Sundar > > > On 5/24/2016 3:41 AM, Marc Downie wrote: >> Dear all, >> >> First of all, many thanks for this year's JEP-276 / jdk.dynalink >> refactoring. We've been enjoying all of the benefits of installing a custom >> Linker without having to maintain a fork of Nashorn just to get it >> installed. We can massage and customize the face that Java objects present >> to JavaScript almost completely. >> >> The one thing that remains that I can't manipulate is the behavior of Java >> objects with respect to *delete*. In short we have elaborately customizable >> *dyn:setProp*, *setElem*, *getProp*, *getElem* that we can bridge to other >> languages and runtimes, but no *dyn:deleteX. *Is this by omission or by >> design? >> >> best, >> >> Marc
