Forwarding
to the ATF dev-team. Let’s continue the discussion here…
Thanks
for letting us know,
Roy
From:
Jacek Pospychała
Sent: Thursday, September 10, 2009 9:27 AM
To: Roy Ganor
Subject: [Fwd: Re: [atf-dev] JavaXPCOM ownership]
Roy,
see below, not the news we'd like to hear..
-------- Wiadomość oryginalna --------
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 9/4/09 6:07 PM, Jacek Pospychala wrote:
> hi Benjamin,
>
> I step in to maintain JavaXPCOM. I very appreciate Javier's work and
> it's absolutely worth continuing.
> To not mention it's fundamental role in ATF existence, there's also a
> variety of other projects that also
> depend on it.
> Since it's friday night here, let's discuss the details the coming week,
> I'll get in touch with you.
How much are you technically familiar with JavaXPCOM? I see you're cc'ed on
a few Mozilla embedding bugs. Are you going to be comfortable reviewing patches?
>>From ATF standpoint, we would very much want to keep JavaXPCOM where it
> is now, in XULRunner builds and as part of Mozilla core. This extremely
> simplifies XULRunner adoption, because adopting project (we, Olivier)
> don't have to worry about matching JavaXPCOM to XULRunner versions and
> users have just one package to download (will have, once bug
> https://bugzilla.mozilla.org/show_bug.cgi?id=507575 is fixed).
> In Eclipse it's already difficult to adopt XULRunner, because of
> licensing issues it can't be packaged with Eclipse projects like ATF.
We've already decided to remove JavaXPCOM from our core distribution: it's
something that can be implemented in extension/embedding code; it's not
something that majority of XULRunner clients need to have; it's a fair bit
of build and maintenance work for release engineering; and it doesn't have
any unit tests.
> I breifly
> looked at existing JavaXPCOM bugs (about 35 of them), however I didn't
> run into any bug that would be clearly caused by JavaXPCOM. The
> biggest issue that we suffer from is XULRunner crashes lead to whole
> Java
> Virtual Machine crashes.
> This complicates the development and makes it difficult to package ATF
> with other Eclipse projects, because there's nothing worse than
> crashing application.
We are working on a multi-process browsing model now, although we don't have
any solid ideas how this will interact with embedders. Depending on what
kind of data you need from XULRunner, you could also implement multi-process
on the Java side.
Or we could just keep fixing bugs as they happen... the ones you are most
likely to hit are the ones that don't show up in browsing contexts and are
somehow specific to the embedding/JavaXPCOM/Eclipse environment.
> On the other hand we can't easily switch from one Java-XULRunner bridge
> to other because we tightly depend on current API.
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.
- --BDS
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFKqBAVSSwGp5sTYNkRAvCrAKCABAw7UluTZwc2FgUxFlQx541rvgCgqBSD
h6blABK94P1354Ym6rawXq4=
=0//s
-----END PGP SIGNATURE-----
