Just a few of the packages that depend on java-gcj-compat that keep triggering the inclusion of the significantly out of date JRE.

rpm -q --whatrequires java-gcj-compat
java_cup-0.10k-5.el6.x86_64
sinjdoc-0.5-9.1.el6.x86_64
jakarta-commons-pool-1.3-12.7.el6.x86_64
classpathx-jaf-1.0-15.4.el6.x86_64
xml-commons-apis-1.3.04-3.6.el6.x86_64
log4j-1.2.14-6.4.el6.x86_64
xml-commons-resolver-1.1-4.18.el6.x86_64
regexp-1.5-4.4.el6.x86_64
bcel-5.2-7.2.el6.x86_64
jakarta-commons-daemon-1.0.1-8.9.el6.x86_64
ecj-3.4.2-6.el6.x86_64
jakarta-commons-httpclient-3.1-0.9.el6_5.x86_64

also needs to provide 'jaxp_parser_impl'

please do *NOT* (re-)introduce java-gcj-compat requiring 'sinjdoc'. That is clearly bogus. The requirement goes the other direction.

I question mx4j requiring 'bcel'.

Hi, Tomcat is available on all architectures on el6. OpenJDK is only available for x86 and x86_64 -- making OpenJDK provide gcj-compat will satisfy the requirement on only certain architectures, leading to inconsistency in build JDKs across architectures. The same holds for the other packages you listed, I believe.

I am going to close this as WONTFIX as the behavior is correct from JDK perspective. If wrong JDK being pulled in is an issue, please bring this up with the respective component owners.

You COMPLETELY missed the point!!

It doesn't matter if OpenJDK is only available in x86/64bit. The current setup means I can *NEVER* remove the blasted java-1.5.0-gcj by virtue of the dependency chain. Any and *ALL* JDK packages need to be tagged with having features java-gcj-compat and jaxp_parser_impl. If on sparc, mips, or some other obscure and dying architectures still need java-1.5.0-gcj because it's the only option, don't have a OpenJDK implementation, or the only option for a modern JRE is 3rd party tarball from Oracle, that's perfectly fine.

This matter is akin to cronie-anacron and cronie-noanacron. RHEL defaults to installing the anacron version but we are able to rip it out and substitute -noanacron because it provides the same RPM feature tags.

I'm NOT asking that the default package be changed away from java-1.5.0-gcj, but rather I should be allowed to install OpenJDK-1.7 after the fact and then remove java-1.5.0-gcj and for it do it cleanly without triggering a mass-uninstall because OpenJDK hasn't been tagged properly. OpenJDK-* and java-1.5.0-gcj are identical in role and capabilities, the RPM's feature attributes simply need to be updated to reflect that fact.

I understand what you are asking and I am telling you that that will cause inconsistencies in the build root.

Take for example log4j that you mentioned. Currently it requires java-1.5.0-gcj. If OpenJDK RPM was to provide this requirement, it may be pulled in (yum does not guarantee which package is pulled in if multiple packages provide a requirement). If OpenJDK is pulled in, it will supersede java-1.5.0-gcj and become the default build JDK for that buildroot, thus causing tomcat to be built with OpenJDK instead of with GCJ.

The most obvious way to get around this is to blacklist OpenJDK from the buildroot, but that does not address any customers who rebuild packages on their end.

What you are proposing is not impossible, but it is not under the sole purview of OpenJDK. It is of least concern to OpenJDK and most to the packages (requiring gcj-compat) themselves which is why I said you should talk to their maintainers first.

Furthermore, this issue should be opened as an RFE against the RHEL distribution as this is not a bug in OpenJDK packaging. This issue has been addressed in RHEL-7 where GCJ is no longer present.

I'll admit I look at the world thru Sysadmin glasses. I see what you're getting at but why should millions of users suffer and get dinged every time by security audits? It was Red Hat's choice to offer multiple alternative Java Runtimes. Every package that is not properly tagged is an incontrovertible bug - it's lying by omission. When I query RPM for features I have every right to expect I get the FULL and correct answer.

You can't just pick and choose, "oh, i'll tag this package as a java interpreter but not these other 6 even though they are all equivalent because I can't be arsed to update our build config to blacklist everything that isn't the one we've chosen as the baseline."

