We're currently planning to remove OJI, LiveConnect, and the XPCOM plugin API from Gecko 1.9.2. We've worked hard to get to a point where this would be possible and I believe we can make these changes in Gecko 1.9.2.
We are planning to remove those components because they are largely unmaintained, they have few consumers, and there are better alternatives.
To put this change in perspective in terms of a timeline, the earliest a browser with those changes would ship would be approximately Q2 2010.
There are three major consumers of these components - Sun's Java plugin, Steven Michaud's JEP, and the Real player. Sun has worked with us to develop a new Java plugin based on NPAPI and NPRuntime, removing their dependency on OJI/LiveConnect and the XPCOM plugin API. This new plugin is already available for Windows and Linux and will be coming to Mac OS X soon. When the new plugin arrives for Mac OS X it will be an alternative to the JEP. As for Real player, we are working with Real to move them to NPAPI and NPRuntime as well.
Our plan for Java on Mac OS X is to ship the JEP in Firefox 3.5, which should be supported until around Q4 2010. The Gecko 1.9.2 branch will not support JEP. It will use the new Java plugin from Sun and Apple, which will be available before a browser based on Gecko 1.9.2 becomes available.
The question at hand now is when to actually commit the changes to the 1.9.2 branch. The removal is not simple and the improvements we plan to make once those components are out of the way will take time (including major simplification and cleanup in our plugins module). This is not a change we can make at the last minute. I'm inclined to commit the removal in April but I'd appreciate feedback on timing.
The argument against committing now is that we'll go for a period of time on the trunk without a Java plugin on Mac OS X and without Real player on all platforms. However, we are not losing regression coverage because both plugins are being replaced entirely and users that actually need those capabilities can use Firefox 3.5. I can't comment further on the timelines for re-gaining support in Gecko 1.9.2 but they are well within the Gecko 1.9.2 development time frame.
The argument for committing now is that this is a major change, we need time and we're not losing coverage of plugins that we'll be supporting when we ship. It also gives plugin developers more time to develop against the exact set of plugin APIs that will be available to them when we ship.
Fun fact: a basic removal patch for this stuff is ~6MB and growing.
On Fri, Mar 20, 2009 at 20:17, <josh...@gmail.com> wrote: > We're currently planning to remove OJI, LiveConnect, and the XPCOM > plugin API from Gecko 1.9.2. We've worked hard to get to a point where > this would be possible and I believe we can make these changes in > Gecko 1.9.2.
> We are planning to remove those components because they are largely > unmaintained, they have few consumers, and there are better > alternatives.
> To put this change in perspective in terms of a timeline, the earliest > a browser with those changes would ship would be approximately Q2 > 2010.
> There are three major consumers of these components - Sun's Java > plugin, Steven Michaud's JEP, and the Real player. Sun has worked with > us to develop a new Java plugin based on NPAPI and NPRuntime, removing > their dependency on OJI/LiveConnect and the XPCOM plugin API. This new > plugin is already available for Windows and Linux and will be coming > to Mac OS X soon. When the new plugin arrives for Mac OS X it will be > an alternative to the JEP. As for Real player, we are working with > Real to move them to NPAPI and NPRuntime as well.
> Our plan for Java on Mac OS X is to ship the JEP in Firefox 3.5, which > should be supported until around Q4 2010. The Gecko 1.9.2 branch will > not support JEP. It will use the new Java plugin from Sun and Apple, > which will be available before a browser based on Gecko 1.9.2 becomes > available.
> The question at hand now is when to actually commit the changes to the > 1.9.2 branch. The removal is not simple and the improvements we plan > to make once those components are out of the way will take time > (including major simplification and cleanup in our plugins module). > This is not a change we can make at the last minute. I'm inclined to > commit the removal in April but I'd appreciate feedback on timing.
> The argument against committing now is that we'll go for a period of > time on the trunk without a Java plugin on Mac OS X and without Real > player on all platforms. However, we are not losing regression > coverage because both plugins are being replaced entirely and users > that actually need those capabilities can use Firefox 3.5. I can't > comment further on the timelines for re-gaining support in Gecko 1.9.2 > but they are well within the Gecko 1.9.2 development time frame.
> The argument for committing now is that this is a major change, we > need time and we're not losing coverage of plugins that we'll be > supporting when we ship. It also gives plugin developers more time to > develop against the exact set of plugin APIs that will be available to > them when we ship.
> Fun fact: a basic removal patch for this stuff is ~6MB and growing.
Is there any (easy) way to test the plugins at http://plugindoc.mozdev.org/windows-all.html for use of code that would be effected by this change? Or would a direct email to the developers, if they can be located make sense? I know that these plugins represent a fractional percentage of plugin usage. However making a good faith effort that alerts them to the change as early as possible makes sense as they may not closely follow NPAPI development.
> This is not a change we can make at the last minute. I'm inclined to > commit the removal in April but I'd appreciate feedback on timing.
The liveconnect, which uses C, currently includes non-public SpiderMonkey headers. Since SpiderMonkey uses C++ this requires workarounds in the headers to hide C++ constructions incompatible with C to make sure that liveconnect compiles.
With liveconnect removed those headers would inevitably quickly became C++ only on 1.9.2 branch. That would mean that backports to 1.9.1 may require extra efforts. Given the amount of 1.9.1 blockers it would be nice to avoid any potential additional work until, say, RC1. So at least with liveconnect I suggests to wait with its removal until Firefox 3.5 RC1.
There have been postings to other groups (eg. m.d.ext) to ask about the current/future support of JAVA.
I have discussed with a pure JAVA base app (http://www.finchsync.com/index.html [FS]) for sync TB/AB and ICS data (Lightning, Reminderfox etc) to change that application having a Mozilla based support, at least to use the new methods to access TB/AB directly. That would require to adapt Mozilla code with main parts of JAVA based FS or to build an extension and "encapsulated" parts of FS (eg. using their sync based on on .NET etc).
QQ: With the mentioned change for Gecko 1.9.2 can anybody recommand which is the 'best' way to get that done? Any suggestions?
On Mar 20, 10:27 pm, Kevin Brosnan <kbros...@gmail.com> wrote:
> Is there any (easy) way to test the plugins athttp://plugindoc.mozdev.org/windows-all.htmlfor use of code that > would be effected by this change? Or would a direct email to the > developers, if they can be located make sense? I know that these > plugins represent a fractional percentage of plugin usage. However > making a good faith effort that alerts them to the change as early as > possible makes sense as they may not closely follow NPAPI development.
Good idea, I'll look into notifying them of this change.
> > This is not a change we can make at the last minute. I'm inclined to > > commit the removal in April but I'd appreciate feedback on timing.
> The liveconnect, which uses C, currently includes non-public > SpiderMonkey headers. Since SpiderMonkey uses C++ this requires > workarounds in the headers to hide C++ constructions incompatible with > C to make sure that liveconnect compiles.
> With liveconnect removed those headers would inevitably quickly became > C++ only on 1.9.2 branch. That would mean that backports to 1.9.1 may > require extra efforts. Given the amount of 1.9.1 blockers it would be > nice to avoid any potential additional work until, say, RC1. So at > least with liveconnect I suggests to wait with its removal until > Firefox 3.5 RC1.
> Igor
That is fine with me, I'll make sure we wait until at least 3.5 RC1 to remove LiveConnect.
> There are three major consumers of these components - Sun's Java > plugin, Steven Michaud's JEP, and the Real player. Sun has worked with > us to develop a new Java plugin based on NPAPI and NPRuntime, removing > their dependency on OJI/LiveConnect and the XPCOM plugin API. This new > plugin is already available for Windows and Linux
Can you be a bit more specific? Which version(s) of the Sun plugin are NPAPI-based? Peter.
josh...@gmail.com wrote: > To put this change in perspective in terms of a timeline, the earliest > a browser with those changes would ship would be approximately Q2 > 2010.
Is that seriously how late the release after 1.9.1 is planned for? That's rather sad-making. I was hoping we'd do a Gecko release before that. :( Was there a discussion I missed somewhere?
> The argument against committing now is that we'll go for a period of > time on the trunk without a Java plugin on Mac OS X and without Real > player on all platforms. However, we are not losing regression > coverage because both plugins are being replaced entirely and users > that actually need those capabilities can use Firefox 3.5.
We might be using trunk testing coverage in general, though, if people can't use it because sites they rely on don't work without Java.... Do we have any data on this?
On Mar 22, 5:18 pm, Boris Zbarsky <bzbar...@mit.edu> wrote:
> josh...@gmail.com wrote: > > To put this change in perspective in terms of a timeline, the earliest > > a browser with those changes would ship would be approximately Q2 > > 2010.
> Is that seriously how late the release after 1.9.1 is planned for? > That's rather sad-making. I was hoping we'd do a Gecko release before > that. :( Was there a discussion I missed somewhere?
This is an estimate of mine, I haven't heard any formal plans. Planned is < actual in almost every case anyway, and Q2 2010 is less than 1 year after 1.9.1. I'd be extremely surprised if we saw a 1.9.2 release before March of 2010.
> > The argument against committing now is that we'll go for a period of > > time on the trunk without a Java plugin on Mac OS X and without Real > > player on all platforms. However, we are not losing regression > > coverage because both plugins are being replaced entirely and users > > that actually need those capabilities can use Firefox 3.5.
> We might be using trunk testing coverage in general, though, if people > can't use it because sites they rely on don't work without Java.... Do > we have any data on this?
I think the number of Mac OS X trunk nightly users that rely on Java so much that they can't occasionally use Firefox 3.5 for a bit is very small. I'm not worried about their impact on overall nightly testing coverage. I have no idea where we'd get data on that.
josh...@gmail.com wrote: > I think the number of Mac OS X trunk nightly users that rely on Java > so much that they can't occasionally use Firefox 3.5 for a bit is very > small. I'm not worried about their impact on overall nightly testing > coverage. I have no idea where we'd get data on that.
We can start by getting data on how many trunk OSX users we have to start with.... Then we could consider widely asking this question and see what responses we get from them.
josh...@gmail.com wrote: > I think the number of Mac OS X trunk nightly users that rely on Java > so much that they can't occasionally use Firefox 3.5 for a bit is very > small. I'm not worried about their impact on overall nightly testing > coverage. I have no idea where we'd get data on that.
And it's not just "occasionally use Firefox 3.5 for a bit". It's a matter of having to maintain a separate profile for that use (because going back and forth across versions on a given profile is NOT something one ever wants to do), remembering to always start Firefox 3.5 when going to some particular sites, remembering to not use it for going to other sites, having bookmarks and history forked, etc.
Basically, if there were even one site that needs me to use Java, I'd not bother running trunk builds at all in the above setup. It'd just be too much pain.
I think none of the sites I care about in fact use Java, but I'm not a good representative sample (e.g. 60+% of my web browsing is Bugzilla).
> josh...@gmail.com wrote: >> I think the number of Mac OS X trunk nightly users that rely on Java >> so much that they can't occasionally use Firefox 3.5 for a bit is very >> small. I'm not worried about their impact on overall nightly testing >> coverage. I have no idea where we'd get data on that.
Crazy idea -- turn it off now, maybe just for a week or two, and see if anyone screams bloody murder?
> Basically, if there were even one site that needs me to use Java, I'd > not bother running trunk builds at all in the above setup. It'd just be > too much pain.
Yeah. I'd guess that user are largely divided into 2 buckets... Those that simply never encounter Java online, and those who use it frequently (likely because their employer/school has some tool that requires it). How big and how important that latter bucket is, I don't know.
FWIW, I disabled Java in my daily-use profile a long time ago. About the only things I've run across (rarely) that need it are a few online games, and demos on educational pages.
> > There are three major consumers of these components - Sun's Java > > plugin, Steven Michaud's JEP, and the Real player. Sun has worked with > > us to develop a new Java plugin based on NPAPI and NPRuntime, removing > > their dependency on OJI/LiveConnect and the XPCOM plugin API. This new > > plugin is already available for Windows and Linux
> Can you be a bit more specific? Which version(s) of the Sun plugin are > NPAPI-based? > Peter.
The new NPAPI/NPRuntime-based Java plugin is available for Windows and Linux starting with Java SE 6 Update 10.
On Mon, Mar 23, 2009 at 5:27 AM, Igor Bukanov <i...@mir2.org> wrote: > Some banks use Java for netbanking and there are photo-sharing or > printing sites that use signed Java applet to implement multiple image > upload.
My bank is one of those stupid banks. (It's a subsidiary of Danske bank and the java requirement was introduced after Dasnke bought my bank, so I'd imagine it's a feature of their somewhat widely spread Nordic banking services).
It turns out for very basic operations if you're incredibly clever you can find a mobile page that works, but it requires either speaking some obscure language or speaking that obscure language and hacking urls.
OTOH, as w/ bz, I'm not the target audience, since I can't run a modern gecko on my mac anyway.
josh...@gmail.com wrote: > On Mar 22, 5:18 pm, Boris Zbarsky<bzbar...@mit.edu> wrote: >> josh...@gmail.com wrote: >>> To put this change in perspective in terms of a timeline, the earliest >>> a browser with those changes would ship would be approximately Q2 >>> 2010.
>> Is that seriously how late the release after 1.9.1 is planned for? >> That's rather sad-making. I was hoping we'd do a Gecko release before >> that. :( Was there a discussion I missed somewhere?
> This is an estimate of mine, I haven't heard any formal plans. Planned > is< actual in almost every case anyway, and Q2 2010 is less than 1 > year after 1.9.1. I'd be extremely surprised if we saw a 1.9.2 release > before March of 2010.
Note that the actual intention of the post-1.9.0 smaller-release plan was to release more often, i.e. about every 6 months. Unfortunately we largely failed to do that with 1.9.1 but maybe we manage to really improve this and and come nearer towards the actual plan next time around.
> josh...@gmail.com wrote: >> This is an estimate of mine, I haven't heard any formal plans. Planned >> is< actual in almost every case anyway, and Q2 2010 is less than 1 >> year after 1.9.1. I'd be extremely surprised if we saw a 1.9.2 release >> before March of 2010.
> Note that the actual intention of the post-1.9.0 smaller-release plan > was to release more often, i.e. about every 6 months. Unfortunately we > largely failed to do that with 1.9.1 but maybe we manage to really > improve this and and come nearer towards the actual plan next time around.
I thought the original plan was to release smaller changes more often in minor releases, and at the same time work on Mozilla2. But I haven't heard anything about Mozilla2 in the last few months. But I have missed an annoucement where it was declared dead or postponed... Peter.
> We're currently planning to remove OJI, LiveConnect, and the XPCOM > plugin API from Gecko 1.9.2. We've worked hard to get to a point where > this would be possible and I believe we can make these changes in > Gecko 1.9.2.
> We are planning to remove those components because they are largely > unmaintained, they have few consumers, and there are better > alternatives.
What effect will this have on Gecko application extensions that contain Java code? That they would need source-level changes? That they would stop working entirely?
> > We're currently planning to remove OJI, LiveConnect, and the XPCOM > > plugin API from Gecko 1.9.2. We've worked hard to get to a point where > > this would be possible and I believe we can make these changes in > > Gecko 1.9.2.
> > We are planning to remove those components because they are largely > > unmaintained, they have few consumers, and there are better > > alternatives.
> What effect will this have on Gecko application extensions that contain > Java code? That they would need source-level changes? That they would > stop working entirely?
There are no functional regressions that I'm aware of, nor do I know of any required code changes under the new plugin. You can even still access Java classes from JS in the same way that it was possible before iirc, though the details of that aren't clear to me. I don't know much about that functionality, I just recall that it was preserved. So as far as extensions relying on a particular Java plugin goes, I don't think there are any issues.
Justin Dolske wrote: > Crazy idea -- turn it off now, maybe just for a week or two, and see if > anyone screams bloody murder?
When we opened up mozilla-central (or shortly thereafter), it was turned off (though source still in the tree), for quite some time in fact. And worse, if a Mac user then went to a website that actually used Java, they'd crash (IIRC we even shipped Firefox 3.1 alpha 1 with this). Nobody really screamed then, so I don't think we'll learn much more if we do it again now.
Justin Dolske wrote: > Crazy idea -- turn it off now, maybe just for a week or two, and see if > anyone screams bloody murder?
When we opened up mozilla-central (or shortly thereafter), it was turned off (though source still in the tree), for quite some time in fact. And worse, if a Mac user then went to a website that actually used Java, they'd crash (IIRC we even shipped Firefox 3.1 alpha 1 with this). Nobody really screamed then, so I don't think we'll learn much more if we do it again now.
josh...@gmail.com wrote: > On Mar 23, 9:50 am, Dan Mosedale<dm...@mozilla.org> wrote: >> On 3/20/09 5:17 PM, josh...@gmail.com wrote:
>>> We're currently planning to remove OJI, LiveConnect, and the XPCOM >>> plugin API from Gecko 1.9.2. We've worked hard to get to a point where >>> this would be possible and I believe we can make these changes in >>> Gecko 1.9.2. >>> We are planning to remove those components because they are largely >>> unmaintained, they have few consumers, and there are better >>> alternatives. >> What effect will this have on Gecko application extensions that contain >> Java code? That they would need source-level changes? That they would >> stop working entirely?
> There are no functional regressions that I'm aware of, nor do I know > of any required code changes under the new plugin. You can even still > access Java classes from JS in the same way that it was possible > before iirc, though the details of that aren't clear to me. I don't > know much about that functionality, I just recall that it was > preserved. So as far as extensions relying on a particular Java plugin > goes, I don't think there are any issues.
There is one functional difference, and that's for binary extensions that explicitly use the LiveConnect library in Mozilla to talk directly from C to Java. That will no longer work, and we have no intentions to provide equivalent functionality directly from C going forward, largely due to lack of owners of such code, which is what got us here in the first place.
Code that depends on such functionality basically need to either funnel through JS to benefit from the NPRuntime layer between the browser and Java, or ship with additional libraries that do the C to Java bridging.
> On Mon, Mar 23, 2009 at 5:27 AM, Igor Bukanov <i...@mir2.org> wrote: >> Some banks use Java for netbanking and there are photo-sharing or >> printing sites that use signed Java applet to implement multiple image >> upload.
> My bank is one of those stupid banks. (It's a subsidiary of Danske > bank and the java requirement was introduced after Dasnke bought my > bank, so I'd imagine it's a feature of their somewhat widely spread > Nordic banking services).
I don't know a single bank where I live (Denmark) which does not use Java (well, those who use ActiveX instead doesn't count)
> We're currently planning toremoveOJI, LiveConnect, and the XPCOM > plugin API from Gecko 1.9.2. We've worked hard to get to a point where > this would be possible and I believe we can make these changes in > Gecko 1.9.2.
> We are planning toremovethose components because they are largely > unmaintained, they have few consumers, and there are better > alternatives.
> To put this change in perspective in terms of a timeline, the earliest > a browser with those changes would ship would be approximately Q2 > 2010.
> There are three major consumers of these components - Sun's Java > plugin, Steven Michaud's JEP, and the Real player. Sun has worked with > us to develop a new Java plugin based on NPAPI and NPRuntime, removing > their dependency onOJI/LiveConnect and the XPCOM plugin API. This new > plugin is already available for Windows and Linux and will be coming > to Mac OS X soon. When the new plugin arrives for Mac OS X it will be > an alternative to the JEP. As for Real player, we are working with > Real to move them to NPAPI and NPRuntime as well.
> Our plan for Java on Mac OS X is to ship the JEP in Firefox 3.5, which > should be supported until around Q4 2010. The Gecko 1.9.2 branch will > not support JEP. It will use the new Java plugin from Sun and Apple, > which will be available before a browser based on Gecko 1.9.2 becomes > available.
> The question at hand now is when to actually commit the changes to the > 1.9.2 branch. The removal is not simple and the improvements we plan > to make once those components are out of the way will take time > (including major simplification and cleanup in our plugins module). > This is not a change we can make at the last minute. I'm inclined to > commit the removal in April but I'd appreciate feedback on timing.
> The argument against committing now is that we'll go for a period of > time on the trunk without a Java plugin on Mac OS X and without Real > player on all platforms. However, we are not losing regression > coverage because both plugins are being replaced entirely and users > that actually need those capabilities can use Firefox 3.5. I can't > comment further on the timelines for re-gaining support in Gecko 1.9.2 > but they are well within the Gecko 1.9.2 development time frame.
> The argument for committing now is that this is a major change, we > need time and we're not losing coverage of plugins that we'll be > supporting when we ship. It also gives plugin developers more time to > develop against the exact set of plugin APIs that will be available to > them when we ship.
> Fun fact: a basic removal patch for this stuff is ~6MB and growing.
> -Josh Aas
Hi,
My name is Deepak Bhole. I am the maintainer of the IcedTea Java plugin, which is part of the IcedTea project (http:// icedtea.classpath.org/wiki/Main_Page). It is the default Java plugin installed with Fedora, Ubuntu and other common distros, and the only open source one afaik that supports LiveConnect.
The plugin work began a while ago, and hence uses OJI. Converting it to npruntime would take significant efforts (pretty much a rewrite for all intents and purposes). I understand that you worked with Sun to remove the OJI dependence in the new plugin, but that plugin is closed source at the moment. Would it be possible for you to reconsider removing OJI at least until another open source option becomes available?
|
