> > 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?
_______________________________________________ atf-dev mailing list atf-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/atf-dev
