commons-pool doesn't compile for java 1.5

Message

kernelcowboy · Post by **kernelcowboy** » Thu Jan 26, 2006 2:50 am

is this news to anyone? bugzilla says "Zarro Boogs found. " it's the enum keyword problem. (incidentally it doesn't mention this in the tomcat bugs either, and this is a dependancy.)

i dont know too much about dependancies and bugs in the gentoo world. but, i do in the java word.

is there any way around this until it's fixed? like may be installing as a binary?

thanks

alistair · Post by **alistair** » Thu Jan 26, 2006 8:59 am

switch your system-jm to a java1.4 version. I believe, this was true late last year at least, that java1.5 has not been marked stable for the simple reason that a lot of the java packages in portage do not support compulation by java1.5, including some important build tools (maybe ant, im not to sure). As you can imagine this is very important for a source based distro.

therefore if you want java1.5 just make sure you have 1.4 as well

kernelcowboy · Post by **kernelcowboy** » Thu Jan 26, 2006 7:23 pm

Thanks. Indeed emergeing with a 1.4 vm was the key.

However, why wouldn't there be a bug listed for the commons--pool ebuild? Should there be one stating 'Doesn't compile with 1.5 - enum.'

incidentally, it doesn't seem like a tough problem to fix in an open source system? are the maintainers just really back logged, or are the commons-pool dev's not able to rename enum and release their code? or, i'm i really in the dark here?

thanks

GJtje · Post by **GJtje** » Thu Jan 26, 2006 9:06 pm

Java5 is a major change, that's why. They wrote their code for 1.4 not 1.5.

alistair · Post by **alistair** » Fri Jan 27, 2006 2:41 am

kernelcowboy wrote:Thanks. Indeed emergeing with a 1.4 vm was the key.

However, why wouldn't there be a bug listed for the commons--pool ebuild? Should there be one stating 'Doesn't compile with 1.5 - enum.'

incidentally, it doesn't seem like a tough problem to fix in an open source system? are the maintainers just really back logged, or are the commons-pool dev's not able to rename enum and release their code? or, i'm i really in the dark here?

thanks

1. A bug was filed against the java1.5 releases. It would be to hard to (and annoying from a dev's perspective) bug report all the java packages.
2) The gentoo developers probably dont release their own patch because they dont have the time to make it + then maintain it within portage while upstream developers decide if they want to use it. (They could be planning a big rewrite after all).
3) As you why the upstream devs havent done that I sadly can't answer.

kernelcowboy · Post by **kernelcowboy** » Fri Jan 27, 2006 6:10 am