The whole point of the features described in RPM is so that the user can swap out equivalent packages. Sendmail vs Postfix is another example of equivalency and it works as it should. If I have both and then remove the other I don't get a massive RPM unwind.

Now maybe 'java-gcj-compat' is a tag that just needs to go away in favor of plain old 'java'. I don't know the history behind it and 'jaxp_parser_impl'. If so, then there are a few dozen packages that need their dependencies updated to remove the aforementioned values. Or we could just fix OpenJDK (it's all of 1 line in a SPEC file! either as 'provides' or 'obsoletes') and the blacklist and the impact is minimal to the point nobody will even notice. That's how you do modular software.

RHEL6 is supported for like 5 years right? I appreciate that RHEL7 has moved on from 1.5.0-gcj but even in RHEL7, it is an error for OpenJDK NOT to report all applicable features. I can't speak to RHEL7 because I don't run it.

Jiri, can we do the above safely?

I'm not sure if we can. I'm a bit afraid of it.

IMHO the only correct solution is to get rid of all
 requires java-gcj-compat
and  start to require
 requires javaX

Where X is correct name and version
Most likely "java >= 1.5" for most of them and java = 1.5 for special cases.

This is general answer.

However - for rhe6 life-cycle, (that means rhel 6, no zstream) I think we may add  java-gcj-compat to list of provides. With note that it is workaround, and will nor be supported in any future rhel.

Of course if any level rhel6 testing will fail, this will really become closed as cantfix.

Yeah, my worry with changing in the OpenJDK packages is as you stated, packages that specifically require 1.5 will fail and will not be noticed until they start failing. Can you generate a list of packages that need gcj compat? Perhaps we can mass mail the maintainers of those packages and ask them.

repoquery --whatrequires java-gcj-compat 

adaptx-0:0.9.13-8.1.el6.x86_64
avalon-framework-0:4.1.4-7.el6.x86_64
bcel-0:5.2-7.2.el6.x86_64
bea-stax-0:1.2.0-0.5.rc1.2.el6.x86_64
bea-stax-api-0:1.2.0-0.5.rc1.2.el6.x86_64
castor-0:0.9.5-5.3.el6.x86_64
castor-demo-0:0.9.5-5.3.el6.x86_64
castor-test-0:0.9.5-5.3.el6.x86_64
castor-xml-0:0.9.5-5.3.el6.x86_64
classpathx-jaf-0:1.0-15.4.el6.x86_64
ecj-1:3.4.2-6.el6.x86_64
flute-0:1.3.0-3.OOo31.el6.x86_64
jakarta-commons-codec-0:1.3-11.7.el6.x86_64
jakarta-commons-daemon-1:1.0.1-8.9.el6.x86_64
jakarta-commons-daemon-jsvc-1:1.0.1-8.9.el6.x86_64
jakarta-commons-httpclient-1:3.1-0.9.el6_5.x86_64
jakarta-commons-pool-0:1.3-12.7.el6.x86_64
jakarta-oro-0:2.0.8-6.6.el6.x86_64
java_cup-1:0.10k-5.el6.x86_64
javacc-0:4.1-0.5.el6.x86_64
jcommon-serializer-0:0.3.0-3.1.el6.x86_64
jlex-0:1.2.6-9.5.el6.x86_64
junit-0:3.8.2-6.5.el6.x86_64
junit-demo-0:3.8.2-6.5.el6.x86_64
jython-0:2.2.1-4.8.el6.x86_64
jzlib-0:1.0.7-7.5.el6.x86_64
ldapjdk-0:4.18-6.el6.x86_64
libbase-0:1.0.0-3.OOo31.1.el6.x86_64
libfonts-0:1.0.0-3.OOo31.el6.x86_64
libformula-0:0.2.0-3.OOo31.1.el6.x86_64
liblayout-0:0.2.9-4.OOo31.el6.x86_64
libloader-0:1.0.0-2.OOo31.1.el6.x86_64
libreadline-java-0:0.8.0-24.3.el6.x86_64
librepository-0:1.0.0-2.OOo31.1.el6.x86_64
log4j-0:1.2.14-6.4.el6.x86_64
pentaho-libxml-0:1.0.0-2.OOo31.1.el6.x86_64
pentaho-reporting-flow-engine-1:0.9.2-5.OOo31.el6.x86_64
regexp-0:1.5-4.4.el6.x86_64
sac-0:1.3-5.1.el6.x86_64
sinjdoc-0:0.5-9.1.el6.x86_64
xml-commons-apis-0:1.3.04-3.6.el6.x86_64
xml-commons-resolver-0:1.1-4.18.el6.x86_64

