[jitsi-dev] Moving to Java 8


#1

Hello,

The Jitsi team is looking into moving to Java 8 for the Jitsi Videobridge, LibJitsi. Java 8 bytecode is not compatible with Java 7 bytecode, so while you can use Java 7 dependencies in your Java 8 projects, the opposite is not possible.

This will force projects that depend on the JVB and LJ to use a Java >= 8 compiler and runtime (so, for example, Jicofo and Jitsi will have to at least be compiled with JDK >= 8).

If any members of the community have concerns or other thoughts on this, I invite you to raise them in this thread.

Best regards,
George Politis


#2

The Jitsi team is looking into moving to Java 8 for the Jitsi
Videobridge, LibJitsi. Java 8 bytecode is not compatible with Java 7
bytecode, so while you can use Java 7 dependencies in your Java 8
projects, the opposite is not possible.

This will force projects that depend on the JVB and LJ to use a Java >= 8
compiler and runtime (so, for example, Jicofo and Jitsi will have to at least
be compiled with JDK >= 8).

If any members of the community have concerns or other thoughts on this, I
invite you to raise them in this thread.

Moving to Java 8 has been an issue because as we wanted to support Ubuntu 14.04 and Debian Jessie. Is that not a requirement anymore?

Debian Stretch (which comes with Java 8 by default) is in freeze currently. AFAIK it should be released as stable in 6-8 months and I would wait for that to happen before we require Java 8.

Best regards,
George Politis

Ingo


#3

Hi Ingo, thanks for chiming in.

By moving to Java 8 we’re not dropping support neither for Ubuntu 14.04 nor for Jessie, since it’s possible to install OpenJDK from either a PPA on Ubuntu 14.04 or jessie-backports on Jessie. This should be fine because users anyway have to add a third party repo to install any Jitsi project.

Best regards,
George

···

On Jan 24, 2017, at 11:53 AM, Ingo Bauersachs <ingo@jitsi.org> wrote:

The Jitsi team is looking into moving to Java 8 for the Jitsi
Videobridge, LibJitsi. Java 8 bytecode is not compatible with Java 7
bytecode, so while you can use Java 7 dependencies in your Java 8
projects, the opposite is not possible.

This will force projects that depend on the JVB and LJ to use a Java >= 8
compiler and runtime (so, for example, Jicofo and Jitsi will have to at least
be compiled with JDK >= 8).

If any members of the community have concerns or other thoughts on this, I
invite you to raise them in this thread.

Moving to Java 8 has been an issue because as we wanted to support Ubuntu 14.04 and Debian Jessie. Is that not a requirement anymore?

Debian Stretch (which comes with Java 8 by default) is in freeze currently. AFAIK it should be released as stable in 6-8 months and I would wait for that to happen before we require Java 8.

Best regards,
George Politis

Ingo

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


#4

Even though it is pretty straightforward, requiring Java 8 on Debian is
still putting up quite some hurdles for some people. I was surprised to
find how many people struggled with it. I love the features new in Java 8,
but from an adoption point of view I would hold of until Stretch.

···

On 24 Jan 2017 19:02, "George Politis" <gp@jitsi.org> wrote:

Hi Ingo, thanks for chiming in.

By moving to Java 8 we’re not dropping support neither for Ubuntu 14.04
nor for Jessie, since it’s possible to install OpenJDK from either a PPA on
Ubuntu 14.04 or jessie-backports on Jessie. This should be fine because
users anyway have to add a third party repo to install any Jitsi project.

Best regards,
George

> On Jan 24, 2017, at 11:53 AM, Ingo Bauersachs <ingo@jitsi.org> wrote:
>
>> The Jitsi team is looking into moving to Java 8 for the Jitsi
>> Videobridge, LibJitsi. Java 8 bytecode is not compatible with Java 7
>> bytecode, so while you can use Java 7 dependencies in your Java 8
>> projects, the opposite is not possible.
>>
>> This will force projects that depend on the JVB and LJ to use a Java >=
8
>> compiler and runtime (so, for example, Jicofo and Jitsi will have to at
least
>> be compiled with JDK >= 8).
>>
>> If any members of the community have concerns or other thoughts on
this, I
>> invite you to raise them in this thread.
>
> Moving to Java 8 has been an issue because as we wanted to support
Ubuntu 14.04 and Debian Jessie. Is that not a requirement anymore?
>
> Debian Stretch (which comes with Java 8 by default) is in freeze
currently. AFAIK it should be released as stable in 6-8 months and I would
wait for that to happen before we require Java 8.
>
>> Best regards,
>> George Politis
>
> 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


