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.
-Josh Aas
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.
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
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?
Günter
Good idea, I'll look into notifying them of this change.
That is fine with me, I'll make sure we wait until at least 3.5 RC1 to
remove LiveConnect.
Should be before the first Alpha IMHO, so that anyone doing/starting
stuff based on any "official" prerelease wouldn't rely on those
functionalities.
Robert Kaiser
Can you be a bit more specific? Which version(s) of the Sun plugin are
NPAPI-based?
Peter.
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?
-Boris
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.
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.
-Boris
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).
-Boris
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.
Justin
Some banks use Java for netbanking and there are photo-sharing or
printing sites that use signed Java applet to implement multiple image
upload.
Igor
The new NPAPI/NPRuntime-based Java plugin is available for Windows and
Linux starting with Java SE 6 Update 10.
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.
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.
Robert Kaiser
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.
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?
Dan
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.
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.
--
jst
When we opened up mozilla-central (or shortly thereafter), it was turned
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.
--
jst
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)
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?
Deepak
Hi Deepak,
Thanks for getting in touch. At this point I think we are pretty
committed to removing OJI/LiveConnect in Gecko 1.9.2 but the good news
is that Firefox 3.5 should fully support your plugin for some time and
you have a while to port to NPAPI/npruntime before a Gecko 1.9.2
browser is released. I'd be happy to help with any questions you might
have.
-Josh
Hi Josh,
Thanks for the reply. I've been in contact with the Sun team, and they
are unable to provide a release date for the plugin source. As soon as
this change goes through, bleeding edge versions of distros (like
Rawhide for Fedora) will completely lose (open source) java plugin
support.
Is there no way to atleast delay a removal a bit while we plan a
rewrite? With 3.5 due around June, that gives us only ~2-3 months
before things will start breaking, and it wouldn't be sufficient to
plan and write a new plugin from scratch given the current status of
resources...
Cheers,
Deepak
> Is there no way to atleast delay a removal a bit while we plan a
> rewrite? With 3.5 due around June, that gives us only ~2-3 months
> before things will start breaking, and it wouldn't be sufficient to
> plan and write a new plugin from scratch given the current status of
> resources...
This change is being proposed for the release *after* 3.5, which is not due
until early 2010.
--BDS
Hmm, that is what I originally thought too, but then I read that 3.1
is being renamed to 3.5 (https://developer.mozilla.org/devnews/
index.php/2009/03/06/shiretoko-to-be-named-firefox-35/).. which is due
out in June 09. Is the 3.5 that the original email refers to, actually
3.6 (now, after the 3.1->3.5 rename) then?
I didn't realize that Sun's plugin wasn't open source -- curious, and
unfortunate.
Mike
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>
--
Sent from Gmail for mobile | mobile.google.com
Yes, that is my concern. Rawhide is always bleeding edge, and will
switch to using trunk soon after 3.5 is out, and that will break all
Java plugin support in the process.
> I didn't realize that Sun's plugin wasn't open source -- curious, and
> unfortunate.
>
The new plugin will be open sourced at some point once it makes to
OpenJDK 7:
http://openjdk.java.net/projects/jdk7/features/#f647
As early as June/July if that target is achieved. Unfortunately, given
the unknown status at this time, I am not sure how reliable that date
is.
Cheers,
Deepak
> Mike
>
> On 4/16/09, Benjamin Smedberg <benja...@smedbergs.us> wrote:
>
>
>
> > On 4/16/09 3:52 PM, c2h...@gmail.com wrote:
>
> >> Is there no way to atleast delay a removal a bit while we plan a
> >> rewrite? With 3.5 due around June, that gives us only ~2-3 months
> >> before things will start breaking, and it wouldn't be sufficient to
> >> plan and write a new plugin from scratch given the current status of
> >> resources...
>
> > This change is being proposed for the release *after* 3.5, which is not due
> > until early 2010.
>
> > --BDS
> > _______________________________________________
> > dev-planning mailing list
> > dev-plann...@lists.mozilla.org