[jitsi-dev] Shipping a private JRE, why?


#1

Hi there,

I´ve downloaded and installed the latest greatest ´stable´ Jitsi from
https://download.jitsi.org/jitsi/windows/jitsi-1.0-latest-x86.exe

This on a system with XP SP3, the latest hotfixes delivered via
WindowsUpdate, and a Java 7 JRE also updated to the latest version
(Java7 update 7).

···

------
C:\>java -version
java version "1.7.0_07"
Java(TM) SE Runtime Environment (build 1.7.0_07-b10)
Java HotSpot(TM) Client VM (build 23.3-b01, mixed mode, sharing)
------

To my surprise when I inspected the Jitsi folder (I´m just curious :slight_smile:
I found that the windows installation packages its own private JRE
under C:\Program Files\Jitsi\jre

And by executing java.exe -version on that folder I found that it is:
C:\Program Files\Jitsi\jre\bin>java.exe -version
java version "1.6.0_24"

So... several questions come to mind:

1. Why package a March 2011 version of Java6 (if what you indeed need
is Java6 and there is some reason not to use Java7) when the latest
Java6 version currently is Java 6 update 35
http://www.java.com/en/download/manual_v6.jsp which likely includes
performance improvements, bugfixes along with security updates?

2. Why not Java 7?

3. Even better than all the above, why package a private JRE at all?:
My proposal (if Jitsi were my software) would be to create a small
´postinstall´ script that is immediately run after Jitsi is installed
and which would check the installed version of Java. If the minimum
system requirements (ie Java6) aren´t met, then users would be
presented with a dialog reading something like "This application uses
Java. We need to install (or update) it. Click OK for the download to
proceed" then either attempt to download Java automagically from
Java.com, or open a web browser pointing towards
http://java.com/inc/BrowserRedirect1.jsp?locale=en

4. I moved away the jre folder (outside the app) and attempted
launching the app with the installed Java7 JRE... it launched just
fine. (which would prove my point#2, it works with Java7 apparently
-just launched the app, didn´t attempt any calls, btw).

My view is that doing #3 would ensure that:

-Jitsi is always used and tested with the latest greatest available JRE
-Less download size (no longer needed to package a JRE internally)
-Less problems (no old JRE bugs masquerading as Jitsi bugs)
-No system pollution with multiple versions of the JRE scattered on the HD...

Of course, this is just my humble opinion....

Thoughts? comments?
FC
--
During times of Universal Deceit, telling the truth becomes a revolutionary act
- George Orwell


#2

1. Why package a March 2011 version of Java6 (if what you indeed need
is Java6 and there is some reason not to use Java7) when the latest
Java6 version currently is Java 6 update 35
http://www.java.com/en/download/manual_v6.jsp which likely includes
performance improvements, bugfixes along with security updates?

The current version of Java 6 distributed as part of Jitsi on Windows satisfies our requirements. That said, it's a good idea to update to the latest stable release for the reasons you've mentioned so please feel free to open a new issue and we'll try to do it as soon as possible (in accord with our other priorities).

2. Why not Java 7?

There are several pieces of Jitsi functionality which do not work as expected on Java 7.

3. Even better than all the above, why package a private JRE at all?:
My proposal (if Jitsi were my software) would be to create a small
´postinstall´ script that is immediately run after Jitsi is installed
and which would check the installed version of Java. If the minimum
system requirements (ie Java6) aren´t met, then users would be
presented with a dialog reading something like "This application uses
Java. We need to install (or update) it. Click OK for the download to
proceed" then either attempt to download Java automagically from
Java.com, or open a web browser pointing towards
http://java.com/inc/BrowserRedirect1.jsp?locale=en

As vaguely hinted above, by shipping a private JRE we have greater certainty that Jitsi on Windows performs for our users as it does for us i.e. it meets our stability and performance requirements.

Another advantage is that the setup experience is greatly simplified.

A possible disadvantage of the approach that you describe is that we do not have it implemented at present. Please feel free to contribute such an implementation, we'll gladly review it.

4. I moved away the jre folder (outside the app) and attempted
launching the app with the installed Java7 JRE... it launched just
fine. (which would prove my point#2, it works with Java7 apparently
-just launched the app, didn´t attempt any calls, btw).

Jitsi on Windows is written to attempt to discover a suitable system-wide JRE, it just prefers a private one without making it mandatory.

Re: "it launched just fine", the fact that Jitsi launched does not mean that all functionality works as expected.

My view is that doing #3 would ensure that:

-Jitsi is always used and tested with the latest greatest available JRE

As stated above, while it could be the latest and greatest JRE for Oracle, it could very well not be any of these for Jitsi.

-Less download size (no longer needed to package a JRE internally)

Jitsi on Windows uses LZMA to compress the setup which gives it great compression ratio. Additionally, Jitsi employs auto-update functionality which downloads the deltas/differences between the currently installed version and the latest available version thus often bringing the download size to much less than a megabyte.

-Less problems (no old JRE bugs masquerading as Jitsi bugs)

At the time of this writing, we do not have reports of Jitsi not performing as expected because of JRE bugs.

-No system pollution with multiple versions of the JRE scattered on the HD…

Jitsi deploys the JRE as private which means that it is not registered in the system (i.e. there are no registry entries for it, it does not copy .exe files to the Windows or System32 folders, etc.) and does not cause other applications to malfunction.

···

On 19.09.2012, at 10:36, Fernando Cassia <fcassia@gmail.com> wrote:


#3

Is there a list of what these are anywhere?

Regards

···

On 27/09/2012 1:07 AM, Lyubomir Marinov wrote:

2. Why not Java 7?

There are several pieces of Jitsi functionality which do not work as expected on Java 7.


#4

There used to be an issue with Felix, but I think that got resolved by
an update from Ingo. (Ingo could you please confirm?)

I vaguely remember some other issues but on the whole our non-interest
in Java7 has been mostly due to the fact that it was beta until
recently. I suppose this would be a good time to start testing with it
again.

Cheers,
Emil

···

On 27.09.12, 01:54, Craig Chandler wrote:

On 27/09/2012 1:07 AM, Lyubomir Marinov wrote:

2. Why not Java 7?

There are several pieces of Jitsi functionality which do not work as expected on Java 7.

Is there a list of what these are anywhere?


#5

From: Emil Ivov [mailto:emcho@jitsi.org]

2. Why not Java 7?

There are several pieces of Jitsi functionality which do not work as
expected on Java 7.

Is there a list of what these are anywhere?

There used to be an issue with Felix, but I think that got resolved by
an update from Ingo. (Ingo could you please confirm?)

Yes, Felix had some problems and I updated it about a year ago. Haven't tested it again since.

I vaguely remember some other issues but on the whole our non-interest
in Java7 has been mostly due to the fact that it was beta until
recently. I suppose this would be a good time to start testing with it
again.

It was long out of beta, but our consensus was to wait until Oracle proposes it by default to the end users on the java.com download page. And that was AFAIK sometime in spring this year.

As we don't have an official test-suite or even a list of issues against specific Java versions, my personal preference would be to always include the newest available version of the JRE. Since we have a stable build line now, I see no reason to delay it in the nightlies. On the contrary: that would help us to find issues early.

Ingo

···

On 27.09.12, 01:54, Craig Chandler wrote:

On 27/09/2012 1:07 AM, Lyubomir Marinov wrote:


#6

Leaving aside the point that Java 7 was
released<https://en.wikipedia.org/wiki/Java_version_history>in summer
2011, Java 6 will reach end of life for security updates in
February. That should be a good reason to move to Java 7. Security is the
main reason that Jitsi should be targeting the current Java 7 release. Does
the Java version that is installed by Jitsi automatically update itself? It
would seem odd if it doesn't - after all, Jitsi is an app that accepts data
from untrusted remote entities on the network and running a program that
accepts such data in a JVM with known exploitable vulnerabilities is
probably not a good idea. Having said that, I do understand that many of
the attacks on JVMs are based on attacking the Java browser plugin, so it
would be more work to attack Jitsi. Nevertheless, the point stands: such
components should be kept up to date with the latest known stable version,
and that version should be a version that will continue to get security
updates.

Regards,

Tom

···

On 27 September 2012 16:41, Emil Ivov <emcho@jitsi.org> wrote:

On 27.09.12, 01:54, Craig Chandler wrote:
> On 27/09/2012 1:07 AM, Lyubomir Marinov wrote:
>>> 2. Why not Java 7?
>> There are several pieces of Jitsi functionality which do not work as
expected on Java 7.
>>
>
> Is there a list of what these are anywhere?

There used to be an issue with Felix, but I think that got resolved by
an update from Ingo. (Ingo could you please confirm?)

I vaguely remember some other issues but on the whole our non-interest
in Java7 has been mostly due to the fact that it was beta until
recently. I suppose this would be a good time to start testing with it
again.

Cheers,
Emil

--
*Tom Strickland*, Software Developer, Thrupoint Software. Tel: +44 (0) 2920
005110

--------------------
Note: The information contained in this message may be privileged and confidential
and protected from disclosure. If the reader of this message is not the intended
recipient, or an employee or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited. If you have received this
communication in error, please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Thrupoint, Inc.


#7

Hey Tom,

Leaving aside the point that Java 7 was released
<https://en.wikipedia.org/wiki/Java_version_history> in summer 2011,

Not that recently then. OK, my bad.

Java 6 will reach end of life for security updates in February. That
should be a good reason to move to Java 7.

Indeed it would, so it would be great to start gathering feedback for
how Jitsi performs with J7. Please let us know how your testing goes.

Security is the main reason
that Jitsi should be targeting the current Java 7 release. Does the Java
version that is installed by Jitsi automatically update itself?

No it does not. Jitsi does however. The main advantage of shipping a
Java version is to have a predictable experience and that all goes away
with auto updates enabled.

Jitsi on the other hand has delta updates and LZMA compression so Java
updates would be quite painless there.

It would
seem odd if it doesn't - after all, Jitsi is an app that accepts data
from untrusted remote entities on the network and running a program that
accepts such data in a JVM with known exploitable vulnerabilities is
probably not a good idea. Having said that, I do understand that many of
the attacks on JVMs are based on attacking the Java browser plugin, so
it would be more work to attack Jitsi.

Jitsi does receive data from potentially untrusted sources. At no point
however does Jitsi execute data from such sources. Could you please
point us to any known vulnerabilities that you believe might put Jitsi
users at risk?

Nevertheless, the point stands:
such components should be kept up to date with the latest known stable
version, and that version should be a version that will continue to get
security updates.

They should indeed. And they will.

It would also be helpful if you had any "should" rules regarding
contributions from the broad community in such cases ;).