From those

flute-0:1.3.0-3.OOo31.el6.x86_64
javacc-0:4.1-0.5.el6.x86_64
libbase-0:1.0.0-3.OOo31.1.el6.x86_64
libfonts-0:1.0.0-3.OOo31.el6.x86_64
libformula-0:0.2.0-3.OOo31.1.el6.x86_64
liblayout-0:0.2.9-4.OOo31.el6.x86_64
libloader-0:1.0.0-2.OOo31.1.el6.x86_64
librepository-0:1.0.0-2.OOo31.1.el6.x86_64
pentaho-libxml-0:1.0.0-2.OOo31.1.el6.x86_64
pentaho-reporting-flow-engine-1:0.9.2-5.OOo31.el6.x86_64
regexp-0:1.5-4.4.el6.x86_64
sac-0:1.3-5.1.el6.x86_64


requires *also* java

The list of owners is a bit suspicious:

adaptx                  RHEL-6.0                                 akurtako       
avalon-framework        RHEL-6.0                                 swagiaal       
bcel                    RHEL-6.0                                 jjohnstn       
bea-stax                RHEL-6.0                                 patrickm       
castor                  RHEL-6.0                                 jjohnstn       
classpathx-jaf          RHEL-6.0                                 jjohnstn       
ecj                     RHEL-6.0                                 dbhole         
flute                   RHEL-6.0                                 caolanm        
jakarta-commons-codec   RHEL-6.0                                 swagiaal       
jakarta-commons-daemon  RHEL-6.0                                 jjohnstn       
jakarta-commons-httpclient RHEL-6.0                                 jjohnstn       
jakarta-commons-pool    RHEL-6.0                                 jjohnstn       
jakarta-oro             RHEL-6.0                                 jjohnstn       
java_cup                RHEL-6.0                                 patrickm       
javacc                  RHEL-6.0                                 jjohnstn       
jcommon-serializer      RHEL-6.0                                 caolanm        
jlex                    RHEL-6.0                                 patrickm       
junit                   RHEL-6.0                                 swagiaal       
junit4                  RHEL-6.0                                 akurtako       
jython                  RHEL-6.0                                 alee           
jzlib                   RHEL-6.0                                 jjohnstn       
ldapjdk                 RHEL-6.2                                 mharmsen       
libbase                 RHEL-6.0                                 caolanm        
libfonts                RHEL-6.0                                 caolanm        
libformula              RHEL-6.0                                 caolanm        
liblayout               RHEL-6.0                                 caolanm        
libloader               RHEL-6.0                                 caolanm        
libreadline-java        RHEL-6.0                                 swagiaal       
librepository           RHEL-6.0                                 caolanm        
log4j                   RHEL-6.0                                 jjohnstn       
pentaho-libxml          RHEL-6.0                                 caolanm        
pentaho-reporting-flow-engine RHEL-6.0                                 caolanm        
regexp                  RHEL-6.0                                 swagiaal       
sac                     RHEL-6.0                                 caolanm        
sinjdoc                 RHEL-6.0                                 dbhole         
xml-commons-apis        RHEL-6.0                                 akurtako       
xml-commons-resolver    RHEL-6.0                                 patrickm  

but seems correct

mharmsen       : ldapjdk
alee           : jython
akurtako       : adaptx junit4 xml-commons-apis
swagiaal       : junit avalon-framework regexp libreadline-java jakarta-commons-codec
jjohnstn       : log4j bcel castor classpathx-jaf jzlib jakarta-commons-daemon jakarta-commons-httpclient jakarta-commons-pool jakarta-oro javacc                  
caolanm        : jcommon-serializer flute libbase libfonts libformula liblayout libloader librepository pentaho-libxml pentaho-reporting-flow-engine sac                     
dbhole         : sinjdoc ecj
patrickm       : xml-commons-resolver bea-stax java_cup jlex

Most of the packages seems to be ok with pure java. What next?

Are they OK with removing it midstream i.e. without recompilation? If so, then it should just be a matter of adding the Provides to OpenJDK and we're done.