#5

Could I suggest that it would be worth identifying the sources that require Java 8 enabling anyone who wants a previous compilation to know which sources are not compatible. If developers are careful for a period not to develop incompatibilities between classes then that should make it possible for users to continue with J7 if it is important to them.

It is in the end only a timing issue.

···

On 24/01/2017 17:59, George Politis wrote:

Hi Ingo, thanks for chiming in.

By moving to Java 8 we’re not dropping support neither for Ubuntu 14.04 nor for Jessie, since it’s possible to install OpenJDK from either a PPA on Ubuntu 14.04 or jessie-backports on Jessie. This should be fine because users anyway have to add a third party repo to install any Jitsi project.

Best regards,
George

On Jan 24, 2017, at 11:53 AM, Ingo Bauersachs <ingo@jitsi.org> wrote:

The Jitsi team is looking into moving to Java 8 for the Jitsi
Videobridge, LibJitsi. Java 8 bytecode is not compatible with Java 7
bytecode, so while you can use Java 7 dependencies in your Java 8
projects, the opposite is not possible.

This will force projects that depend on the JVB and LJ to use a Java >= 8
compiler and runtime (so, for example, Jicofo and Jitsi will have to at least
be compiled with JDK >= 8).

If any members of the community have concerns or other thoughts on this, I
invite you to raise them in this thread.

Moving to Java 8 has been an issue because as we wanted to support Ubuntu 14.04 and Debian Jessie. Is that not a requirement anymore?

Debian Stretch (which comes with Java 8 by default) is in freeze currently. AFAIK it should be released as stable in 6-8 months and I would wait for that to happen before we require Java 8.

Best regards,
George Politis

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


#6

Hi Guus, thanks for chiming in.

I agree that it’s not great to have an additional extra step to enable the Jessie backports repo or the OpenJDK PPA, but people that were able to successfully install any Jitsi product should already be familiar with the process of adding a third party repo.

On the other hand, if we chose to stay with Java 7 for the foreseeable future, then the devs have resort to hacks in order to be able to use some of the functionality and the classes that are currently available in Java 8. Hacks not only reduce the maintainability of the code but also the replicated Java 8 classes and/or functionality will never work as well as in Java 8 because they require the underlying JVM/bytecode changes.

In the end, it’s in the best interest of the end users to have a high quality and maintainable source code.

Best regards,
George

···

On Jan 24, 2017, at 12:27 PM, Guus der Kinderen <guus.der.kinderen@gmail.com> wrote:

Even though it is pretty straightforward, requiring Java 8 on Debian is still putting up quite some hurdles for some people. I was surprised to find how many people struggled with it. I love the features new in Java 8, but from an adoption point of view I would hold of until Stretch.

On 24 Jan 2017 19:02, "George Politis" <gp@jitsi.org <mailto:gp@jitsi.org>> wrote:
Hi Ingo, thanks for chiming in.

By moving to Java 8 we’re not dropping support neither for Ubuntu 14.04 nor for Jessie, since it’s possible to install OpenJDK from either a PPA on Ubuntu 14.04 or jessie-backports on Jessie. This should be fine because users anyway have to add a third party repo to install any Jitsi project.

Best regards,
George

> On Jan 24, 2017, at 11:53 AM, Ingo Bauersachs <ingo@jitsi.org <mailto:ingo@jitsi.org>> wrote:
>
>> The Jitsi team is looking into moving to Java 8 for the Jitsi
>> Videobridge, LibJitsi. Java 8 bytecode is not compatible with Java 7
>> bytecode, so while you can use Java 7 dependencies in your Java 8
>> projects, the opposite is not possible.
>>
>> This will force projects that depend on the JVB and LJ to use a Java >= 8
>> compiler and runtime (so, for example, Jicofo and Jitsi will have to at least
>> be compiled with JDK >= 8).
>>
>> If any members of the community have concerns or other thoughts on this, I
>> invite you to raise them in this thread.
>
> Moving to Java 8 has been an issue because as we wanted to support Ubuntu 14.04 and Debian Jessie. Is that not a requirement anymore?
>
> Debian Stretch (which comes with Java 8 by default) is in freeze currently. AFAIK it should be released as stable in 6-8 months and I would wait for that to happen before we require Java 8.
>
>> Best regards,
>> George Politis
>
> Ingo
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org <mailto:dev@jitsi.org>
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org <mailto: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


#7

Hi Guus, thanks for chiming in.

