F27 Self Contained Change: Decouple system java setting from java command setting

[Jan Kurik]

= Proposed Self Contained Change: Decouple system java setting from
java command setting =
https://fedoraproject.org/wiki/Changes/Decouple_system_java_setting_from_...

Change owner(s):
* Michael Simacek <msimacek AT redhat DOT com>
* Mikolaj Izdebski <mizdebsk AT redhat DOT com>

Alternatives can be used to specify which Java installation should be
the default for the system. Currently, changing the default java
command causes not only a change to the /usr/bin/java symlink, but
also affects the which runtime is used for system installed Java
applications. We propose introduction of separate setting for
system-wide java applications.


== Detailed Description ==
Fedora allows parallel installation of multiple Java runtime
environments and it uses alternatives mechanism to allow the user to
switch between them. JDK packages provide a set of alternatives
symlinks for it's executables. The java symlink is used to determine
the java command (/usr/bin/java), but also determines which runtime
environment is used to run system-wide Java applications installed
from RPMs, such as maven or eclipse. While in theory different Java
runtime environments are drop-in replacements for each other, in
practice some of the applications may stop working properly. Users
usually install alternative JDKs in order to run their own
applications and don't expect that changing the java command will have
effect on the system applications. By introducing a separate setting
for system-wide java, we would avoid this problem. We propose
specifying default Java runtime for RPM-managed applications in
/etc/java/java.conf (this is already possible, but not currently
used). Administrators would still be able to override the system
default if they need to.


== Scope ==
* Proposal owners:
Adjust javapackages-tools to provide default Java setting in /etc/java/java.conf

* Other developers:
N/A (not a System Wide Change)

* Release engineering:
https://pagure.io/releng/issue/6831

* List of deliverables:
N/A (not a System Wide Change)

* Policies and guidelines:
N/A (not a System Wide Change)

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

[Dennis Gilmore]

I would like to see some details on how this is going to be
implemented.

It all seem very vague and handwavy

El jue, 08-06-2017 a las 15:55 +0200, Jan Kurik escribió:
>  = Proposed Self Contained Change: Decouple system java setting from
>  java command setting =
>  https://fedoraproject.org/wiki/Changes/Decouple_system_java_setting_f
>  rom_java_command_setting
>  
>  Change owner(s):
>  * Michael Simacek <msimacek AT redhat DOT com>
>  * Mikolaj Izdebski <mizdebsk AT redhat DOT com>
>  
>  Alternatives can be used to specify which Java installation should be
>  the default for the system. Currently, changing the default java
>  command causes not only a change to the /usr/bin/java symlink, but
>  also affects the which runtime is used for system installed Java
>  applications. We propose introduction of separate setting for
>  system-wide java applications.
>  
>  
>  == Detailed Description ==
>  Fedora allows parallel installation of multiple Java runtime
>  environments and it uses alternatives mechanism to allow the user to
>  switch between them. JDK packages provide a set of alternatives
>  symlinks for it's executables. The java symlink is used to determine
>  the java command (/usr/bin/java), but also determines which runtime
>  environment is used to run system-wide Java applications installed
>  from RPMs, such as maven or eclipse. While in theory different Java
>  runtime environments are drop-in replacements for each other, in
>  practice some of the applications may stop working properly. Users
>  usually install alternative JDKs in order to run their own
>  applications and don't expect that changing the java command will
>  have
>  effect on the system applications. By introducing a separate setting
>  for system-wide java, we would avoid this problem. We propose
>  specifying default Java runtime for RPM-managed applications in
>  /etc/java/java.conf (this is already possible, but not currently
>  used). Administrators would still be able to override the system
>  default if they need to.
>  
>  
>  == Scope ==
>  * Proposal owners:
>  Adjust javapackages-tools to provide default Java setting in
>  /etc/java/java.conf
>  
>  * Other developers:
>  N/A (not a System Wide Change)
>  
>  * Release engineering:
>  https://pagure.io/releng/issue/6831
>  
>  * List of deliverables:
>  N/A (not a System Wide Change)
>  
>  * Policies and guidelines:
>  N/A (not a System Wide Change)
>  
>  * Trademark approval:
>  N/A (not needed for this Change)
>  -- 
>  Jan Kuřík
>  Platform & Fedora Program Manager
>  Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org

