Deprecate "language level" concept

[gbrail]

Getting ready to release 1.8.0 soon.

How do people feel about deprecating the "languageVersion" concept? That would mean deprecating the "setLanguageVersion" flag in Context, sending a message that people should be using the default language level (now "VERSION_ECMASCRIPT") and stop relying on Rhino being able to support parts of the JavaScript spec that have changed in ECMAScript, or that Rhino never implemented properly in the first place.

This would at least put us on a path to getting rid of this stuff.

OTOH, there are a LOT of tests that only run on older language levels, so either we don't need those any more (yay) or they need to be updated.

[p-bakker]

See #1776 and #1743 as well

[rPraml]

This topic is somewhat similar to https://www.reddit.com/r/linux/comments/1h7894j/linus_torvalds_completely_broken_x86_64_feature/ 😉.

Yes, I think that you can't identify features based on the language level alone. On the one hand, we have features like proxy support, OTOH we may fix bugs like the "const" issue in a certain rhino version.

If you look at the browsers, it's mainly the job of the Javascript code to react to the different implementations. I think everyone knows the isIE(), isFF() checks etc.

What we need in the long term is an API, that the running code can detect the current rhino version similar to navigator.userAgent. Maybe a global rhino object with versionMajor, minor and point.
And we need something like rhino.hasFeature("PROXY_SUPPORT") to query the current rhino configuration. It might be even possible to enable/disable some features during runtime.

I would also like to question how long we want to continue supporting old javascript versions for backwards compatibility and accept the additional complexity. The Edge browser at the time could still be configured back to IE7 compatibility. But that is now history too.

What I can imagine here, that we can somehow have two rhino versions at classpath and the application can decide, if it wants or needs to use the old/legacy 1.8.x that still provides maximum compatibility with his existing code or if it can use rhino 2 with new features etc. but requires some fixes in existing code
(changing the package from org.mozilla.javascript to org.mozilla.rhino would make this possible, but maybe a dumb idea)

[p-bakker]

@gbrail do you want this case hanging around still?

[gbrail]

Yes -- we haven't agreed on the future of "language levels" and whether some day we can close out support for some of the very oldest ones.