alistair wrote: 1. A bug was filed against the java1.5 releases. It would be to hard to (and annoying from a dev's perspective) bug report all the java packages.

I am, by no means, trying to cause an argument by sayin this ... But, isn't it the package that is failing to compile, not the virtual machine. And some packages may compile fine in java 1.5, should the vm be penalized for that? May be we should allow 1.5 to be your vm if you choose, and then mark some packages as stable and others not. and assign bugs to the ones that are not. in fact, isn't your java version similar to your ARCH, except you can more than one virtual ARCH. (I feel I'm slipping outside my confort knowledge zone, so I'll stop here.)

AllenJB · Post by **AllenJB** » Fri Jan 27, 2006 8:37 am

kernelcowboy wrote:
alistair wrote: 1. A bug was filed against the java1.5 releases. It would be to hard to (and annoying from a dev's perspective) bug report all the java packages.
I am, by no means, trying to cause an argument by sayin this ... But, isn't it the package that is failing to compile, not the virtual machine. And some packages may compile fine in java 1.5, should the vm be penalized for that? May be we should allow 1.5 to be your vm if you choose, and then mark some packages as stable and others not. and assign bugs to the ones that are not. in fact, isn't your java version similar to your ARCH, except you can more than one virtual ARCH. (I feel I'm slipping outside my confort knowledge zone, so I'll stop here.)

There's no way within portage to mark packages stable on unstable based upon what other software (versions) you have installed.

I could have misinterpreted what I've read to date, but as I understand it, the java herd are permanently solving the problem by adding a feature to the java ebuilds where the ebuild specifies what version of java to compile it in - so when java 1.6 comes out, this problem won't occur because java 1.5 packages will compile using 1.5.

Allen

alistair · Post by **alistair** » Fri Jan 27, 2006 10:42 am

kernelcowboy wrote:
alistair wrote: 1. A bug was filed against the java1.5 releases. It would be to hard to (and annoying from a dev's perspective) bug report all the java packages.
I am, by no means, trying to cause an argument by sayin this ... But, isn't it the package that is failing to compile, not the virtual machine. And some packages may compile fine in java 1.5, should the vm be penalized for that? May be we should allow 1.5 to be your vm if you choose, and then mark some packages as stable and others not. and assign bugs to the ones that are not. in fact, isn't your java version similar to your ARCH, except you can more than one virtual ARCH. (I feel I'm slipping outside my confort knowledge zone, so I'll stop here.)

Yes that is true and I agree with you, But on the other hand I understand why they have done it this way. Another messy way that "might" work is to (in each java package's ebuild) add -version 1.4 flags to the javac options.

alistair · Post by **alistair** » Fri Jan 27, 2006 10:47 am

emerge -pv sun-jdk

These are the packages that I would merge, in order:

Calculating dependencies
!!! All ebuilds that could satisfy "sun-jdk" have been masked.
!!! One of the following masked packages is required to complete your request:
- dev-java/sun-jdk-1.5.0.06-r2 (masked by: package.mask)
# <nichoj@gentoo.org>
# Many things in the tree don't compile with 1.5 yet.
# 1.5 defaults to -target 1.5, which makes downgrading to a 1.4/1.3
# impossible. See bug #69970 and bug 65937 for more information.
# http://www.gentoo.org/proj/en/java/tiger-faq.xml

- dev-java/sun-jdk-1.5.0.06-r1 (masked by: package.mask)
- dev-java/sun-jdk-1.4.2.10-r2 (masked by: -* keyword)
- dev-java/sun-jdk-1.5.0.06 (masked by: package.mask)
- dev-java/sun-jdk-1.3.1.17 (masked by: -* keyword)
- dev-java/sun-jdk-1.3.1.16 (masked by: -* keyword)
- dev-java/sun-jdk-1.2.2.017 (masked by: -* keyword)
- dev-java/sun-jdk-1.4.2.10-r1 (masked by: -* keyword)
- dev-java/sun-jdk-1.4.2.10 (masked by: -* keyword)

For more information, see MASKED PACKAGES section in the emerge man page or
refer to the Gentoo Handbook.

AllenJB · Post by **AllenJB** » Fri Jan 27, 2006 12:09 pm

alistair wrote:
kernelcowboy wrote:
alistair wrote: 1. A bug was filed against the java1.5 releases. It would be to hard to (and annoying from a dev's perspective) bug report all the java packages.
I am, by no means, trying to cause an argument by sayin this ... But, isn't it the package that is failing to compile, not the virtual machine. And some packages may compile fine in java 1.5, should the vm be penalized for that? May be we should allow 1.5 to be your vm if you choose, and then mark some packages as stable and others not. and assign bugs to the ones that are not. in fact, isn't your java version similar to your ARCH, except you can more than one virtual ARCH. (I feel I'm slipping outside my confort knowledge zone, so I'll stop here.)
Yes that is true and I agree with you, But on the other hand I understand why they have done it this way. Another messy way that "might" work is to (in each java package's ebuild) add -version 1.4 flags to the javac options.

As I understand it, that's essentially what they're doing. But they're doing it in a way (probably through use of an eclass) so that from now on every java package ebuild will specify what version of java it needs to be compiled with. Of course, this isn't an overnight change. The new method needs to be thoroughly tested before being deployed, and then every java ebuild needs to be updated with it's correct -version flags.

Allen