[Mikolaj Izdebski]

On 06/16/2017 06:44 PM, Dennis Gilmore wrote:
>  I would like to see some details on how this is going to be
>  implemented. 
It is going to be implemented by updating javapackages-tools package in
Fedora 27 to new upstream release, which includes this change:
https://github.com/fedora-java/javapackages/pull/44/commits/a05123ba74a06...

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk

[Michael Šimáček]

On 2017-06-16 18:44, Dennis Gilmore wrote:
>  I would like to see some details on how this is going to be
>  implemented.
>  
>  It all seem very vague and handwavy 
I've just updated the proposal [1] to be more concrete and detailed. Let 
me know if there are still unclear points.

[1] 
https://fedoraproject.org/wiki/Changes/Decouple_system_java_setting_from_...

Michael

> 
> El jue, 08-06-2017 a las 15:55 +0200, Jan Kurik escribió:
>> = Proposed Self Contained Change: Decouple system java setting from
>> java command setting =
>> https://fedoraproject.org/wiki/Changes/Decouple_system_java_setting_f
>> rom_java_command_setting
>>
>> Change owner(s):
>> * Michael Simacek <msimacek AT redhat DOT com>
>> * Mikolaj Izdebski <mizdebsk AT redhat DOT com>
>>
>> Alternatives can be used to specify which Java installation should be
>> the default for the system. Currently, changing the default java
>> command causes not only a change to the /usr/bin/java symlink, but
>> also affects the which runtime is used for system installed Java
>> applications. We propose introduction of separate setting for
>> system-wide java applications.
>>
>>
>> == Detailed Description ==
>> Fedora allows parallel installation of multiple Java runtime
>> environments and it uses alternatives mechanism to allow the user to
>> switch between them. JDK packages provide a set of alternatives
>> symlinks for it's executables. The java symlink is used to determine
>> the java command (/usr/bin/java), but also determines which runtime
>> environment is used to run system-wide Java applications installed
>> from RPMs, such as maven or eclipse. While in theory different Java
>> runtime environments are drop-in replacements for each other, in
>> practice some of the applications may stop working properly. Users
>> usually install alternative JDKs in order to run their own
>> applications and don't expect that changing the java command will
>> have
>> effect on the system applications. By introducing a separate setting
>> for system-wide java, we would avoid this problem. We propose
>> specifying default Java runtime for RPM-managed applications in
>> /etc/java/java.conf (this is already possible, but not currently
>> used). Administrators would still be able to override the system
>> default if they need to.
>>
>>
>> == Scope ==
>> * Proposal owners:
>> Adjust javapackages-tools to provide default Java setting in
>> /etc/java/java.conf
>>
>> * Other developers:
>> N/A (not a System Wide Change)
>>
>> * Release engineering:
>> https://pagure.io/releng/issue/6831
>>
>> * List of deliverables:
>> N/A (not a System Wide Change)
>>
>> * Policies and guidelines:
>> N/A (not a System Wide Change)
>>
>> * Trademark approval:
>> N/A (not needed for this Change)
>> -- 
>> Jan Kuřík
>> Platform & Fedora Program Manager
>> Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
>> _______________________________________________
>> devel mailing list -- devel(a)lists.fedoraproject.org
>> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>>
>>
>> _______________________________________________
>> devel mailing list -- devel(a)lists.fedoraproject.org
>> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org

[Jiri Vanek]

There are may reasons to not to do this change. At least not to do this as it is
specified.

Where is best place to discus? Discussion already started at java-project(a)redhat.com.[1]

Please advice,

   J.

[1] http://post-office.corp.redhat.com/archives/java-project/2017-June/date.html

