[jitsi-dev] Java 7+, OSX and Video

The version is:
$ java -version
java version "1.7.0_65"
Java(TM) SE Runtime Environment (build 1.7.0_65-b17)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)

···

On Mon, Nov 24, 2014 at 2:44 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

seem a line in /etc/hosts is causing this. But it works with java6.
127.0.0.1<----->damencho-dev The problem comes from
InetAddress.getLocalHost() (Thanks Bobi for the help and java8 tests:) ).

Without the problem line printing result of InetAddress.getLocalHost():
java1.6: 10.0.0.117
java1.7: 10.0.0.117
java1.8: 10.0.0.117
With that line in /etc/hosts:
java1.6: 10.0.0.117
java1.7: 127.0.0.1
java1.8: 10.0.0.117

What was the exact version of Java 7? This might have been a regression...
Given that it works again with Java 8, why not just skip 7 entirely and
deliver it with 8 embedded?

Not sure whether that line is ok there, but without it everything works.

Is it present on other Mac systems by default? I'll check mine in the
evening, although I might have modified hosts and have forgotten about it.

Regards
damencho

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

Not sure whether that line is ok there, but without it everything works.

Is it present on other Mac systems by default? I'll check mine in the
evening, although I might have modified hosts and have forgotten about it.

So, my unlike to be modified /etc/hosts is:
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost

And 1.8.0_25 returns my WLAN address. So whatever is in your hosts file
should not hold us back, especially not with your small patch.

Regards
damencho

Ingo

Ingo

But I got the same results and with 1.7.0_72.

···

On Mon, Nov 24, 2014 at 2:49 PM, Damian Minkov <damencho@jitsi.org> wrote:

The version is:
$ java -version
java version "1.7.0_65"
Java(TM) SE Runtime Environment (build 1.7.0_65-b17)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)

On Mon, Nov 24, 2014 at 2:44 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

seem a line in /etc/hosts is causing this. But it works with java6.
127.0.0.1<----->damencho-dev The problem comes from
InetAddress.getLocalHost() (Thanks Bobi for the help and java8 tests:) ).

Without the problem line printing result of InetAddress.getLocalHost():
java1.6: 10.0.0.117
java1.7: 10.0.0.117
java1.8: 10.0.0.117
With that line in /etc/hosts:
java1.6: 10.0.0.117
java1.7: 127.0.0.1
java1.8: 10.0.0.117

What was the exact version of Java 7? This might have been a regression...
Given that it works again with Java 8, why not just skip 7 entirely and
deliver it with 8 embedded?

Not sure whether that line is ok there, but without it everything works.

Is it present on other Mac systems by default? I'll check mine in the
evening, although I might have modified hosts and have forgotten about it.

Regards
damencho

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

We are u40 build 15
Jdk8

https://jdk8.java.net/download.html

Mike Tallent
Objectwheel

···

Sent from my iPhone

On Nov 24, 2014, at 4:49 AM, Damian Minkov <damencho@jitsi.org> wrote:

The version is:
$ java -version
java version "1.7.0_65"
Java(TM) SE Runtime Environment (build 1.7.0_65-b17)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)

On Mon, Nov 24, 2014 at 2:44 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

seem a line in /etc/hosts is causing this. But it works with java6.
127.0.0.1<----->damencho-dev The problem comes from
InetAddress.getLocalHost() (Thanks Bobi for the help and java8 tests:) ).

Without the problem line printing result of InetAddress.getLocalHost():
java1.6: 10.0.0.117
java1.7: 10.0.0.117
java1.8: 10.0.0.117
With that line in /etc/hosts:
java1.6: 10.0.0.117
java1.7: 127.0.0.1
java1.8: 10.0.0.117

What was the exact version of Java 7? This might have been a regression...
Given that it works again with Java 8, why not just skip 7 entirely and
deliver it with 8 embedded?

Not sure whether that line is ok there, but without it everything works.

Is it present on other Mac systems by default? I'll check mine in the
evening, although I might have modified hosts and have forgotten about it.

Regards
damencho

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

I think I lost track of the discussion. Why are we talking about modifying
/etc/hosts ?