I agree that it’s not great to have an additional extra step to enable the
Jessie backports repo or the OpenJDK PPA, but people that were able to
successfully install any Jitsi product should already be familiar with the
process of adding a third party repo.

We could also just add it as part of the installation, the way we do
with jitsi's repo.

Emil

···

On Tue, Jan 24, 2017 at 12:53 PM, George Politis <gp@jitsi.org> wrote:

On the other hand, if we chose to stay with Java 7 for the foreseeable
future, then the devs have resort to hacks in order to be able to use some
of the functionality and the classes that are currently available in Java 8.
Hacks not only reduce the maintainability of the code but also the
replicated Java 8 classes and/or functionality will never work as well as in
Java 8 because they require the underlying JVM/bytecode changes.

In the end, it’s in the best interest of the end users to have a high
quality and maintainable source code.

Best regards,
George

On Jan 24, 2017, at 12:27 PM, Guus der Kinderen > <guus.der.kinderen@gmail.com> wrote:

Even though it is pretty straightforward, requiring Java 8 on Debian is
still putting up quite some hurdles for some people. I was surprised to find
how many people struggled with it. I love the features new in Java 8, but
from an adoption point of view I would hold of until Stretch.

On 24 Jan 2017 19:02, "George Politis" <gp@jitsi.org> wrote:

Hi Ingo, thanks for chiming in.

By moving to Java 8 we’re not dropping support neither for Ubuntu 14.04
nor for Jessie, since it’s possible to install OpenJDK from either a PPA on
Ubuntu 14.04 or jessie-backports on Jessie. This should be fine because
users anyway have to add a third party repo to install any Jitsi project.

Best regards,
George

> On Jan 24, 2017, at 11:53 AM, Ingo Bauersachs <ingo@jitsi.org> wrote:
>
>> The Jitsi team is looking into moving to Java 8 for the Jitsi
>> Videobridge, LibJitsi. Java 8 bytecode is not compatible with Java 7
>> bytecode, so while you can use Java 7 dependencies in your Java 8
>> projects, the opposite is not possible.
>>
>> This will force projects that depend on the JVB and LJ to use a Java >=
>> 8
>> compiler and runtime (so, for example, Jicofo and Jitsi will have to at
>> least
>> be compiled with JDK >= 8).
>>
>> If any members of the community have concerns or other thoughts on
>> this, I
>> invite you to raise them in this thread.
>
> Moving to Java 8 has been an issue because as we wanted to support
> Ubuntu 14.04 and Debian Jessie. Is that not a requirement anymore?
>
> Debian Stretch (which comes with Java 8 by default) is in freeze
> currently. AFAIK it should be released as stable in 6-8 months and I would
> wait for that to happen before we require Java 8.
>
>> Best regards,
>> George Politis
>
> 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

--
https://jitsi.org


#8

Hi John, thanks for chiming in.

I think we either stick with Java 7 or go with Java 8. We don’t have the time to support the sophisticated setup that you describe.

However, Java 8 and Java 7 can be installed side by side, so this solves the problem for users that don’t want to upgrade their Java installation because, for example, they have a legacy Java application that they need to support.

Best regards,
George

···

On Jan 24, 2017, at 2:29 PM, John Hemming <john@hemming.email> wrote:

Could I suggest that it would be worth identifying the sources that require Java 8 enabling anyone who wants a previous compilation to know which sources are not compatible. If developers are careful for a period not to develop incompatibilities between classes then that should make it possible for users to continue with J7 if it is important to them.

It is in the end only a timing issue.

On 24/01/2017 17:59, George Politis wrote:

Hi Ingo, thanks for chiming in.

By moving to Java 8 we’re not dropping support neither for Ubuntu 14.04 nor for Jessie, since it’s possible to install OpenJDK from either a PPA on Ubuntu 14.04 or jessie-backports on Jessie. This should be fine because users anyway have to add a third party repo to install any Jitsi project.

Best regards,
George

On Jan 24, 2017, at 11:53 AM, Ingo Bauersachs <ingo@jitsi.org> wrote:

The Jitsi team is looking into moving to Java 8 for the Jitsi
Videobridge, LibJitsi. Java 8 bytecode is not compatible with Java 7
bytecode, so while you can use Java 7 dependencies in your Java 8
projects, the opposite is not possible.

This will force projects that depend on the JVB and LJ to use a Java >= 8
compiler and runtime (so, for example, Jicofo and Jitsi will have to at least
be compiled with JDK >= 8).

If any members of the community have concerns or other thoughts on this, I
invite you to raise them in this thread.