Running into bz1211995 and this bz causes ipa server to not install.

And seeing in catalina.out:
Apr 16, 2015 1:05:12 a.m. org.apache.catalina.users.MemoryUserDatabase open
WARNING: Exception configuring digester to permit java encoding names in XML files. Only IANA encoding names will be supported.
org.xml.sax.SAXNotSupportedException: http://apache.org/xml/features/allow-java-encodings
   at gnu.xml.stream.SAXParserFactory.setFeature(libgcj.so.10)
   at org.apache.tomcat.util.digester.Digester.setFeature(Digester.java:556)
   at org.apache.catalina.users.MemoryUserDatabase.open(MemoryUserDatabase.java:391)
   at org.apache.catalina.users.MemoryUserDatabaseFactory.getObjectInstance(MemoryUserDatabaseFactory.java:103)
   at org.apache.naming.factory.ResourceFactory.getObjectInstance(ResourceFactory.java:140)
   at javax.naming.spi.NamingManager.getObjectInstance(libgcj.so.10)
   at org.apache.naming.NamingContext.lookup(NamingContext.java:793)
   at org.apache.naming.NamingContext.lookup(NamingContext.java:140)
   at org.apache.naming.NamingContextBindingsEnumeration.nextElementInternal(NamingContextBindingsEnumeration.java:113)
   at org.apache.naming.NamingContextBindingsEnumeration.next(NamingContextBindingsEnumeration.java:71)
   at org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans(GlobalResourcesLifecycleListener.java:137)
   at org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans(GlobalResourcesLifecycleListener.java:109)
   at org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.lifecycleEvent(GlobalResourcesLifecycleListener.java:81)
   at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142)
   at org.apache.catalina.core.StandardServer.start(StandardServer.java:703)
   at org.apache.catalina.startup.Catalina.start(Catalina.java:593)
   at java.lang.reflect.Method.invoke(libgcj.so.10)
   at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
   at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)
Apr 16, 2015 1:05:12 a.m. org.apache.catalina.core.StandardService start
INFO: Starting service Catalina
Apr 16, 2015 1:05:12 a.m. org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.24
Apr 16, 2015 1:05:12 a.m. org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory ca
Apr 16, 2015 1:05:13 a.m. org.apache.catalina.startup.TldConfig lifecycleEvent
SEVERE: Error processing TLD files for context path /ca
java.lang.IllegalArgumentException: URI "file:./" is not hierarchical
   at java.io.File.<init>(libgcj.so.10)
   at org.apache.catalina.startup.TldConfig.getJarPaths(TldConfig.java:636)
   at org.apache.catalina.startup.TldConfig.execute(TldConfig.java:305)
   at org.apache.catalina.startup.TldConfig.lifecycleEvent(TldConfig.java:688)
   at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142)
   at org.apache.catalina.core.StandardContext.start(StandardContext.java:4616)
   at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
   at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)

The exception you have provided do not seem to be related to this bugzilla.
What led you to pointing it here?

This is cleanly packaging issue.

The SAXNotSupportedException only happens when IPA was running with java-1.5.0-gcj, which was automatically pulled by one of IPA's dependencies. After switching to java-1.8.0-openjdk the exception no longer happens.

In Comment #10 you suggested about adding java-gcj-compat to the list of provides. Is that still the plan?