--sent from my mobile

···

On 24 Nov 2014 10:36 PM, "Ingo Bauersachs" <ingo@jitsi.org> wrote:

>> Not sure whether that line is ok there, but without it everything works.
>
> Is it present on other Mac systems by default? I'll check mine in the
> evening, although I might have modified hosts and have forgotten about
it.

So, my unlike to be modified /etc/hosts is:
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost

And 1.8.0_25 returns my WLAN address. So whatever is in your hosts file
should not hold us back, especially not with your small patch.

>> Regards
>> damencho
>
> Ingo

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

I will commit it tomorrow. I'm working today and will continue
tomorrow on the launcher. I've already fixed it for the splash screen,
just needs a little adjustment in the build.xml.
Needs to change the way we handle the versions. Currently it takes the
first found java version that satisfies the version written in
Info.plist it will be 1.7+. Currently if you have 1.7.0_45, 1.7.0_65
and 1.8, it will choose 1.7.0_45, I will be changing it to use 1.8.
Or do you think we need to move just to 1.7*, till we also move and
the windows version to 1.8?

···

On Mon, Nov 24, 2014 at 11:34 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

Not sure whether that line is ok there, but without it everything works.

Is it present on other Mac systems by default? I'll check mine in the
evening, although I might have modified hosts and have forgotten about it.

So, my unlike to be modified /etc/hosts is:
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost

And 1.8.0_25 returns my WLAN address. So whatever is in your hosts file
should not hold us back, especially not with your small patch.

Regards
damencho

Ingo

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

How is it that we get to asking InetAddress for getLocalHost(). We normally
do a number of things to avoid it.

--sent from my mobile

···

On 24 Nov 2014 2:05 PM, "Damian Minkov" <damencho@jitsi.org> wrote:

But I got the same results and with 1.7.0_72.

On Mon, Nov 24, 2014 at 2:49 PM, Damian Minkov <damencho@jitsi.org> wrote:
> The version is:
> $ java -version
> java version "1.7.0_65"
> Java(TM) SE Runtime Environment (build 1.7.0_65-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
>
>
>
> On Mon, Nov 24, 2014 at 2:44 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:
>>> seem a line in /etc/hosts is causing this. But it works with java6.
>>> 127.0.0.1<----->damencho-dev The problem comes from
>>> InetAddress.getLocalHost() (Thanks Bobi for the help and java8 tests:)
).
>>>
>>> Without the problem line printing result of InetAddress.getLocalHost():
>>> java1.6: 10.0.0.117
>>> java1.7: 10.0.0.117
>>> java1.8: 10.0.0.117
>>> With that line in /etc/hosts:
>>> java1.6: 10.0.0.117
>>> java1.7: 127.0.0.1
>>> java1.8: 10.0.0.117
>>
>> What was the exact version of Java 7? This might have been a
regression...
>> Given that it works again with Java 8, why not just skip 7 entirely and
>> deliver it with 8 embedded?
>>
>>> Not sure whether that line is ok there, but without it everything
works.
>>
>> Is it present on other Mac systems by default? I'll check mine in the
>> evening, although I might have modified hosts and have forgotten about
it.
>>
>>> Regards
>>> damencho
>>
>> Ingo
>>
>>
>> _______________________________________________
>> dev mailing list
>> dev@jitsi.org
>> Unsubscribe instructions and other list options:
>> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

On my said it always goes in the following case:
"Socket returned the ANY local address. Trying a workaround." Which
then do the getLocalHost() stuff.

···

On Mon, Nov 24, 2014 at 3:08 PM, Emil Ivov <emcho@jitsi.org> wrote:

How is it that we get to asking InetAddress for getLocalHost(). We normally
do a number of things to avoid it.

--sent from my mobile

On 24 Nov 2014 2:05 PM, "Damian Minkov" <damencho@jitsi.org> wrote:

But I got the same results and with 1.7.0_72.