Moving to Java 8 has been an issue because as we wanted to support Ubuntu 14.04 and Debian Jessie. Is that not a requirement anymore?

Debian Stretch (which comes with Java 8 by default) is in freeze currently. AFAIK it should be released as stable in 6-8 months and I would wait for that to happen before we require Java 8.

Best regards,
George Politis

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


#9

I agree that it’s not great to have an additional extra step to enable the
Jessie backports repo or the OpenJDK PPA, but people that were able to
successfully install any Jitsi product should already be familiar with the
process of adding a third party repo.

Adding a ppa on Ubuntu is easy enough AFTER you found out that a) you need to do that and b) which one. But adding an apt-pinning on Debian is next to impossible for an average admin.
Adding it automatically isn't an option either, it might break existing installed software.

For Jitsi Desktop, it isn't necessary (or at least wasn't until and including 2.8) to add a repo. Downloading the .deb and dkpg -i was enough. I understand that nobody working at Atlassian doesn't care about this anymore, but I still do. See [1] for the painful experience of a user trying to install Jitsi.

On the other hand, if we chose to stay with Java 7 for the foreseeable
future, then the devs have resort to hacks in order to be able to use some of
the functionality and the classes that are currently available in Java 8.
Hacks not only reduce the maintainability of the code but also the replicated
Java 8 classes and/or functionality will never work as well as in Java 8
because they require the underlying JVM/bytecode changes.

Which classes would need to be duplicated? So far, I haven't come anything in the JDK that would necessitate Java 8. The useful things are lambdas and streams. And this doesn't justify the hurdles.

In the end, it’s in the best interest of the end users to have a high quality
and maintainable source code.

Previously the policy was to stick with Java current - 1. Java 9 isn't released yet, so this would currently still equate to Java 7. If installing PPA's and other repositories is all of a sudden a valid option, then we could have migrated to Java 8 in late 2014 when I asked about that, and had forgotten about the fact that it isn't available in Ubuntu 14.04 and Debian.

Best regards,
George

Ingo

[1] http://lists.jitsi.org/pipermail/users/2017-January/012145.html


#10

I haven't as yet used the forking function in git, but I would have thought you could simply fork the system prior to applying any Java 8 and refer people to the Java 7 version.

Obviously as someone who has not done this (yet - I do intend doing this for the relevant work on the bridge as soon as I have something that is in a good enough state) I cannot be certain that I understand how it works.

···

On 24/01/2017 20:51, George Politis wrote:

Hi John, thanks for chiming in.

I think we either stick with Java 7 or go with Java 8. We don’t have the time to support the sophisticated setup that you describe.
  However, Java 8 and Java 7 can be installed side by side, so this solves the problem for users that don’t want to upgrade their Java installation because, for example, they have a legacy Java application that they need to support.

Best regards,
George

On Jan 24, 2017, at 2:29 PM, John Hemming <john@hemming.email> wrote:

Could I suggest that it would be worth identifying the sources that require Java 8 enabling anyone who wants a previous compilation to know which sources are not compatible. If developers are careful for a period not to develop incompatibilities between classes then that should make it possible for users to continue with J7 if it is important to them.

It is in the end only a timing issue.

On 24/01/2017 17:59, George Politis wrote:

Hi Ingo, thanks for chiming in.

By moving to Java 8 we’re not dropping support neither for Ubuntu 14.04 nor for Jessie, since it’s possible to install OpenJDK from either a PPA on Ubuntu 14.04 or jessie-backports on Jessie. This should be fine because users anyway have to add a third party repo to install any Jitsi project.

Best regards,
George

On Jan 24, 2017, at 11:53 AM, Ingo Bauersachs <ingo@jitsi.org> wrote:

The Jitsi team is looking into moving to Java 8 for the Jitsi
Videobridge, LibJitsi. Java 8 bytecode is not compatible with Java 7
bytecode, so while you can use Java 7 dependencies in your Java 8
projects, the opposite is not possible.

This will force projects that depend on the JVB and LJ to use a Java >= 8
compiler and runtime (so, for example, Jicofo and Jitsi will have to at least
be compiled with JDK >= 8).

If any members of the community have concerns or other thoughts on this, I
invite you to raise them in this thread.

Moving to Java 8 has been an issue because as we wanted to support Ubuntu 14.04 and Debian Jessie. Is that not a requirement anymore?

Debian Stretch (which comes with Java 8 by default) is in freeze currently. AFAIK it should be released as stable in 6-8 months and I would wait for that to happen before we require Java 8.

Best regards,
George Politis

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


#11

Hi Ingo,