Emil

···

On 27.09.12, 18:53, Strickland, Tom wrote:

Regards,

Tom

On 27 September 2012 16:41, Emil Ivov <emcho@jitsi.org > <mailto:emcho@jitsi.org>> wrote:

    On 27.09.12, 01:54, Craig Chandler wrote:
    > On 27/09/2012 1:07 AM, Lyubomir Marinov wrote:
    >>> 2. Why not Java 7?
    >> There are several pieces of Jitsi functionality which do not work
    as expected on Java 7.
    >>
    >
    > Is there a list of what these are anywhere?

    There used to be an issue with Felix, but I think that got resolved by
    an update from Ingo. (Ingo could you please confirm?)

    I vaguely remember some other issues but on the whole our non-interest
    in Java7 has been mostly due to the fact that it was beta until
    recently. I suppose this would be a good time to start testing with it
    again.

    Cheers,
    Emil

--
*Tom Strickland*, Software Developer, Thrupoint Software. Tel: +44 (0)
2920 005110

--------------------
Note: The information contained in this message may be privileged and confidential
and protected from disclosure. If the reader of this message is not the intended
recipient, or an employee or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited. If you have received this
communication in error, please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Thrupoint, Inc.

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31


#8

Yes, that's true. We'll see if we can include it this week and if not,
we'll do so after we are done 2.0 (beginning of October).