On Mon, Nov 24, 2014 at 2:49 PM, Damian Minkov <damencho@jitsi.org> wrote:
> The version is:
> $ java -version
> java version "1.7.0_65"
> Java(TM) SE Runtime Environment (build 1.7.0_65-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
>
>
>
> On Mon, Nov 24, 2014 at 2:44 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:
>>> seem a line in /etc/hosts is causing this. But it works with java6.
>>> 127.0.0.1<----->damencho-dev The problem comes from
>>> InetAddress.getLocalHost() (Thanks Bobi for the help and java8 tests:)
>>> ).
>>>
>>> Without the problem line printing result of
>>> InetAddress.getLocalHost():
>>> java1.6: 10.0.0.117
>>> java1.7: 10.0.0.117
>>> java1.8: 10.0.0.117
>>> With that line in /etc/hosts:
>>> java1.6: 10.0.0.117
>>> java1.7: 127.0.0.1
>>> java1.8: 10.0.0.117
>>
>> What was the exact version of Java 7? This might have been a
>> regression...
>> Given that it works again with Java 8, why not just skip 7 entirely and
>> deliver it with 8 embedded?
>>
>>> Not sure whether that line is ok there, but without it everything
>>> works.
>>
>> Is it present on other Mac systems by default? I'll check mine in the
>> evening, although I might have modified hosts and have forgotten about
>> it.
>>
>>> Regards
>>> damencho
>>
>> Ingo
>>
>>
>> _______________________________________________
>> dev mailing list
>> dev@jitsi.org
>> Unsubscribe instructions and other list options:
>> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

I will commit it tomorrow. I'm working today and will continue
tomorrow on the launcher. I've already fixed it for the splash screen,
just needs a little adjustment in the build.xml.

Great!

Needs to change the way we handle the versions. Currently it takes the
first found java version that satisfies the version written in
Info.plist it will be 1.7+. Currently if you have 1.7.0_45, 1.7.0_65
and 1.8, it will choose 1.7.0_45, I will be changing it to use 1.8.
Or do you think we need to move just to 1.7*, till we also move and
the windows version to 1.8?

Let's move Windows to 1.8 now and see what comes back from the nightly
userbase. I've made all my recent calls during the mac-debugging with 1.8 on
Windows as well and noticed no particular problems.

And I wanted to deploy 5347 in the company tomorrow - if you update it soon
I can wait a little and give feedback for that as well (SIP calls and audio
only though).

Ingo

I think I lost track of the discussion. Why are we talking about modifying
/etc/hosts ?

We're not. Damian's is modified for whatever reason and is causing problems. I pasted mine for reference.

Ingo

If Java 1.7 causes any delay or eats up dev time, I’d go for 1.8 directly. Why support old Java versions?

Also Java updates are rather important security wise, so maybe Jitsi should even require the latest Java to be installed? Similar to what OS X does with flash? It disables any previous versions of flash and does not allow the user to run such un-secure software.

my cents.

···

Am 25.11.2014 um 00:38 schrieb Mike <mikegps1@gmail.com>:

We are u40 build 15
Jdk8

https://jdk8.java.net/download.html

Mike Tallent
Objectwheel

Sent from my iPhone

On Nov 24, 2014, at 4:49 AM, Damian Minkov <damencho@jitsi.org> wrote:

The version is:
$ java -version
java version "1.7.0_65"
Java(TM) SE Runtime Environment (build 1.7.0_65-b17)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)

On Mon, Nov 24, 2014 at 2:44 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

seem a line in /etc/hosts is causing this. But it works with java6.
127.0.0.1<----->damencho-dev The problem comes from
InetAddress.getLocalHost() (Thanks Bobi for the help and java8 tests:) ).

Without the problem line printing result of InetAddress.getLocalHost():
java1.6: 10.0.0.117
java1.7: 10.0.0.117
java1.8: 10.0.0.117
With that line in /etc/hosts:
java1.6: 10.0.0.117
java1.7: 127.0.0.1
java1.8: 10.0.0.117

What was the exact version of Java 7? This might have been a regression...
Given that it works again with Java 8, why not just skip 7 entirely and
deliver it with 8 embedded?

Not sure whether that line is ok there, but without it everything works.

Is it present on other Mac systems by default? I'll check mine in the
evening, although I might have modified hosts and have forgotten about it.