I agree that it’s not great to have an additional extra step to enable the
Jessie backports repo or the OpenJDK PPA, but people that were able to
successfully install any Jitsi product should already be familiar with the
process of adding a third party repo.

Adding a ppa on Ubuntu is easy enough AFTER you found out that a) you need to do that and b) which one.

I didn’t explicitly mention it, but we will of course update the instructions to include that additional extra step, as Emil has already pointed out.

But adding an apt-pinning on Debian is next to impossible for an average admin.
Adding it automatically isn't an option either, it might break existing installed software.

Whenever we move to Java 8 we will face this problem. On the up-side, Java 8 and Java 7 can be installed side by side, so people who actually need Java 7 can still use it.

For Jitsi Desktop, it isn't necessary (or at least wasn't until and including 2.8) to add a repo. Downloading the .deb and dkpg -i was enough.

And if we target Java 8, it will only require an additional step: downloading the Java 8 JRE deb and dpkg -i.

I understand that nobody working at Atlassian doesn't care about this anymore, but I still do.

Jitsi was mentioned in the initial email and we are having an open discussion with the community.

See [1] for the painful experience of a user trying to install Jitsi.

How is sticking to Java 7 going to fix our documentation, which is a problem that already exists and has caused the problem described in the thread that you referenced?

On the other hand, if we chose to stay with Java 7 for the foreseeable
future, then the devs have resort to hacks in order to be able to use some of
the functionality and the classes that are currently available in Java 8.
Hacks not only reduce the maintainability of the code but also the replicated
Java 8 classes and/or functionality will never work as well as in Java 8
because they require the underlying JVM/bytecode changes.

Which classes would need to be duplicated? So far, I haven't come anything in the JDK that would necessitate Java 8. The useful things are lambdas and streams. And this doesn't justify the hurdles.

There are open PRs in LJ now that copy Java 8 classes and I’ve also copied classes from Java 8 in the past because it makes sense to use them. Also, ice4j has some hackery to activate features when it runs on JRE 8.

In the end, it’s in the best interest of the end users to have a high quality
and maintainable source code.

Previously the policy was to stick with Java current - 1. Java 9 isn't released yet, so this would currently still equate to Java 7. If installing PPA's and other repositories is all of a sudden a valid option, then we could have migrated to Java 8 in late 2014 when I asked about that, and had forgotten about the fact that it isn't available in Ubuntu 14.04 and Debian.

I’m surprised to hear that we have such a policy, I wasn’t aware of it, but I think we should have migrated to Java 8 in late 2014.

Best regards,
George

···

On Jan 24, 2017, at 4:27 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

Best regards,
George

Ingo

[1] http://lists.jitsi.org/pipermail/users/2017-January/012145.html

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


#12

For what it's worth, I think that the choice to move to Java 8 depends on
what group of people you want to please most: developer (which will like
the new Java 8 features), or Debian admins (which will like the Java 7
compatibility with Debian). On a side note: from an administrative
perspective, it would be good to use Java 8 at runtime, as this brings
security and performance improvements.

···

On 25 January 2017 at 00:10, George Politis <gp@jitsi.org> wrote:

Hi Ingo,

> On Jan 24, 2017, at 4:27 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:
>
>> I agree that it’s not great to have an additional extra step to enable
the
>> Jessie backports repo or the OpenJDK PPA, but people that were able to
>> successfully install any Jitsi product should already be familiar with
the
>> process of adding a third party repo.
>
> Adding a ppa on Ubuntu is easy enough AFTER you found out that a) you
need to do that and b) which one.

I didn’t explicitly mention it, but we will of course update the
instructions to include that additional extra step, as Emil has already
pointed out.

> But adding an apt-pinning on Debian is next to impossible for an average
admin.
> Adding it automatically isn't an option either, it might break existing
installed software.

Whenever we move to Java 8 we will face this problem. On the up-side, Java
8 and Java 7 can be installed side by side, so people who actually need
Java 7 can still use it.

>
> For Jitsi Desktop, it isn't necessary (or at least wasn't until and
including 2.8) to add a repo. Downloading the .deb and dkpg -i was enough.

And if we target Java 8, it will only require an additional step:
downloading the Java 8 JRE deb and dpkg -i.

> I understand that nobody working at Atlassian doesn't care about this
anymore, but I still do.

Jitsi was mentioned in the initial email and we are having an open
discussion with the community.

> See [1] for the painful experience of a user trying to install Jitsi.
>

How is sticking to Java 7 going to fix our documentation, which is a
problem that already exists and has caused the problem described in the
thread that you referenced?

