picocontainer to 2.15 has started throwing errors on Linux java

[sdyura]

izpack https://github.com/izpack/izpack installer is still used by many projects and it uses picocontainer 2.15
it has stopped working on Linux because of an error in picocontainer 2.15
reported https://izpack.atlassian.net/browse/IZPACK-1786 and https://izpack.atlassian.net/browse/IZPACK-1787

java.lang.ArrayIndexOutOfBoundsException: Index 70131 out of bounds for length 22674
com.izforge.izpack.api.exception.ContainerException: java.lang.ArrayIndexOutOfBoundsException: Index 70131 out of bounds for length 22674
	at com.izforge.izpack.core.container.AbstractContainer.initialise(AbstractContainer.java:312)
	at com.izforge.izpack.core.container.AbstractContainer.initialise(AbstractContainer.java:284)
	at com.izforge.izpack.installer.container.impl.GUIInstallerContainer.<init>(GUIInstallerContainer.java:38)
	at com.izforge.izpack.installer.bootstrap.InstallerGui.run(InstallerGui.java:54)
	at com.izforge.izpack.installer.bootstrap.Installer.launchInstall(Installer.java:289)
	at com.izforge.izpack.installer.bootstrap.Installer.start(Installer.java:233)
	at com.izforge.izpack.installer.bootstrap.Installer.main(Installer.java:78)
Caused by: java.lang.ArrayIndexOutOfBoundsException: Index 70131 out of bounds for length 22674
	at org.picocontainer.paranamer.BytecodeReadingParanamer$ClassReader.<init>(BytecodeReadingParanamer.java:451)
	at org.picocontainer.paranamer.BytecodeReadingParanamer$ClassReader.<init>(BytecodeReadingParanamer.java:431)
	at org.picocontainer.paranamer.BytecodeReadingParanamer$ClassReader.<init>(BytecodeReadingParanamer.java:492)
	at org.picocontainer.paranamer.BytecodeReadingParanamer$ClassReader.<init>(BytecodeReadingParanamer.java:337)
	at org.picocontainer.paranamer.BytecodeReadingParanamer.lookupParameterNames(BytecodeReadingParanamer.java:100)
	at org.picocontainer.paranamer.AdaptiveParanamer.lookupParameterNames(AdaptiveParanamer.java:75)
	at org.picocontainer.paranamer.AnnotationParanamer.lookupParameterNames(AnnotationParanamer.java:110)
	at org.picocontainer.paranamer.CachingParanamer.lookupParameterNames(CachingParanamer.java:75)
	at org.picocontainer.injectors.ParameterNameBinding.getName(ParameterNameBinding.java:38)
	at org.picocontainer.injectors.ConstructorInjector.getGreediestSatisfiableConstructor(ConstructorInjector.java:149)
	at org.picocontainer.injectors.ConstructorInjector.getGreediestSatisfiableConstructor(ConstructorInjector.java:110)
	at org.picocontainer.injectors.ConstructorInjector.access$100(ConstructorInjector.java:51)
	at org.picocontainer.injectors.ConstructorInjector$1.run(ConstructorInjector.java:331)
	at org.picocontainer.injectors.AbstractInjector$ThreadLocalCyclicDependencyGuard.observe(AbstractInjector.java:270)
	at org.picocontainer.injectors.ConstructorInjector.getComponentInstance(ConstructorInjector.java:364)
	at org.picocontainer.behaviors.AbstractBehavior.getComponentInstance(AbstractBehavior.java:64)
	at org.picocontainer.behaviors.Stored.getComponentInstance(Stored.java:91)
	at org.picocontainer.DefaultPicoContainer.getInstance(DefaultPicoContainer.java:699)
	at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:647)
	at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:632)

is there any chance the issue can be fixed and new version released?
thanks

[paul-hammant]

There's a chance, for sure.

Looks like root cause is in Paranamer which I also update, but isn't needed in the Java9+ era

Does izpack need to use BytecodeReadingParanamer that AdaptiveParanamer delegates to? I can say more about the question back to you, if you don't know what I mean

[sdyura]

i do not know much about izpack internals, i am just a user of izpack.
i preliminary search for BytecodeReadingParanamer and AdaptiveParanamer did not find anything relevant