Regards
damencho

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

How is it that we get to asking InetAddress for getLocalHost(). We

normally

do a number of things to avoid it.

On my said it always goes in the following case:
"Socket returned the ANY local address. Trying a workaround." Which
then do the getLocalHost() stuff.

This would mean that this snippet has already failed to provide an actual
address and delivers 0.0.0.0 (or ::0)

            localHostFinderSocket.connect(intendedDestination,
                                          RANDOM_ADDR_DISC_PORT);
            localHost = localHostFinderSocket.getLocalAddress();
            localHostFinderSocket.disconnect();

Ingo

Hi,

here is a patch, that removes an unnecessary call of getLocalHost(),
and fixes the checks, at least respects what comments say.
This works for me with the additional line in hosts file.
WDYT?

Regards
damencho

nam.patch (998 Bytes)

···

On Mon, Nov 24, 2014 at 3:36 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

How is it that we get to asking InetAddress for getLocalHost(). We

normally

do a number of things to avoid it.

On my said it always goes in the following case:
"Socket returned the ANY local address. Trying a workaround." Which
then do the getLocalHost() stuff.

This would mean that this snippet has already failed to provide an actual
address and delivers 0.0.0.0 (or ::0)

            localHostFinderSocket.connect(intendedDestination,
                                          RANDOM_ADDR_DISC_PORT);
            localHost = localHostFinderSocket.getLocalAddress();
            localHostFinderSocket.disconnect();

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

OK thanks!

···

On Mon, Nov 24, 2014 at 10:58 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

I think I lost track of the discussion. Why are we talking about modifying
/etc/hosts ?

We're not. Damian's is modified for whatever reason and is causing problems. I pasted mine for reference.

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org

`

  Agreed. Though, the switch to 8 should be tested. We already experienced incompatibilities between

  Java versions in GUI (focus handling...). So could not be only a simple switch.. But this is a very

  rare case so this will probably go smooth...

`
···

Am 25.11.2014 um 13:30 schrieb foss:


If Java 1.7 causes any delay or eats up dev time, I�d go for 1.8 directly. Why support old Java versions? Also Java updates are rather important security wise, so maybe Jitsi should even require the latest Java to be installed? Similar to what OS X does with flash? It disables any previous versions of flash and does not allow the user to run such un-secure software. my cents.

Am 25.11.2014 um 00:38 schrieb Mike : We are u40 build 15 Jdk8 Mike Tallent Objectwheel Sent from my iPhone

On Nov 24, 2014, at 4:49 AM, Damian Minkov wrote: The version is: $ java -version java version "1.7.0_65" Java(TM) SE Runtime Environment (build 1.7.0_65-b17) Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode) On Mon, Nov 24, 2014 at 2:44 PM, Ingo Bauersachs wrote:

seem a line in /etc/hosts is causing this. But it works with java6. 127.0.0.1<----->damencho-dev The problem comes from InetAddress.getLocalHost() (Thanks Bobi for the help and java8 tests:) ). Without the problem line printing result of InetAddress.getLocalHost(): java1.6: 10.0.0.117 java1.7: 10.0.0.117 java1.8: 10.0.0.117 With that line in /etc/hosts: java1.6: 10.0.0.117 java1.7: 127.0.0.1 java1.8: 10.0.0.117
What was the exact version of Java 7? This might have been a regression... Given that it works again with Java 8, why not just skip 7 entirely and deliver it with 8 embedded?
Not sure whether that line is ok there, but without it everything works.
Is it present on other Mac systems by default? I'll check mine in the evening, although I might have modified hosts and have forgotten about it.
Regards damencho


Ingo _______________________________________________ dev mailing list Unsubscribe instructions and other list options:

_______________________________________________ dev mailing list Unsubscribe instructions and other list options:

_______________________________________________ dev mailing list Unsubscribe instructions and other list options:


_______________________________________________ dev mailing list Unsubscribe instructions and other list options:

