Increase IzPack minimum JDK requirements

298 views
Skip to first unread message

Patrick Reinhart

unread,
Mar 12, 2020, 6:07:05 AM3/12/20
to izpack-dev
Hi everyone,

I wanted to know about your all opinions about to lift up the minimum JDK requirements for IzPack for the new releases to come. Is there a preferred minimum version?

At the moment the minimal version is at 1.6 where it's extremely hard or in the last months impossible to build it on open source based platforms. Should we move to the already no longer supported version 8 in a first step for a coming version 5.2.x version?

Thanks for your comments on that topic.

Patrick

René Krell

unread,
Mar 12, 2020, 6:23:54 AM3/12/20
to izpack-dev
OK from my point of view.

In this case
  • I'd increase the new release version to 5.2.0 (master branch and version tag in JIRA)
  • created a Git branch 5.1 to reflect the breaking change and to allow anyone who sits on JRE 6 to maintain the old version.

René

zosrothko

unread,
Oct 22, 2020, 8:58:45 AM10/22/20
to izpack-dev
Hi

" At the moment the minimal version is at 1.6 where it's extremely hard or in the last months impossible to build it on open source based platforms" What do you mean by hard or impossible to build on open source platforms?

FA

Dieter Stüken

unread,
Oct 23, 2020, 4:46:25 AM10/23/20
to izpack-dev

The mentioned Java version 1.6 is from 2006. Support (i.e. public available installers) ended 2013.

If someone is interested in a new version of IzPack, will he still be forced upon using 1.6?

And 1.6 was neither open source at that time, nor is it clear if Oracle even permits using it this way.



The current LTE Version is Java 11 which works pretty well even with ancient Java code.

If someone sticks on i.e. Java 8 he should really think about upgrading his Java version first.

 

Dieter.

Reinhart Patrick

unread,
Oct 23, 2020, 4:58:36 AM10/23/20
to izpac...@googlegroups.com
At the moment I raised the minimum requirement for building izPack 5.2.x to JDK 8. Also I'm researching what library update are needed in order to support JDK 8 in the first place and looking into the JDK 11 requirements next...

Patrick

--
You received this message because you are subscribed to the Google Groups "izpack-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to izpack-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/izpack-dev/19b19867-a034-4c14-99eb-1422ce2b04dcn%40googlegroups.com.

Ron Wheeler

unread,
Oct 23, 2020, 11:10:02 AM10/23/20
to izpac...@googlegroups.com
1.6:
Is anyone actually able to build and test a new iZPack on 1.6?
I do not have 1.6 installed anywhere.
If none of the developers is able to build and test a 1.6, then it is not possible to guarantee that it will work on 1.6 so 1.6 is not the minimal version regardless of what the docs say.

1.8:
Notwithstanding the current pace of new Linux versions, I would guess that a number of people are able to build and test on 1.8.

Is there any reason not to support 1.8?
- Is there some feature from 1.9+ that must be used to make IzPack function?

Given the very good history of upward compatibilty the Java JRE, is there any reason why a user would have problems running an IzPack built with version 8 on any newer version?

Ron

Ron Wheeler

unread,
Oct 23, 2020, 11:21:08 AM10/23/20
to izpac...@googlegroups.com

I would be surprised if any library that ran under 1.6 would not work with 1.8.

In general it would be good to update libraries to later versions to get the bug fixes but I would be surprised if a library written to support Java 1.6 failed under 8.

Why move the minimum past 8?
I have never had a problem going from 1.8 to 11 or 14 and it has not been a recurring issue in the media.

Unless there is some feature that can not be implemented in Java 8, I would suggest supporting 1.8 and dropping earlier versions.

IMHO, Increasing the minimum should only be done if there is no one capable of building and testing on the current minimum or there is an important functionality upgrade that can only be done with a newer Java.


Ron

On 2020-10-23 4:58 a.m., Reinhart Patrick wrote:

Francis ANDRE

unread,
Oct 23, 2020, 1:58:19 PM10/23/20
to izpac...@googlegroups.com, Reinhart Patrick

Hello

I do not quite understand why the minimum requirement for building IzPack has been raised to JDK 8. When one specifies an specific version of the JDK, is it because one is using specific features of the Java language at the level specified. For example, using lambda expression requires the JDK 1.8. But in case of IzPack, there is no such code even the features of 1.7 are not used. Thus all IzPack code can be compiled using the source level of 1.6.