(In reply to Endi Sukma Dewata from comment #22)
> The SAXNotSupportedException only happens when IPA was running with
> java-1.5.0-gcj, which was automatically pulled by one of IPA's dependencies.
> After switching to java-1.8.0-openjdk the exception no longer happens.
> 
> In Comment #10 you suggested about adding java-gcj-compat to the list of
> provides. Is that still the plan?

Thanx for explanation. Then please, remove that requires, and correct "requires: java"

So you will be aligned with system jdk.

> 
> Thanx for explanation. Then please, remove that requires, and correct
> "requires: java"
> 

This is valid for all dependences. I already wrote to all maintainers, and got nearly no reply.

I bet, adding gcj-comapct-whatever will bring us all to troubles later.

Let me clarify, our own packages do not have direct dependency on java-gcj-compat, and in fact they cannot run with Java 1.5. They do require Java 1.6 or later, and we already have this dependency:

 Requires: java >= 1:1.6.0

I'm not sure if changing it to this will solve the problem:

 Requires: java

The problem is the lower level dependencies still do require java-gcj-compat, so when we install our packages they will pull both gcj 1.5 and openjdk 1.8. Because of the priority, alternatives will pick gcj 1.5 over openjdk 1.8, and the installation fails because it cannot not run with Java 1.5.

If we use alternatives to switch manually to openjdk 1.8 before installation, the installation will work just fine, but that also means the lower level dependencies that do require java-gcj-compat actually work just fine with openjdk 1.8.

So I think the possible solutions are:
1. Add java-gcj-compat into openjdk's provides. As mentioned above, so far they work just fine. If someone really needs gcj they can always switch back using alternatives.
2. Change the alternatives' priority such that openjdk 1.8 is higher than gcj.
3. Remove openjdk 1.8 if it's considered "too new" to be usable. The openjdk 1.6 or 1.7 already have higher priority than gcj.
4. Add "Conflicts: java >= 1:1.8.0" into our packages.
5. Require users to switch to openjdk manually.
6. Automatically change the alternatives to use openjdk during installation and runtime.
7. Hard-code our packages to use certain openjdk version.

I don't think options #4-7 are good practices in general.

Thanks Endi. I don't think 'Requires: java' will work either. 

'Requires: java-openjdk' that I mentioned in comment #25 could work, but then it will be limited to OpenJDK. 

I think option #2 (making OpenJDK8 priority higher than GCJ but lower than OpenJDK6) is the best approach here.

Jiri, are you ok with the above?

Looking to the specfiles:
gcj:
%define origin          gcj%{gccsuffix}
%define priority        1500

jdk8
# priority must be 6 digits in total
%global priority        0000%{updatever}

Now, looking into https://bugzilla.redhat.com/show_bug.cgi?id=1189084
all *openj*jdks in rhel 6 are enforcing priority of 6.

So adding force to gcj to 4
keeping jdk 6 and 7 on 
1{6,7}0XXX
and putting jdk8 to anything on 5 digits will do the job.

If acks appear here, I will push the changes to both jdk8 and gcj (the restriction)

Endi, thanx for bringing up solution with priorities. I would not thought it can help.

If GCJ is fixed, can we just not make JDK 1501 and leave gcj alone? The gcj rpm has been touched in years and I would prefer not to change it unless it is really needed.

As you wish. Setting jdk8 to 1800 will do the job and will be more aligned with other jdks.  My intention to touch gcj was to add the priority check so no one will accidentally rise length of that "number". If you are sure gj package wil not be touched, ten then the check is definitely not necessary  and modification in jdk8 will be more then enough.

One question - in 6.7/7.2 Are you going to keep the priorities of jdk8 below jdks 6 and 7?
We lready provides java in 6.6/7.1. Or the priorities will get to normal once we provide also javac?

Yeah unless there is a very serious issue in GCJ, I don't see us updating it.

1800 will not break other 1{6,7}0XXX priorities, right?

re: 6.7/7.2 -- it is late for 6.7, we can propose it for 6.8/7.2 though; I am fine with raising priority to higher than OpenJDK6 and 7.

the change was pushed and build is being build
http://pkgs.devel.redhat.com/cgit/rpms/java-1.8.0-openjdk/commit/?h=rhel-6.7&id=f07e421351229ab7ca6b89028d2d65ba333e2ed2
http://brewweb.devel.redhat.com/brew/taskinfo?taskID=9070148

the change was pushed also to rhel 7.2 but no build done (yet, unrelated failure)

> the change was pushed also to rhel 7.2 but no build done (yet, unrelated
> failure)

https://bugzilla.redhat.com/show_bug.cgi?id=1212540
http://download.devel.redhat.com/brewroot/work/tasks/94/9070094/build.log

This bug is not fixed, however workaround is provided to remove all bad caused by this.  The true fix will probably never go to rhel6 . I will move this bug to modified, but not sure if it is about to be ever closed.

Hello.

Myself and Mikolaj had made some research, and this is not possible to fix for rhel6

We are not able to get rid of dual gcj + openjdk + multiple versions of any java  from rhel.

Even worse. openjdk do not provide same libraries, as are expected when one is requiring gcj compact, so openjdk simply can not provide them.

Luckily, this issue is not persisting in rhel7.