On 06/08/2017 03:55 PM, Jan Kurik wrote:
>  = Proposed Self Contained Change: Decouple system java setting from
>  java command setting =
>
> https://fedoraproject.org/wiki/Changes/Decouple_system_java_setting_from_...
>  
>  Change owner(s):
>  * Michael Simacek <msimacek AT redhat DOT com>
>  * Mikolaj Izdebski <mizdebsk AT redhat DOT com>
>  
>  Alternatives can be used to specify which Java installation should be
>  the default for the system. Currently, changing the default java
>  command causes not only a change to the /usr/bin/java symlink, but
>  also affects the which runtime is used for system installed Java
>  applications. We propose introduction of separate setting for
>  system-wide java applications.
>  
>  
>  == Detailed Description ==
>  Fedora allows parallel installation of multiple Java runtime
>  environments and it uses alternatives mechanism to allow the user to
>  switch between them. JDK packages provide a set of alternatives
>  symlinks for it's executables. The java symlink is used to determine
>  the java command (/usr/bin/java), but also determines which runtime
>  environment is used to run system-wide Java applications installed
>  from RPMs, such as maven or eclipse. While in theory different Java
>  runtime environments are drop-in replacements for each other, in
>  practice some of the applications may stop working properly. Users
>  usually install alternative JDKs in order to run their own
>  applications and don't expect that changing the java command will have
>  effect on the system applications. By introducing a separate setting
>  for system-wide java, we would avoid this problem. We propose
>  specifying default Java runtime for RPM-managed applications in
>  /etc/java/java.conf (this is already possible, but not currently
>  used). Administrators would still be able to override the system
>  default if they need to.
>  
>  
>  == Scope ==
>  * Proposal owners:
>  Adjust javapackages-tools to provide default Java setting in /etc/java/java.conf
>  
>  * Other developers:
>  N/A (not a System Wide Change)
>  
>  * Release engineering:
>  https://pagure.io/releng/issue/6831
>  
>  * List of deliverables:
>  N/A (not a System Wide Change)
>  
>  * Policies and guidelines:
>  N/A (not a System Wide Change)
>  
>  * Trademark approval:
>  N/A (not needed for this Change)
>   

-- 
Jiri Vanek
Senior QE engineer, OpenJDK QE lead, Mgr.
Red Hat Czech
jvanek(a)redhat.com    M: [phone]

[Mikolaj Izdebski]

On 06/20/2017 10:48 AM, Jiri Vanek wrote:
>  There are may reasons to not to do this change. At least not to do
> this
>  as it is specified. 
I would like to hear your reasons.

>  Where is best place to discus? Discussion already started at
>  java-project(a)redhat.com.[1] 
Fedora devel list is the right place for that.

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk

Hi,

Frankly, the proposed change seems a great way to accumulate technical debt at a rapid
pace, by helping apps to specify various legacy or proprietary Java variants, and
postponing taking into account openjdk changes indefinitely.

That's more or less what the proprietary unixes did till the whole house of cards
collapsed under the weight of long overdue migration needs.

IIRC the whole alternative system already lets an app specify a specific java version and
producer (at least it did in JPackage time). What it does not let people do is to pretend
an app is java-version and java-producer agnostic when it isn't. 

Regards,

-- 
Nicolas Mailhot

[Michael Šimáček]

On 2017-06-20 20:07, nicolas.mailhot(a)laposte.net wrote:
>  Hi,
>  
>  Frankly, the proposed change seems a great way to accumulate technical debt at a rapid
> pace, by helping apps to specify various legacy or proprietary Java variants, and
> postponing taking into account openjdk changes indefinitely. 
Why do you think so? The proposal doesn't say anything like that. It 
doesn't let apps specify their Java. The setting for Java applications 
will still be global.

Moreover, Fedora doesn't ship legacy or proprietary Java variants.

>  
>  That's more or less what the proprietary unixes did till the whole house of cards
> collapsed under the weight of long overdue migration needs.
>  
>  IIRC the whole alternative system already lets an app specify a specific java version and
> producer (at least it did in JPackage time). What it does not let people do is to pretend
> an app is java-version and java-producer agnostic when it isn't.
>  
%jpackage_script generated launcher scripts don't let an app specify 
java version/provider and that will stay the same.

Michael