We are working for the AS400 system and some OS version supports only the 1.6 JDK. Thus could you reconsider the required level of the source language be the 1.6 instead of 1.8, hence not requiring a 1.8 JDK?

Regards

To view this discussion on the web visit https://groups.google.com/d/msgid/izpack-dev/CAFKSXJZSwWrMg4gx%2BFzNhNrDO5r%3DUOdNf8qB0bRJvuLbyPtXLA%40mail.gmail.com.
-- 
Francis ANDRE
R&D
Metrixware Systemobjects SAS
SPACES Le Belvédère
1-7, cours Valmy
92923 Paris La Defense Cedex, France

Francis ANDRE

unread,
Oct 23, 2020, 1:59:45 PM10/23/20
to izpac...@googlegroups.com


Le 23/10/2020 à 10:46, 'Dieter Stüken' via izpack-dev a écrit :

The mentioned Java version 1.6 is from 2006. Support (i.e. public available installers) ended 2013.

Your are talking of the Oracle JDK, but there are others JDK like the IBM ones which still are supported at level 1.6 (on AS400 for example)
--
You received this message because you are subscribed to the Google Groups "izpack-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to izpack-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/izpack-dev/19b19867-a034-4c14-99eb-1422ce2b04dcn%40googlegroups.com.
-- 
Francis ANDRE
R&D
Metrixware Systemobjects SAS
SPACES Le Belvédère
1-7, cours Valmy
92923 Paris La Defense Cedex, France

Patrick Reinhart

unread,
Oct 25, 2020, 3:08:42 PM10/25/20
to izpac...@googlegroups.com
I understand that there are situations in which there is no way to upgrade, but in this situation up to version 4.1.3 can be used in that case. 

As the izPack project is done in the open, we do not have any resources to compile and test with older Java Versions on the used open build platforms and therefore moved to 1.8 (and will be moving forward as soon those options are no longer available)

Patrick


Francis ANDRE

unread,
Oct 26, 2020, 3:13:13 AM10/26/20
to izpac...@googlegroups.com, Patrick Reinhart


Le 25/10/2020 à 20:08, Patrick Reinhart a écrit :
I understand that there are situations in which there is no way to upgrade, but in this situation up to version 4.1.3 can be used in that case. 

As the izPack project is done in the open, we do not have any resources to compile and test with older Java Versions on the used open build platforms and therefore moved to 1.8 (and will be moving forward as soon those options are no longer available)

But why??? There is no need to build & test IzPack with the JDK 8 since it's base code is using only the 1.6 java language specification. You can use a JDK 1.8 on the build platform of your choice, but stay in 1.6 with the -source/-target options as

jdk1.8/bin/javac ...-source=1.6 -target=1.6 and the generated classes with run using a jre 1.6, a jre 1.7 and a jre 1.8

Joined 2 builds log of IzPack, one with  <source>1.6</source><target>1.6</target> and the second with <source>1.8</source><target>1.8</target>. Both are equal except all timestamp.


install-1.8.log
install-1.6.log

Patrick Reinhart

unread,
Oct 26, 2020, 5:57:52 AM10/26/20
to Francis ANDRE, izpac...@googlegroups.com
Am 26.10.20 um 08:16 schrieb Francis ANDRE:


Le 25/10/2020 à 20:08, Patrick Reinhart a écrit :
I understand that there are situations in which there is no way to upgrade, but in this situation up to version 4.1.3 can be used in that case. 

As the izPack project is done in the open, we do not have any resources to compile and test with older Java Versions on the used open build platforms and therefore moved to 1.8 (and will be moving forward as soon those options are no longer available)

But why??? There is no need to build & test IzPack with the JDK 8 since it's base code is using only the 1.6 java language specification. You can use a JDK 1.8 on the build platform of your choice, but stay in 1.6 with the -source/-target options as

jdk1.8/bin/javac ...-source=1.6 -target=1.6 and the generated classes with run using a jre 1.6, a jre 1.7 and a jre 1.8

Joined 2 builds log of IzPack, one with  <source>1.6</source><target>1.6</target> and the second with <source>1.8</source><target>1.8</target>. Both are equal except all timestamp.


I know that up to JDK 11 a target version of 1.6 is supported, but any JDK following (15 at the time of writing) will only support 1.7. Also we need to support newer JDK Platforms in the future and already had to do significant changes to support those, just in order to be executable in there. If izPack want to stay relevant as an installer platform also for newer projects, we need to move on, as sadly it is for those who need to support and use older versions of a JDK though. For the moment I could set the minimum source level back, but this would only be for a couple more months maybe the next release and I consider it not to be worth while as I would like to extend the tests and energy to newer JDKs.