mikegps1@gmail.comhttps://jdk8.java.net/download.htmldamencho@jitsi.orgingo@jitsi.orgdev@jitsi.orghttp://lists.jitsi.org/mailman/listinfo/devdev@jitsi.orghttp://lists.jitsi.org/mailman/listinfo/devdev@jitsi.orghttp://lists.jitsi.org/mailman/listinfo/devdev@jitsi.orghttp://lists.jitsi.org/mailman/listinfo/dev

Normally, I would agree with you to focus on the latest release, however
that would exclude even Debian Jessie (Testing). AFAICT Jessie only has
OpenJDK-7. And I think Jessie is currently stabilizing, so there's
chance that OpenJDK 8 won't make it in.

Danny

···

On 25-11-14 13:30, foss wrote:

If Java 1.7 causes any delay or eats up dev time, I�d go for 1.8 directly. Why support old Java versions?

Also Java updates are rather important security wise, so maybe Jitsi should even require the latest Java to be installed? Similar to what OS X does with flash? It disables any previous versions of flash and does not allow the user to run such un-secure software.

my cents.

Am 25.11.2014 um 00:38 schrieb Mike <mikegps1@gmail.com>:

We are u40 build 15
Jdk8

https://jdk8.java.net/download.html

Mike Tallent
Objectwheel

Sent from my iPhone

On Nov 24, 2014, at 4:49 AM, Damian Minkov <damencho@jitsi.org> wrote:

The version is:
$ java -version
java version "1.7.0_65"
Java(TM) SE Runtime Environment (build 1.7.0_65-b17)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)

On Mon, Nov 24, 2014 at 2:44 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

seem a line in /etc/hosts is causing this. But it works with java6.
127.0.0.1<----->damencho-dev The problem comes from
InetAddress.getLocalHost() (Thanks Bobi for the help and java8 tests:) ).

Without the problem line printing result of InetAddress.getLocalHost():
java1.6: 10.0.0.117
java1.7: 10.0.0.117
java1.8: 10.0.0.117
With that line in /etc/hosts:
java1.6: 10.0.0.117
java1.7: 127.0.0.1
java1.8: 10.0.0.117

What was the exact version of Java 7? This might have been a regression...
Given that it works again with Java 8, why not just skip 7 entirely and
deliver it with 8 embedded?

Not sure whether that line is ok there, but without it everything works.

Is it present on other Mac systems by default? I'll check mine in the
evening, although I might have modified hosts and have forgotten about it.

Regards
damencho

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

here is a patch, that removes an unnecessary call of getLocalHost(),
and fixes the checks, at least respects what comments say.
This works for me with the additional line in hosts file.
WDYT?

It doesn't necessarily return the correct address, but surely better than the current version.

Regards
damencho

Ingo

Normally, I would agree with you to focus on the latest release, however
that would exclude even Debian Jessie (Testing). AFAICT Jessie only has
OpenJDK-7. And I think Jessie is currently stabilizing, so there's
chance that OpenJDK 8 won't make it in.

Did Jitsi itself even make it into stable? And in any case, this is only
about the shipped runtime on Windows and Mac. We can still support even Java
6 as the underlying JDK, even though I'd prefer to go to 1.8 and make use of
e.g. lambdas.

Danny

Ingo

Also note that the problem with OpenJDK 7 discussed above doesn't affect linux (at least I am unable to reproduce it).

Boris

···

On 25/11/14 20:52, Danny van Heumen wrote:

Normally, I would agree with you to focus on the latest release, however
that would exclude even Debian Jessie (Testing). AFAICT Jessie only has
OpenJDK-7. And I think Jessie is currently stabilizing, so there's
chance that OpenJDK 8 won't make it in.

Normally, I would agree with you to focus on the latest release, however
that would exclude even Debian Jessie (Testing). AFAICT Jessie only has
OpenJDK-7. And I think Jessie is currently stabilizing, so there's
chance that OpenJDK 8 won't make it in.

Also note that the problem with OpenJDK 7 discussed above doesn't
affect linux (at least I am unable to reproduce it).

Ah, right, they're talking only about the JVM to ship ...
Sorry about that, thanks for correcting me!

Danny

···

On 25-11-14 20:50, Boris Grozev wrote:

On 25/11/14 20:52, Danny van Heumen wrote:

Boris

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev