1098129 - [geckoview] Split GeckoView and Browser packages

Status: RESOLVED WORKSFORME

(GeckoView :: General, defect)

Description

[Nick Alexander :nalexander [he/him]]

This is a follow-up to my m-f-d mailing list post [1].  We have two options:

1) Extract GV code, resources, and manifest pieces into a new package (org.mozilla.geckoview);

2) Push Browser (Fennec) code, resources, and manifest pieces into a new package (org.mozilla.fennec, org.mozilla.browser).

These packages are Android libraries: Java packages and Android resources.

If we do 1) we need to:

1) move less code;
2) change more code that is JNI wrapped;
3) only change internally accessed code;
4) move fewer resources;
5) change less of our manifest.

If we do 2) we need to:

1) move more code;
2) change less code that is JNI wrapped;
3) change more externally referenced code (via the Android manifest);
4) move almost all resources;
5) change more of our manifest (and we may find that we *can't* change our manifest).

Moving code is essentially mechanical, *except* where it is JNI wrapped or dynamically accessed.  A quick look at the JNI wrapping suggests that changing the hosting class is not a big deal, but that's a big open question.  We shouldn't be doing the latter at all anyway, but we'll need to make sure this is the case.  So I expect 1 and 2 to be minor issues.

I expect that we will move *all* of our resources over time as we move to an IDE friendy build, so I expect 4 to be a wash.

I personally found modifying the manifest to be fraught with peril: it's hard to make sure nothing breaks because some of these things are consumed externally.  Therefore I think that 3 and 5 are the most challenging things, at least for the organization of the code into packages, and conclude that the approach with the least risk is to extract GeckoView into a new package.

[1] https://mail.mozilla.org/pipermail/mobile-firefox-dev/2014-November/000960.html

Comment 1

[Nick Alexander :nalexander [he/him]]

I discussed this with mfinkle today (in my 1:1) and I think he concurs with me: extracting GeckoView into a new Android package is the least risky approach.  mfinkle notes that GV is technically not yet shipping, so we have free rein to completely change the exposed interface (including the Android and Java package names).

Comment 2

[Nick Alexander :nalexander [he/him]]

snorp: could you comment specifically on how difficult it would be to s/org.mozilla.gecko/org.mozilla.geckoview/ throughout the Gecko <-> Java JNI interface?

Comment 3

[James Willcox (:snorp) ([e-mail]) (he/him)]

(In reply to Nick Alexander :nalexander from comment #2)
> snorp: could you comment specifically on how difficult it would be to
> s/org.mozilla.gecko/org.mozilla.geckoview/ throughout the Gecko <-> Java JNI
> interface?

I don't think changing everything will be too bad. Is it expected that we wouldn't have any JNI in the org.mozilla.browser package? If so, a wholesale switch should be even easier.

Comment 4

[Nick Alexander :nalexander [he/him]]

(In reply to James Willcox (:snorp) ([e-mail]) from comment #3)
> (In reply to Nick Alexander :nalexander from comment #2)
> > snorp: could you comment specifically on how difficult it would be to
> > s/org.mozilla.gecko/org.mozilla.geckoview/ throughout the Gecko <-> Java JNI
> > interface?
> 
> I don't think changing everything will be too bad. Is it expected that we
> wouldn't have any JNI in the org.mozilla.browser package? If so, a wholesale
> switch should be even easier.

My guess is that we will have JNI in both GeckoView (clear) and in the browser (eventually).  For example, I think I see JNI access used in the new Downloads integration.  And I see JNI integration in GeckoAppShell for things that probably aren't part of GV, like for creating "bookmark shortcuts" on the home screen.  It's not clear that we can avoid JNI for those things, but it would be significantly better for GV consumers if they never needed to expose JNI interfaces to Gecko (and could do everything through messages).

I'd be pretty thrilled to see GeckoAppShell's JNI interface teased apart, and it looks like it's not that hard to make that happen (based again on the JNI integration for Downloads); but I just don't know enough about the interface between Gecko and Java to say much with confidence.

Comment 5

[James Willcox (:snorp) ([e-mail]) (he/him)]

(In reply to Nick Alexander :nalexander from comment #4)
> (In reply to James Willcox (:snorp) ([e-mail]) from comment #3)
> > (In reply to Nick Alexander :nalexander from comment #2)
> > > snorp: could you comment specifically on how difficult it would be to
> > > s/org.mozilla.gecko/org.mozilla.geckoview/ throughout the Gecko <-> Java JNI
> > > interface?
> > 
> > I don't think changing everything will be too bad. Is it expected that we
> > wouldn't have any JNI in the org.mozilla.browser package? If so, a wholesale
> > switch should be even easier.
> 
> My guess is that we will have JNI in both GeckoView (clear) and in the
> browser (eventually).  For example, I think I see JNI access used in the new
> Downloads integration.  And I see JNI integration in GeckoAppShell for
> things that probably aren't part of GV, like for creating "bookmark
> shortcuts" on the home screen.  It's not clear that we can avoid JNI for
> those things, but it would be significantly better for GV consumers if they
> never needed to expose JNI interfaces to Gecko (and could do everything
> through messages).
> 
> I'd be pretty thrilled to see GeckoAppShell's JNI interface teased apart,
> and it looks like it's not that hard to make that happen (based again on the
> JNI integration for Downloads); but I just don't know enough about the
> interface between Gecko and Java to say much with confidence.

Yeah, I want to see them separated too, mostly because it's necessary to support multiple windows, which is necessary to make GeckoView actually usable.

Comment 6

[Benjamin Smedberg]

Mass change of bugs in the "Embedding: GRE Core" component in preparation for archiving it. I believe that these are no longer relevant; but if they are, they should be reopened and moved into a component relevant to the code in question.

Comment 7

[Nick Alexander :nalexander [he/him]]

This is still live; moving it under GeckoView.

Comment 8

[Nick Alexander :nalexander [he/him]]

This was mostly done in https://bugzilla.mozilla.org/show_bug.cgi?id=1432235.