Patrick

Dieter Stüken

unread,
Oct 26, 2020, 7:05:59 AM10/26/20
to izpack-dev
patrick.....com schrieb am Montag, 26. Oktober 2020 um 10:57:52 UTC+1:
Am 26.10.20 um 08:16 schrieb Francis ANDRE:

But why??? There is no need to...

You are totally right, the current code works perfectly with 1.6. But I think you want to profit from nice new features and bug fixes, or why are you expecting a new release? But, this has to be realized by the izpack developer(s). May be some developers are still using a handaxe, but we have lasers today. So even if it seems possible to do so, it prevents us from a rapid and modern development.

But there are other aspects:
Using -target=1.6 looks promising and may generate proper byte code to run with a 1.6 VM (especially if exactly this code run with 1.6 before).  But it still links against its own bootclasspath (i.e. 1.8.). So you have to be very careful if you change anything with the code. Using -source=1.6 prevents you from using lambda expressions, but it does not prevent you from calling any method which did not exist wit 1.6 or became a different behavior. To get things right you also need to specify the -bootclasspath option to link against some JDK 1.6 installation you still have on disk (or not).

Interestingly this changed since 9 with its new -release option. So Java 9 is capable to verify even its API calls against older versions (>=1.6) without the need of any external bootclasspath. So I agree to Patricks statement: it may be possible to stay with 1.6 for a while, but not forever. But it might be hard to realize it using 1.8. So, if Java 9 or 11 is still capable to produce valid 1.6 bytecode using the current source code, I currently don't have a problem with it.

In order to support 1.6 to save the life of some AS400 system for the next century, we may think of a fork some day. It may still receive backports for serious bug fixes, but does not inhibit us from any further development. And if I have a look into the source code I got the impression: renovations and refactorings are badly necessary....

Dieter.

Francis ANDRE

unread,
Oct 27, 2020, 11:18:11 AM10/27/20
to izpac...@googlegroups.com

Dieter


In order to support 1.6 to save the life of some AS400 system for the next century, we may think of a fork some day. It may still receive backports for serious bug fixes, but does not inhibit us from any further development. And if I have a look into the source code I got the impression: renovations and refactorings are badly necessary....

This is a huge effort... but unless you want to refactor using lamdba, there is no real need to go to Java 8

And gooing to JavaSE > 9 is another story from my point of view

Anyway, I am fine with your proposal to make a specific branch/fork for staying on the "1.6" code base one day

Francis


Dieter.
--
You received this message because you are subscribed to the Google Groups "izpack-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to izpack-dev+...@googlegroups.com.

Dieter Stüken

unread,
Oct 27, 2020, 6:08:23 PM10/27/20
to izpack-dev
franci... schrieb am Dienstag, 27. Oktober 2020 um 16:18:11 UTC+1:

This is a huge effort... but unless you want to refactor using lamdba, there is no real need to go to Java 8

And gooing to JavaSE > 9 is another story from my point of view


OK, if you aim to preserve IzPack as it is,  there is no need to change anything ever.
I am developing a huge legacy desktop application since about 20 years. I always jumped to the next Java version available.
It took me about two years to understand the relevance of lambda expressions. Meanwhile I consider them to be essential.
But that is my personal opinion ...

Why is JavaSE > 9 is another story to you?

Dieter.

Francis ANDRE

unread,
Oct 28, 2020, 5:32:22 AM10/28/20
to izpac...@googlegroups.com

Dieter

Le 27/10/2020 à 23:08, 'Dieter Stüken' via izpack-dev a écrit :
OK, if you aim to preserve IzPack as it is,  there is no need to change anything ever.
I am developing a huge legacy desktop application since about 20 years. I always jumped to the next Java version available.
It took me about two years to understand the relevance of lambda expressions. Meanwhile I consider them to be essential.
But that is my personal opinion ...

Why is JavaSE > 9 is another story to you?

Because if one wants to benefit of the new features of Java 9 -- the modularization -- applied to IzPack, on should repackage all IzPack submodules into module of Java 9 and this could be also a costly experience.

From my point of view, the minimum refactoring to apply to IzPack would be to refactor all parametrized type with their effective parameter types and change the afferent code avoiding useless casts and better use generic loops.

Francis


-

Dieter Stüken