but maybe you can explain it more so i would have enough understanding to investigate

[sucitram]

There have been some commits to the head of the PicoContainer2 project this year adding Java 21 support.

I have had success running IzPack against the current, locally built, PicoContainer snapshot on java 21. With some minor modifications to the PicoContainer build script IzPack will run successfully on Java 17 too.

[sdyura]

@sucitram does this mean the error is fixed and PicoContainer2 just needs another release done?

[sucitram]

That has been my experience. Though I didn't test thoroughly and was only concerned with the PicoContainer artifacts used by IzPack.

@paul-hammant committed the recent changes and would be better placed to comment on the readiness for release.

[paul-hammant]

https://github.com/search?q=repo%3Aizpack%2Fizpack+USE_NAMES&type=code is where Paranamer (not needed at Java-9) is activated.

Java 9 provided its own way of accessing parameter names (for constructors and methods). I am not sure that PicoContainer ever utilized that mechanism, but could have it added.

[paul-hammant]

I've made a branch - https://github.com/picocontainer/PicoContainer2/tree/picocontainer-2.15 if we're doing work on that it would be with (say) JDK-9 or (better) JDK-11 to drop Paranamer and use JDK-9's own way of accessing parameter names.

Or we fix the bug in Paranamer which could be update Paranamer's use of ASM .. https://github.com/paul-hammant/paranamer/blob/master/paranamer-generator/pom.xml#L21 ... then build release a point version of Paranamer, then build a point release of PicoContainer. pom.xml deps being the changes in each

https://mvnrepository.com/artifact/org.ow2.asm/asm/5.2 is newer than 5.1. There's newer still 6, 7, 8 and 9 but backwards compatibility could have been lost in any of those

[paul-hammant]

I've updated Paranamer to latest asm (and latest qdox). https://github.com/paul-hammant/paranamer/commits/master/

For me, this builds under JDK11. That's not released yet. I'll go on try see if that works with PicoContainer 2.15

[paul-hammant]

Using JDK11 First build paranamer from master which makes 2.8.1-SNAPSHOT

Then in a branch of this repo - https://github.com/picocontainer/PicoContainer2/tree/picocontainer-2.15 also using JDK 11, cd into 'picodir thenmvn install`.

That makes picocontainer-2.15.1-SNAPSHOT which you can test izpack and then tell me how that went. I'm not going to release anything until izpack dev team tell me that works for the broken testcase in their testbase :)

[paul-hammant]

I can't add a comment to https://izpack.atlassian.net/browse/IZPACK-1786 for some reason (to link back here)

[sdyura]

i added another comment there, (i think you need an account to post)
hopefully someone with linux can test it, if not i will try dig up a linux computer somewhere

[sdyura]

izpack dev is actually on github https://github.com/izpack/
so maybe can get there attention @rkrell @reinhapa

[paul-hammant]

Team uses mail-lists, too https://izpack.org/mailing-lists/

[reinhapa]

izpack dev is actually on github https://github.com/izpack/ so maybe can get there attention @rkrell @reinhapa

@sdyura I could add the snapshot dependency to the current izpack build if there is an official SNAPSHOT available. (@paul-hammant any chance to publish such a version?)

[reinhapa]

I've made a branch - https://github.com/picocontainer/PicoContainer2/tree/picocontainer-2.15 if we're doing work on that it would be with (say) JDK-9 or (better) JDK-11 to drop Paranamer and use JDK-9's own way of accessing parameter names.>

@paul-hammant This would be my preferred way as I plan to lift the minimal JDK Version to 21 going forward (as older usages should use the older izpack versions)

[reinhapa]

@sdyura just successfully built and tested izpack with Java 21 using the picocontainer-2.15.1-SNAPSHOT version as described by @paul-hammant. Having this as an final version would open the potential to have IzPack be compiled on Java 21 as well as updating a lot of libraries that have various security issues...

[paul-hammant]

Yes, it's all the upgrades you'd need for JDK21 - with JDK11 .class file format, IYKWIM.

I'll go ahead and publish those to maven central - though that might require more pom.xml changes which I'm not familar with in the last few years.

[reinhapa]