>> On the other hand, if we chose to stay with Java 7 for the foreseeable
>> future, then the devs have resort to hacks in order to be able to use
some of
>> the functionality and the classes that are currently available in Java
8.
>> Hacks not only reduce the maintainability of the code but also the
replicated
>> Java 8 classes and/or functionality will never work as well as in Java 8
>> because they require the underlying JVM/bytecode changes.
>
> Which classes would need to be duplicated? So far, I haven't come
anything in the JDK that would necessitate Java 8. The useful things are
lambdas and streams. And this doesn't justify the hurdles.

There are open PRs in LJ now that copy Java 8 classes and I’ve also copied
classes from Java 8 in the past because it makes sense to use them. Also,
ice4j has some hackery to activate features when it runs on JRE 8.

>
>> In the end, it’s in the best interest of the end users to have a high
quality
>> and maintainable source code.
>
> Previously the policy was to stick with Java current - 1. Java 9 isn't
released yet, so this would currently still equate to Java 7. If installing
PPA's and other repositories is all of a sudden a valid option, then we
could have migrated to Java 8 in late 2014 when I asked about that, and had
forgotten about the fact that it isn't available in Ubuntu 14.04 and Debian.

I’m surprised to hear that we have such a policy, I wasn’t aware of it,
but I think we should have migrated to Java 8 in late 2014.

Best regards,
George

>
>> Best regards,
>> George
>
> Ingo
>
> [1] http://lists.jitsi.org/pipermail/users/2017-January/012145.html
>
>
> _______________________________________________
> 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


#13

Hi John, I’m still trying to understand what your would like to achieve and why you need git forking? The Java 7 code will remain in the git repository. We can add a git tag to mark the transition to Java 8.

···

On Jan 25, 2017, at 1:40 AM, John Hemming <john@hemming.email> wrote:

I haven't as yet used the forking function in git, but I would have thought you could simply fork the system prior to applying any Java 8 and refer people to the Java 7 version.

Obviously as someone who has not done this (yet - I do intend doing this for the relevant work on the bridge as soon as I have something that is in a good enough state) I cannot be certain that I understand how it works.

On 24/01/2017 20:51, George Politis wrote:

Hi John, thanks for chiming in.

I think we either stick with Java 7 or go with Java 8. We don’t have the time to support the sophisticated setup that you describe.
However, Java 8 and Java 7 can be installed side by side, so this solves the problem for users that don’t want to upgrade their Java installation because, for example, they have a legacy Java application that they need to support.

Best regards,
George

On Jan 24, 2017, at 2:29 PM, John Hemming <john@hemming.email> wrote:

Could I suggest that it would be worth identifying the sources that require Java 8 enabling anyone who wants a previous compilation to know which sources are not compatible. If developers are careful for a period not to develop incompatibilities between classes then that should make it possible for users to continue with J7 if it is important to them.

It is in the end only a timing issue.

On 24/01/2017 17:59, George Politis wrote:

Hi Ingo, thanks for chiming in.

By moving to Java 8 we’re not dropping support neither for Ubuntu 14.04 nor for Jessie, since it’s possible to install OpenJDK from either a PPA on Ubuntu 14.04 or jessie-backports on Jessie. This should be fine because users anyway have to add a third party repo to install any Jitsi project.

Best regards,
George

On Jan 24, 2017, at 11:53 AM, Ingo Bauersachs <ingo@jitsi.org> wrote:

The Jitsi team is looking into moving to Java 8 for the Jitsi
Videobridge, LibJitsi. Java 8 bytecode is not compatible with Java 7
bytecode, so while you can use Java 7 dependencies in your Java 8
projects, the opposite is not possible.

This will force projects that depend on the JVB and LJ to use a Java >= 8
compiler and runtime (so, for example, Jicofo and Jitsi will have to at least
be compiled with JDK >= 8).

If any members of the community have concerns or other thoughts on this, I
invite you to raise them in this thread.

Moving to Java 8 has been an issue because as we wanted to support Ubuntu 14.04 and Debian Jessie. Is that not a requirement anymore?

Debian Stretch (which comes with Java 8 by default) is in freeze currently. AFAIK it should be released as stable in 6-8 months and I would wait for that to happen before we require Java 8.

Best regards,
George Politis

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

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


#14

Hi Guus,

I think the issue is more about code maintainability, avoiding code duplication, avoiding hacks, code performance and security (that you mentioned) etc., than which party to make happy. These are real problems that we have today and, if we decide to stick to Java 7, the situation will only get worse as we move forward.

