Not using what is in style guide:

http://docs.puppetlabs.com/guides/style_guide.html#puppet-doc

Currently this module does not work on Scientific Linux. Please support it.

To install the debian packages you need to provide a preseed responsefile to the package resource.

It would be really nice if this could support installing the JDK and JRE on Windows environments.

Because the metadata.json is empty in the repo, I get this error:

err: Could not retrieve catalog from remote server: Error 400 on SERVER: No source module metadata provided for java

Some package providers such as apt automatically pull in recommended and/or suggested packages. This can be disabled with an option to package:

package { 'java':
   name => ...,
   ensure => present,
   install_options => ['--no-install-recommends', '--install-suggests']
}

But puppetlabs-java currently does not support the install_options flag.

The README is really sparse right now. Could we please expand it, to answer questions like:

• How do we specify Java version(s) to install?
• How do we install JDKs and/or JREs?
• How do we install Oracle vs Open JVMs?

version 9.0.0 produces a facter error if the module is installed on a machine with no java installation.
This happens even if the module isnt being called since its happening at fact resolution.
The error is

Error: Facter: Error while resolving custom fact fact='java_version', resolution='': unexpected return

Use Case

To be able to manage jdk/jre packages on debian 12 boxes

Describe the Solution You Would Like

That the module can manage jdk and/or jre packages on debian 12

It is not uncommon to want to REMOVE something.

Therefore, it would be helpful to support ensure => purged and/or ensure => absent.

There seems to be a bug in either Puppet 2.7 or the Oracle RPM that makes ensure => purged not work (it always says created).

A workaround is something like this for init.pp:

  validate_re($version, 'purged|present|installed|latest|^[._0-9a-zA-Z:-]+$')

  # deleted

  case $version {
    'purged': {
      exec {
        "removepackage_$use_java_package_name":
        # Do it "manually" because either Puppet RPM handling bad, or Java RPM can't handle
        command => "/usr/bin/yum -y erase $use_java_package_name",
        onlyif  => "/bin/rpm -ql $use_java_package_name";
      }    
    }
    default: {
      package { 'java':
        ensure => $version,
        name   => $use_java_package_name,
      }
    }
  }

Use Case

The ARM architecture, more specifically AArch64, is getting more popular.
The current implementation only supports x86 and alike installations, but not for any other architecture.

Describe the Solution You Would Like

I would like the ability to use this module to install Java on an AArch64 machine.

Describe Alternatives You've Considered

• Directly installing the java package with the package manager
  • This pulls operating system specific logic to the calling module.

Additional Context

I've created a branch that works for our specific use case.
But I'm not entirely sure it will handle all environments as expected.
https://github.com/0Rick0/puppetlabs-java/tree/feature/support-aarch64

It might also be useful to support other architectures like MIPS, PPC and ARMHF

While its nice to have the 'official' oracle java package, its often less quality then what the distros ship. This is especially going to be an issue when you come to things like Java/Tomcat bundle - as the Redhat Tomcat/Java bundle is nice when managed correctly.

When users install the Java from Redhat, they get support for it from Redhat as well - Oracle's bundle is not supported so not all users would want this and we shouldn't force it onto them.

I think a generic approach is nice - so this module should support multiple potential options. Not sure if this is 1 ticket or multiple though :-).

does it module actually manage to install it oracle java? I does not for me and I could not find any code that make that possible (only oracle can distribute it).

Hi, it looks like the latest version on Puppetforge (1.0.1) does not include the recent changes to support Ubuntu Saucy. Could you please push out a new version?

Might be doing something wrong here, but in trying to apply this manifest straight out of the repo, I got:

undefined method `any?' for "^jdk$|^jre$":String at /etc/puppet/modules/java/manifests/init.pp:19 on node...

Looking at validate_re shows that it's expecting an Array, b/c of the call to .any?. I was able to fix the issue by wrapping []'s around the strings being passed into validate_re like so:

  validate_re($distribution, ['^jdk$|^jre$'])
  validate_re($version, ['installed|^[._0-9a-zA-Z:-]+$'])

Not sure if the fix should be on the validate_re side or the init.pp

Use Case

When upgrading GraalVM Java Subversions over Puppet (i.e. jdk 17.0.4 -> graalvm-22.2 and jdk 17.0.5->graalvm-22.3) my current way to provision needs a workaround in order to function:

file {'/tmp/jdk-0-linux-x64.tar.gz':
    ensure => absent
  }
java::download {'GraalVM-22.3':
    ensure => 'present',
    java_se => 'jdk',
    version => '17',
    version_major => '0',
    version_minor => '5',
    package_type => 'tar.gz',
    url=> 'https://github.com/graalvm/graalvm-ce-builds/releases/download/vm-22.3.0/graalvm-ce-java17-linux-amd64-22.3.0.tar.gz',
    basedir => '/opt/java',
  } 

This is due to the naming of the archive package in download.pp as it does not include subversions. Therefore, if still existing the old archive file will be used and the update will not be successful.

Describe the Solution You Would Like

Include the $version and $minor_release in the naming of the archive-name resulting in jdk-17-0-5-linux-x64.tar.gz

Additional Context

I have already included the changes in a fork and will do a PR if no objections are raised.

To install the debian packages you need to provide a preseed responsefile to the package resource.

It would be handy to allow installation of multiple java instances per machine. Obviously only one would be the default java but others could co-exist.

https://github.com/puppetlabs/puppetlabs-java/blob/master/manifests/params.pp#L25

Not sure why the < 6.3

I see plenty of evidence that Java 7 is routine on many versions of RedHat, Centos, and Scientific:

http://www.oracle.com/technetwork/java/javase/compatibility-417013.html (maybe sound or AWT issues?)

http://www.if-not-true-then-false.com/2010/install-sun-oracle-java-jdk-jre-7-on-fedora-centos-red-hat-rhel/

Describe the Bug

A clear and concise description of what the bug is.

Expected Behavior

A clear and concise description of what you expected to happen.

Steps to Reproduce

Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'

Environment

• Version [e.g. 1.27.0]
• Platform [e.g. Ubuntu 18.04]

Additional Context

Add any other context about the problem here.

Use Case

Sometimes it happens that stuff runs on legacy platforms for reasons. The code in
https://github.com/puppetlabs/puppetlabs-java/blob/main/manifests/init.pp#L97-L106 prevents the use of the module on unsupported platforms. This pattern is quite unique to this module. For example it prevents the use of the same module on Debian 9 (supported until v10.x.x) and Debian 12 (supported since v11.x.x)
When a new version is released user should be able to define default values in his own environment and allow the use on an unsupported platform.

Describe the Solution You Would Like

Remove the failure on unsupported platforms.

Describe Alternatives You've Considered

Having separate branches of the control repo with different module versions. I prefer a single main branch for all environments though. Multiple control-repo branches lead to merge overhead and/or rotting branches.
Different module versions in different branches can also become an issue with inconsistent types.

Additional Context

https://puppetcommunity.slack.com/archives/CFD8Z9A4T/p1713871729247549

Describe the Bug

As per subject, java::adopt reinstalls every time the puppet agent is run.

Expected Behavior

Should only install if the package does not already exist.

Steps to Reproduce

 java::adopt { 'jre' :
   ensure  => 'present',
   version => '11',
   java    => 'jre',
 }

Environment

• java module version: 7.3.0
• Puppet server Version 6.18.0
• Platform CentOS 7

Additional Context

It would not normally matter, except that every time Java is reinstalled, it replaces the cacerts database.

I am also open to workarounds if there is no fix.