blackdown-jdk offers a superset of what is available in blackdown-jre, but if jre is already installed at the time that jdk gets installed, java-config is not used to change the default VM and switch the java env variables over to jdk. A side-effect of this is after installing jdk, tools such as 'jar' are not automatically placed in $PATH. When blackdown-jdk gets installed because it is a dependency of a package that requires 'jar', in effect it does not meet that dependency until the user manually runs java-config. Perhaps the blackdown-jdk ebuild should run java-config even if a default VM is set, if the current VM is blackdown-jre.
It's sadly a bit trickier than that. If a user installs blackdown-jre, then installs blackdown-jdk, it may make sense to say that the blackdown-jdk will take precedence. But when the user then unmerges blackdown-jdk, the system should revert to blackdown-jre, which is impossible if the env files are actually overwritten. Next up: The user installs sun-jdk, then installs blackdown-jdk, should the blackdown-jdk then take precedence as the system-default from the moment it was installed ? In general, we have opted for _NOT_ modifying a users enviroment and settings unless he explicitly asks for it. The only exception is setting a default VM (a JRE or a JDK) if you install one and none exist beforehand. Please add your insights; I'll keep pondering this until we get to a solution that's good.
In my opinion a merge should be more troublefree than an unmerge. It makes sense to me for a user to have to run 'java-config' to change to a different VM once she has removed a package. But in my example where I have installed blackdown-jdk and afterwards 'jar' is not in my path, this is confusing. The ebuild could at least suggest to me to run java-config after installing the package, to set things straight. I didn't discover I needed to do this until after I started looking around in /etc/env.d/20java. As for env files being overwritten, I see there would be a problem if the user modifies /etc/env.d/20java. This file could have stronger language suggesting the user customize the files in /etc/env.d/java and then rerun java-config. Assuming the user has customized the blackdown-jre file, and assuming when blackdown-jdk is installed the env is switched to it, the user's changes are still intact and he can switch back to blackdown-jre with no harm done. I'm suggesting auto-switching the VM only on a blackdown jre->jdk upgrade, and not when installing any jdk. But really the problem I'm pointing out is 'jar' not being added to the path, making my merge fail. There could be other ways of addressing that problem.
Have blackdown-jre merged and working wanted to use/try openoffice which requires blackdown-jdk. So tried to emerge after openoffice failed the installation and setting of the vm failed as it was not able to find the jdk after the merge. java-config will not find the jdk. --list-available-vms only lists the jre. yet I can browse the directories in /opt/blackdown-jdk-1.3.1 and see the files? Essentially the emerge of the jdk attempted to -set-system-vm=blackdown-jdk and failed.the error was not found.
Not sure if anybody's still looking at this, but... How about splitting the Java env files into two: 20*-jre and 21*-jdk. Could then modify java-config to set either or both to none, still giving the user full configuration. Emerging or unmerging a jdk/jre could then call java-config to set defaults in the following manner for a jre: 1. If unmerging a jre, 1.a. If the current jre is none or the current jre is not the jre that has been unmerged, do nothing. 1.b. Else if there is a jdk configured or no other jres are installed, set the current jre to none. 1.c. Else set the current jre to the next "default" jre. 2. Else if merging a jre, 2.a. If the current jre is not none, do nothing. 2.b. Else set the current jre to the jre that has been emerged. and similarly for a jdk: 1. If unmerging a jdk, 1.a. If the current jdk is none or the current jdk is not the jdk that has been unmerged, do nothing. 1.b. Else if no other jdks are installed, set the current jdk to none. 1.c. Else set the current jdk to the next "default" jdk. 2. Else if merging a jdk, 2.a. If the current jdk is not none, do nothing. 2.b. Else set the current jdk to the jdk that has been emerged. With this method (or a variant thereof), java should always be available unless the user has explicitly set either the jre or jdk to none. What constitutes the "default" jre/jdk could be controversial, but is not too important as the user must have installed the software first anyway. I would suggest that it be easiest to just go alphabetically.
It's been quite some time since anyone looked at this. I think it is worth another look. I am suffering the same quandry because I merged blackdown-jdk, then blackdown-jre, then tried to merge openoffice. No luck because it can't find javac, which is in /opt/blackdown-jdk-1.4.x whereas it tries to find it in /opt/blackdown-jre-1.4.x. If I take out the java USE flag from /etc/make.conf, I believe it will build just fine, but I see javac in /opt/blackdown-jdk-1.4.1/bin and I want to build openoffice with java support, dagnabbit.
P.S. I know I can java-config --set-system-vm=blackdown-1.4.1 to get openoffice to find javac ... but I'm presenting the quandry from the perspective of joe user.
I think we'll adopt a middle ground here for now: 1) If you merge a JRE and a JDK is already present, we'll keep the JDK as the default system VM. 2) If you merge a JDK, it will be set as the default system VM regardless 3) If you unmerge either a JDK or a JRE, a big fat warning will tell you to run java-config manually to select your preferred VM.
Fixed this for blackdown-jre, sun-jre-bin, ibm-jre-bin and compaq-jre.
I've added the suggestions to the upcoming Java Ebuild Development Guide, so I consider this matter closed, or at least superseded by the Guide.
