Re: FW: [Fwd: Re: [atf-dev] JavaXPCOM ownership]

[Olivier Rossel <olivier.rossel@xxxxxxxxx>]

XPCOM is going to change, and in some cases change quite radically: we're

dropping all pretense of binary compatibility between major releases in

order to improve performance characteristics, and we're likely to eventually

change to a garbage-collected runtime.

Since the JS representation of objects is the one the web sees and the one

that is actively QAed, I really strongly suggest that future bridges work on

the JS level: this is what the NPAPI does already in the Sun Java plugin; I

don't know whether it's possible to use that same code in Eclipse or not,

but that's the kind of API you need to end up with, if you want stability.

I am not sure I get the idea behind that "JS-level API".
Could it mean that JavaXPCOM should evolve into a Rhino-based library?