bug-report-can-t-call-static-methods-on-a-java-class-instance

[Attila Szegedi]

Hi Cristoph,

I presume you’re referring to this post: <http://mail.openjdk.java.net/pipermail/nashorn-dev/2013-October/002204.html <http://mail.openjdk.java.net/pipermail/nashorn-dev/2013-October/002204.html>>.

I still stand by the design decisions we made when mapping the Java class/object system to JavaScript in Nashorn. I understand the differing opinions (yours and Tal’s both), and don’t consider them wrong, just having different requirement priorities.

Have you considered that for a large established system, you might not want to change the underlying JavaScript engine? Rhino is yet again in active development, so a hopefully easier way to modernize your system would be to switch from JDK-embedded JavaScript runtime to Rhino as an external library. Ideally you’d just need to touch your script engine factory instantiation code.

Even if you decide to switch to Nashorn, a hopefully smaller change would be to change the methods in your utility classes from being static to being instance methods. That would even keep the change cross-compatible with Rhino. (Of course, this doesn’t help you if you have some external dependencies where you can’t change the methods from static to instance…)

In terms of future advice, there’s one other approach you might take, although unfortunately it won’t be available for JDK 8, just for JDK 9. Namely, in JDK 9 Nashorn can be extended with additional linkers (see e.g. Sundar’s recent post that uses extra linkers to bridge JS to Python https://blogs.oracle.com/sundararajan/entry/nashorn_javascript_access_to_python <https://blogs.oracle.com/sundararajan/entry/nashorn_javascript_access_to_python>). It would be possible to write an additional Dynalink linker that recognizes missing members on POJOs and attempts to look up static methods instead. I know this doesn't help you now, but thought it might be worth mentioning it for completeness so it might help someone who digs this message out of an archive a year from now.

As for “creature” – yes, you were misinterpreting it :-). “A different kind of creature” here could be synonymous with “a different cup of tea”, or “another case”. I use the word as synonymous with “being” (“something created”) without any intended negative overtones. I built fairly complex systems on top of Rhino in the past myself, and for a while both contributed to Rhino and served as the project’s administrator. I certainly have neither the moral ground nor the desire to diss Rhino or its users.

Attila.

> On Feb 4, 2016, at 7:18 AM, Christoph Sauer <christoph.sauer at nuveon.de> wrote:
> 
> Dear Attila,
> 
> i was just evaluating a switch of our huge codebase written in
> Javascript using the Rhino interpreter to Nashorn. We have utility
> classes written in Java that are are passed as objects to help users
> write less code in JS, because that is why we use JS
> in the first place. Those utility objects also contain frequently used
> static methods. Your design decisions will make it impossible for us to
> switch.
> 
> Not only will we have to rewrite our code, we also will have to make
> separate calls to "handles" the user already has. This is against my
> design decision to pursue the ideal of "literate programming". The ideal
> to make code more readable is broken here.  I agree with Tal Liron
> that if a programmer wants to use Java, they would. We use Javascript
> because of the shorthand and the goal towards cleaner code
> without loosing the power of using Java where need be.
> 
> I felt offended to be called a "Creature". I hope I misinterpret you
> sentence here .

> Two years have passed since this post. Have you changed your mind since?
> Will there be at least a "strict" switch like suggested by tal?
> 
> Thanks
> Christoph