In order to better understand what the issue is here, can somebody please describe a practical unsolvable problem that will be caused by moving LJ (and its reverse dependencies) to Java 8?

Best regards,
George

···

On Jan 25, 2017, at 1:34 AM, Guus der Kinderen <guus.der.kinderen@gmail.com> wrote:

For what it's worth, I think that the choice to move to Java 8 depends on what group of people you want to please most: developer (which will like the new Java 8 features), or Debian admins (which will like the Java 7 compatibility with Debian). On a side note: from an administrative perspective, it would be good to use Java 8 at runtime, as this brings security and performance improvements.

On 25 January 2017 at 00:10, George Politis <gp@jitsi.org <mailto:gp@jitsi.org>> wrote:
Hi Ingo,

> On Jan 24, 2017, at 4:27 PM, Ingo Bauersachs <ingo@jitsi.org <mailto:ingo@jitsi.org>> wrote:
>
>> I agree that it’s not great to have an additional extra step to enable the
>> Jessie backports repo or the OpenJDK PPA, but people that were able to
>> successfully install any Jitsi product should already be familiar with the
>> process of adding a third party repo.
>
> Adding a ppa on Ubuntu is easy enough AFTER you found out that a) you need to do that and b) which one.

I didn’t explicitly mention it, but we will of course update the instructions to include that additional extra step, as Emil has already pointed out.

> But adding an apt-pinning on Debian is next to impossible for an average admin.
> Adding it automatically isn't an option either, it might break existing installed software.

Whenever we move to Java 8 we will face this problem. On the up-side, Java 8 and Java 7 can be installed side by side, so people who actually need Java 7 can still use it.

>
> For Jitsi Desktop, it isn't necessary (or at least wasn't until and including 2.8) to add a repo. Downloading the .deb and dkpg -i was enough.

And if we target Java 8, it will only require an additional step: downloading the Java 8 JRE deb and dpkg -i.

> I understand that nobody working at Atlassian doesn't care about this anymore, but I still do.

Jitsi was mentioned in the initial email and we are having an open discussion with the community.

> See [1] for the painful experience of a user trying to install Jitsi.
>

How is sticking to Java 7 going to fix our documentation, which is a problem that already exists and has caused the problem described in the thread that you referenced?

>> On the other hand, if we chose to stay with Java 7 for the foreseeable
>> future, then the devs have resort to hacks in order to be able to use some of
>> the functionality and the classes that are currently available in Java 8.
>> Hacks not only reduce the maintainability of the code but also the replicated
>> Java 8 classes and/or functionality will never work as well as in Java 8
>> because they require the underlying JVM/bytecode changes.
>
> Which classes would need to be duplicated? So far, I haven't come anything in the JDK that would necessitate Java 8. The useful things are lambdas and streams. And this doesn't justify the hurdles.

There are open PRs in LJ now that copy Java 8 classes and I’ve also copied classes from Java 8 in the past because it makes sense to use them. Also, ice4j has some hackery to activate features when it runs on JRE 8.

>
>> In the end, it’s in the best interest of the end users to have a high quality
>> and maintainable source code.
>
> Previously the policy was to stick with Java current - 1. Java 9 isn't released yet, so this would currently still equate to Java 7. If installing PPA's and other repositories is all of a sudden a valid option, then we could have migrated to Java 8 in late 2014 when I asked about that, and had forgotten about the fact that it isn't available in Ubuntu 14.04 and Debian.

I’m surprised to hear that we have such a policy, I wasn’t aware of it, but I think we should have migrated to Java 8 in late 2014.

Best regards,
George

>
>> Best regards,
>> George
>
> Ingo
>
> [1] http://lists.jitsi.org/pipermail/users/2017-January/012145.html
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org <mailto:dev@jitsi.org>
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org <mailto: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


#15

That sounds like a good proposal. Although I have worked professionally in computing since 1981 (apart from a break of about 12 years in politics) I have not yet used git properly.

···

On 25/01/2017 17:33, George Politis wrote:

Hi John, I’m still trying to understand what your would like to achieve and why you need git forking? The Java 7 code will remain in the git repository. We can add a git tag to mark the transition to Java 8.

On Jan 25, 2017, at 1:40 AM, John Hemming <john@hemming.email> wrote:

I haven't as yet used the forking function in git, but I would have thought you could simply fork the system prior to applying any Java 8 and refer people to the Java 7 version.

Obviously as someone who has not done this (yet - I do intend doing this for the relevant work on the bridge as soon as I have something that is in a good enough state) I cannot be certain that I understand how it works.

