Wednesday 11.10-12.00

Add this session to your schedule

While developing Nashorn, we indeed run into a bunch of issues requiring a design decision when it came to integrating the JavaScript language - a prototype-based, classless language, with no fixed-size typed arrays, no concept of static access levels, no namespaces. Since there's no point in having a JS on JVM if it lives in its own little isolated bubble, we had to ensure it integrates with the platform. And then we had to answer all those questions I posed in the abstract and then some. While we're making every effort to hide plumbing that can be hidden so that developers using Nashorn don't have to worry about them, we also don't try to create a fallacious environment that papers over fundamental differences between the languages. For that reason, some of the design decisions might be a bit surprising - like the fact that the correct representation for a POJO in JSON is undefined and needs an explicit replacer function instead for different behavior, that arrays can't be autoconverted either way, that it's better to not pretend you can "import packages" into your JS program, and so on. We need to educate the developer community, show them what is the recommended and correct way to handle various underlying platform idioms in order to make sure they can confidently develop programs in JS that take full advantage of the underlying Java platform.