Emil

···

On 27.09.12, 22:46, Ingo Bauersachs wrote:

From: Emil Ivov [mailto:emcho@jitsi.org] On 27.09.12, 01:54, Craig
Chandler wrote:

On 27/09/2012 1:07 AM, Lyubomir Marinov wrote:

2. Why not Java 7?

There are several pieces of Jitsi functionality which do not
work as expected on Java 7.

Is there a list of what these are anywhere?

There used to be an issue with Felix, but I think that got resolved
by an update from Ingo. (Ingo could you please confirm?)

Yes, Felix had some problems and I updated it about a year ago.
Haven't tested it again since.

I vaguely remember some other issues but on the whole our
non-interest in Java7 has been mostly due to the fact that it was
beta until recently. I suppose this would be a good time to start
testing with it again.

It was long out of beta, but our consensus was to wait until Oracle
proposes it by default to the end users on the java.com download
page. And that was AFAIK sometime in spring this year.

As we don't have an official test-suite or even a list of issues
against specific Java versions, my personal preference would be to
always include the newest available version of the JRE. Since we have
a stable build line now, I see no reason to delay it in the
nightlies. On the contrary: that would help us to find issues early.


#9

Hi all,

starting build 4236, latest jre 7u7 is included in jitsi windows installers.

Regards
damencho

···

On Thu, Sep 27, 2012 at 11:51 PM, Emil Ivov <emcho@jitsi.org> wrote:

On 27.09.12, 22:46, Ingo Bauersachs wrote:

From: Emil Ivov [mailto:emcho@jitsi.org] On 27.09.12, 01:54, Craig
Chandler wrote:

On 27/09/2012 1:07 AM, Lyubomir Marinov wrote:

2. Why not Java 7?

There are several pieces of Jitsi functionality which do not
work as expected on Java 7.

Is there a list of what these are anywhere?

There used to be an issue with Felix, but I think that got resolved
by an update from Ingo. (Ingo could you please confirm?)

Yes, Felix had some problems and I updated it about a year ago.
Haven't tested it again since.

I vaguely remember some other issues but on the whole our
non-interest in Java7 has been mostly due to the fact that it was
beta until recently. I suppose this would be a good time to start
testing with it again.

It was long out of beta, but our consensus was to wait until Oracle
proposes it by default to the end users on the java.com download
page. And that was AFAIK sometime in spring this year.

As we don't have an official test-suite or even a list of issues
against specific Java versions, my personal preference would be to
always include the newest available version of the JRE. Since we have
a stable build line now, I see no reason to delay it in the
nightlies. On the contrary: that would help us to find issues early.

Yes, that's true. We'll see if we can include it this week and if not,
we'll do so after we are done 2.0 (beginning of October).

Emil