I´ve downloaded and installed the latest greatest ´stable´ Jitsi from
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).
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
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
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....
During times of Universal Deceit, telling the truth becomes a revolutionary act
- George Orwell