unread,
Oct 28, 2020, 6:31:26 AM10/28/20
to izpack-dev
When mentioning java>9 I did not intend to use its language features by now. This is very long term road to take.
Instead I had a look at the -release option of Java 9.  This gives you a safe way to generate java 6 code without relaying an old JDK.
If this works, the build server can safely be driven by Java11 and still produces Java-6 output.

You are right, there are tons of possible refactoring aspects even with java 6 (i.e. generics) before considering lambdas and more.

Before using full fledged modularization, I suggest using the ServiceLoader (since 1.6!).
Managing submodules using a ServiceLoader is a first and important step to separate dependencies.
Initially you are not even forced to use separate jars, but if prepared well, it is possible any time and it opens the door to future modularization.

I just realize:
If IzPack is able to load extensions via a ServiceLoader, it's no problem, to develop future extensions using Java11 while the core remains on Java6. 
 
Dieter

Francis ANDRE

unread,
Oct 28, 2020, 6:50:24 AM10/28/20
to izpac...@googlegroups.com


Le 28/10/2020 à 11:31, 'Dieter Stüken' via izpack-dev a écrit :
When mentioning java>9 I did not intend to use its language features by now. This is very long term road to take.
Instead I had a look at the -release option of Java 9.  This gives you a safe way to generate java 6 code without relaying an old JDK.
If this works, the build server can safely be driven by Java11 and still produces Java-6 output.
That's a great news! let's go in this direction then.


You are right, there are tons of possible refactoring aspects even with java 6 (i.e. generics) before considering lambdas and more.

Before using full fledged modularization, I suggest using the ServiceLoader (since 1.6!).
Managing submodules using a ServiceLoader is a first and important step to separate dependencies.
Initially you are not even forced to use separate jars, but if prepared well, it is possible any time and it opens the door to future modularization.

I just realize:
If IzPack is able to load extensions via a ServiceLoader, it's no problem, to develop future extensions using Java11 while the core remains on Java6. 
A very good point for a new design of IzPack...
 
Dieter
franci...@metrixware.com schrieb am Mittwoch, 28. Oktober 2020 um 10:32:22 UTC+1:

Dieter

Le 27/10/2020 à 23:08, 'Dieter Stüken' via izpack-dev a écrit :
OK, if you aim to preserve IzPack as it is,  there is no need to change anything ever.
I am developing a huge legacy desktop application since about 20 years. I always jumped to the next Java version available.
It took me about two years to understand the relevance of lambda expressions. Meanwhile I consider them to be essential.
But that is my personal opinion ...

Why is JavaSE > 9 is another story to you?

Because if one wants to benefit of the new features of Java 9 -- the modularization -- applied to IzPack, on should repackage all IzPack submodules into module of Java 9 and this could be also a costly experience.

From my point of view, the minimum refactoring to apply to IzPack would be to refactor all parametrized type with their effective parameter types and change the afferent code avoiding useless casts and better use generic loops.

Francis


- 
Francis ANDRE
R&D
Metrixware Systemobjects SAS
SPACES Le Belvédère
1-7, cours Valmy
92923 Paris La Defense Cedex, France
--
You received this message because you are subscribed to the Google Groups "izpack-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to izpack-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/izpack-dev/76beacaa-a496-424e-a818-8dc72e3a63e5n%40googlegroups.com.
-- 
Francis ANDRE
R&D
Metrixware Systemobjects SAS
SPACES Le Belvédère
1-7, cours Valmy
92923 Paris La Defense Cedex, France

Yosra Gouaiel

unread,
Aug 19, 2021, 7:59:13 AM8/19/21
to izpack-dev
Hello,
Anyone knows when the version 5.2.0 will be released

thanks

Patrick Reinhart

unread,
Aug 20, 2021, 1:07:04 PM8/20/21
to izpac...@googlegroups.com
Hi Yosra,

I had no plans to do a release, but if there is the interest of doing so, I will try to do one. I may need to check if I got the all the needed access though.

Patrick


Am 19.08.21 um 13:59 schrieb Yosra Gouaiel:

Yosra Gouaiel

unread,
Aug 26, 2021, 9:30:54 AM8/26/21
to izpack-dev
Yes we need the official release to use it in our prod code , the previous one does not support jdk11 and further 
thanks

Patrick Reinhart

unread,
Aug 31, 2021, 2:10:25 AM8/31/21
to izpac...@googlegroups.com
Hi Yosra,

Still working on getting access in order to publish snapshots and
releases...

Cheers

Patrick


Am 26.08.21 um 15:30 schrieb Yosra Gouaiel:
Reply all
Reply to author
Forward
0 new messages