On 24/01/2017 20:51, George Politis wrote:

Hi John, thanks for chiming in.

I think we either stick with Java 7 or go with Java 8. We don’t have the time to support the sophisticated setup that you describe.
  However, Java 8 and Java 7 can be installed side by side, so this solves the problem for users that don’t want to upgrade their Java installation because, for example, they have a legacy Java application that they need to support.

Best regards,
George

On Jan 24, 2017, at 2:29 PM, John Hemming <john@hemming.email> wrote:

Could I suggest that it would be worth identifying the sources that require Java 8 enabling anyone who wants a previous compilation to know which sources are not compatible. If developers are careful for a period not to develop incompatibilities between classes then that should make it possible for users to continue with J7 if it is important to them.

It is in the end only a timing issue.

On 24/01/2017 17:59, George Politis wrote:

Hi Ingo, thanks for chiming in.

By moving to Java 8 we’re not dropping support neither for Ubuntu 14.04 nor for Jessie, since it’s possible to install OpenJDK from either a PPA on Ubuntu 14.04 or jessie-backports on Jessie. This should be fine because users anyway have to add a third party repo to install any Jitsi project.

Best regards,
George

On Jan 24, 2017, at 11:53 AM, Ingo Bauersachs <ingo@jitsi.org> wrote:

The Jitsi team is looking into moving to Java 8 for the Jitsi
Videobridge, LibJitsi. Java 8 bytecode is not compatible with Java 7
bytecode, so while you can use Java 7 dependencies in your Java 8
projects, the opposite is not possible.

This will force projects that depend on the JVB and LJ to use a Java >= 8
compiler and runtime (so, for example, Jicofo and Jitsi will have to at least
be compiled with JDK >= 8).

If any members of the community have concerns or other thoughts on this, I
invite you to raise them in this thread.

Moving to Java 8 has been an issue because as we wanted to support Ubuntu 14.04 and Debian Jessie. Is that not a requirement anymore?

Debian Stretch (which comes with Java 8 by default) is in freeze currently. AFAIK it should be released as stable in 6-8 months and I would wait for that to happen before we require Java 8.

Best regards,
George Politis

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

_______________________________________________
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


#16

I think the issue is more about code maintainability, avoiding code
duplication, avoiding hacks, code performance and security (that you
mentioned) etc., than which party to make happy. These are real problems that
we have today and, if we decide to stick to Java 7, the situation will only
get worse as we move forward.

In order to better understand what the issue is here, can somebody please
describe a practical unsolvable problem that will be caused by moving LJ (and
its reverse dependencies) to Java 8?

For Meet: The installation for an average admin on Debian Jessie.
For Desktop: The installation for all Linux users whose distribution is still on Java 7.

At the very least, please don't commit anything before we have Jitsi Desktop 2.10 out.

Best regards,
George

Ingo


#17

Hey,

Since Debian stable won’t get any updates, do you foresee any problem if this was done after Stretch gets frozen (after Jitsi Desktop 2.10, that is) ?

Cheers,

···

On Jan 25, 2017, at 21:06, Ingo Bauersachs <ingo@jitsi.org> wrote:

I think the issue is more about code maintainability, avoiding code
duplication, avoiding hacks, code performance and security (that you
mentioned) etc., than which party to make happy. These are real problems that
we have today and, if we decide to stick to Java 7, the situation will only
get worse as we move forward.

In order to better understand what the issue is here, can somebody please
describe a practical unsolvable problem that will be caused by moving LJ (and
its reverse dependencies) to Java 8?

For Meet: The installation for an average admin on Debian Jessie.
For Desktop: The installation for all Linux users whose distribution is still on Java 7.

At the very least, please don't commit anything before we have Jitsi Desktop 2.10 out.

--
Saúl


#18

In order to better understand what the issue is here, can somebody
please describe a practical unsolvable problem that will be caused by
moving LJ (and its reverse dependencies) to Java 8?

For Meet: The installation for an average admin on Debian Jessie. For
Desktop: The installation for all Linux users whose distribution is
still on Java 7.

At the very least, please don't commit anything before we have Jitsi
Desktop 2.10 out.

Since Debian stable won’t get any updates, do you foresee any problem if this
was done after Stretch gets frozen (after Jitsi Desktop 2.10, that is)?

There are basically no components of Jitsi in Debian, so I don't see how the freeze would change anything. Everyone who's not on testing/sid won't have Java 8 and thus cannot install Jitsi (be it Meet or Desktop) without adding a Java 8 repository.

Cheers,

Ingo