I'll go ahead and publish those to maven central - though that might require more pom.xml changes which I'm not familar with in the last few years.

That would be great. I will then update the IzPack project as soon I've got the update in...

[sdyura]

doesn’t izpack need to support java 1.8? as thats still the version most people download from java.com
https://www.java.com/en/download/

[reinhapa]

doesn’t izpack need to support java 1.8? as thats still the version most people download from java.com https://www.java.com/en/download/

You could still use the older revisions of IzPack if you have the need to run it under JDK 8. On the other hand no one will use IzPack for new Projects, it it does not run under later JDKs let alone the security issues we currently have because of libraries we can not update when we want stick on JDK 8. When IzPack stops keeping up to date, we will not have any relevance in the future...

[paul-hammant]

Ugh, I'm stuck with the paranamer release :-(

[ERROR] Failed to execute goal org.sonatype.plugins:nexus-staging-maven-plugin:1.6.7:deploy 
(injected-nexus-deploy) on project paranamer-distribution: Failed to deploy artifacts: Could 
not transfer artifact com.thoughtworks.paranamer:paranamer:jar:javadoc:2.8.1-20250220.125033-1 
from/to ossrh (https://s01.oss.sonatype.org/content/repositories/snapshots): authentication failed for
https://s01.oss.sonatype.org/content/repositories/snapshots/com/thoughtworks/paranamer/paranamer/2.8.1-SNAPSHOT/paranamer-2.8.1-20250220.125033-1-javadoc.jar, 
status: 401 Content access is protected by token -> [Help 1]

Yes, I made a token within the sonatype portal. That's in ~/.m2/settings.xml instead of my old (5 years ago) name+password.

Yes, I can log into https://central.sonatype.com/account and did do to generate the token

Yes I can log into https://oss.sonatype.org/#welcome but see no messages for me

I wish the 401 response came with some debug info in the content of the request. like "no token specified", or "token specified but incorrect", or "that's a correct and valid-today token, but YOU are not authorized to deploy the artifact in question"

I need to pubish paranamer, before I change picocontainer to use the non-SNAPSHOT version and publish that

[reinhapa]

Ugh, I'm stuck with the paranamer release :-(

@paul-hammant I owe you at least one beer if we ever meet in person!

[paul-hammant]

Pat, do you have recent deploy-to-maven-central skills? If yes, could I add you to the so-authorized list to do so and you help me here?

[reinhapa]

Pat, do you have recent deploy-to-maven-central skills? If yes, could I add you to the so-authorized list to do so and you help me here?

Sure, if I can help....

[sdyura]

doesn’t izpack need to support java 1.8? as thats still the version most people download from java.com https://www.java.com/en/download/

You could still use the older revisions of IzPack if you have the need to run it under JDK 8. On the other hand no one will use IzPack for new Projects, it it does not run under later JDKs let alone the security issues we currently have because of libraries we can not update when we want stick on JDK 8. When IzPack stops keeping up to date, we will not have any relevance in the future...

modern java apps all bundle jre so use things like https://conveyor.hydraulic.dev/ for installers

but there are old apps, written to support all java versions, that are still quite popular and need to be able to install on all versions of java, 1.8 to 21. with the same installer. izpack 5.2.3 worked well on all versions until this bug came along.

eventually these projects do need to be updated to more modern solutions, but if its a big project that is a lot of work.

[reinhapa]

but there are old apps, written to support all java versions, that are still quite popular and need to be able to install on all versions of java, 1.8 to 21. with the same installer. izpack 5.2.3 worked well on all versions until this bug came along.

eventually these projects so need to be updated to more modern solutions, but if its a big project that is a lot of work.

I see no reason, why those projects with old Java versions need to update to a newer IzPack version. If you only use Java 8 features (without lambdas & method references) in classes used directly by IzPack there should be no problem with the current version. If you decide to use newer Java language features, you then also will have no problem using an IzPack version that requires a later version Java I guess.

For me as maintainer of the IzPack project wanting to stay relevant, it is required to be able to move forward in regards to new versions and also using of new Java features that may help in order to do so.

[paul-hammant]

@reinhapa It seems ways of publishing to maven central have changed. We used to use mvn release:prepare followed by mvn release:perform It looks like we domvn deploy` now, so I made a bunch of changes toward that. The Sonatype documentation is spread out over many pages. So I figured I needed to update multiple bits,

This page though - https://central.sonatype.org/publish/publish-maven/#distribution-management-and-authentication gives blocks of config that pertain to s01.oss.sonatype.org that I never previous dealt with. So I paste in the code blocks given and take out what I feel are the deprecated bits. I'm also not publishing a snapshot right now. This page only has code fragments for snapshots though.

Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to deploy artifacts: Could not transfer artifact com.thoughtworks.paranamer:paranamer:jar:javadoc:2.8.1-20250221.090517-1 from/to ossrh (https://s01.oss.sonatype.org/content/repositories/snapshots): authentication failed for https://s01.oss.sonatype.org/content/repositories/snapshots/com/thoughtworks/paranamer/paranamer/2.8.1-SNAPSHOT/paranamer-2.8.1-20250221.090517-1-javadoc.jar, status: 401 Content access is protected by token
    at org.sonatype.nexus.maven.staging.deploy.DeployMojo.execute (DeployMojo.java:216)

• The root wagon (itself end of life?) exception is caught, wrapped and rethrown a few times but the message is roughly the same by the time Maven quits.

If there was a body with more detail for the the 401 response, it is long lost.

[paul-hammant]

So I go back to the old publication URL (that I may be grandfathered into) - paul-hammant/paranamer@7938054 - but it is the same. I'm sure as shit I made a token yesterday and pasted locally:

$ cat ~/.m2/settings.xml 
<settings>
  <servers>
    <server>
        <id>ossrh</id>
        <username>Jxxxxxx</username>
        <password>Oxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxh</password>
    </server>
  </servers>
</settings>

I'm lost - the lack of a more precise message is leaving me not wanting to use the maven-central.

GitHub Packages Registry or JitPack are alternatives to Sonatype stuff. If I moved Paranamer and PicoContainer publication one of those, you'd have to reconfigure your deps some.

[reinhapa]

Hmm, I wrote a message to your email address as stated in your Github profile. Also not that "s01.oss.sonatype.org" uses a different token as "oss.sonatype.org". Looking at your change I guess that you should use the later and make sure to get the token from the later site (had same issues in my different projects using one and the other site)

[paul-hammant]

Will continue chat in email :)

[sdyura]

@reinhapa

I see no reason, why those projects with old Java versions need to update to a newer IzPack version. If you only use Java 8 features (without lambdas & method references) in classes used directly by IzPack there should be no problem with the current version. If you decide to use newer Java language features, you then also will have no problem using an IzPack version that requires a later version Java I guess.

For me as maintainer of the IzPack project wanting to stay relevant, it is required to be able to move forward in regards to new versions and also using of new Java features that may help in order to do so.

my project does not use any new java features, but the installer is broken for my users that have a new version of java on Linux.
i only control what version of java my project uses, but i do not control what version of java my users have installed.
so i cant use izpack-5.2.3 because it crashes for some of my users, not because i need any new java features.
I do not want to have multiple installers for different versions of java, most users do not know what version they have.
i need the installer for my project to not crash on new versions of java, as currently it does.
does that make sense or am i missing something?

[paul-hammant]

Link to your project, Yura?

[sdyura]

Link to your project, Yura?

this was the bug report i got from a user: https://sourceforge.net/p/domination/bugs/50/
project website is http://risk.sf.net

[reinhapa]

my project does not use any new java features, but the installer is broken for my users that have a new version of java on Linux.

Just installed the latest version of your project using Java 21 and even the latest 24 early access without any problem as stated in the IZPACK-1786 issue and I'm totally confused... How ever, when there will be a new version available, I will do a new version.

[paul-hammant]

Toward a release of PicoContainer, Paranamer has been released @reinhapa helping me do many years of upgrades to maven-central bits and pieces. Now compiled on JDK-11 byecode level, brings in an optional feature from JDK-9 (parameter name access). I'll get PicoContainer 2.15.1 out in the next few days.

[paul-hammant]

PicoContainer 2.15.1 release is out now - dependent on in JDK11 now.