src.zip in sun-jdk1.4.0 (src.jar in jdk 1.3 i think) gets installed into /opt/sun-jdk-1.4.0/share instead of /opt/sun-jdk-1.4.0/. This breaks some programs because the location of that file has changed from the norm. I've only used Netbeans for now so I don't know how many more programs are broken from this. The easy work around is of course mount src.zip in Netbeans. But this is hard to figure out because Netbeans gives you a criptic message (e.g. when opening a form). Normally, src.zip is mounted automatically in Netbeans the first time you start it up. Can the Netbeans ebuild be changed to point it to this new location? I don't think so because I the Netbeans filesystem settings are stored in the user's home directory and generated on demand for each user when the program first starts up. Why is the location of src.zip and the demo directory moved to share anyway? It's only 1 file and 1 directory. If is should be moved, should it be to /usr/share, or /opt/share since its a binary package (even though it is open source-you could download the sources and compile if you wanted to)? Maybe it's enough just to alert the user when installing sun-jdk or netbeans that the location is changed and they need to configure their programs appropriately.
ok its only javax.swing.JComponent that doesnt work all the time. JPanel does work. Ill post this bug on netbeans website.
The reason it is moved into the share directory is that it is really a share file. However, if this cannot be resolved on the NetBeans side, we will just have to move it back. In general we should probably not touch the directory layout of /opt/<anyjava>/, no matter how ugly it is.. Keep me appraised.
It turns out the problem I was having is a confimed and fixed bug on Netbean's website. You cannot create a new BeanForm with javax.swing.JComponent as the superclass because it is an abstract class, even though it is an option in the dropdown box. So this is not a gentoo bug. I also checked if src.zip was automounted with Netbeans on Windows. It's not. In fact, the documentation says it is optional when redistibuting the sdk. Unless there is a really good reason not to have the share directory and there is no other complaints that other programs don't work, this can be closed as INVALID.
Ok. Thanks for excellent feedback.
Eclipse seems to look for src.zip in the jdk directory. I'm not sure how many other programs look for it there as well. Can't we compromise and create a symbolic link? /opt/sun-jdk-1.4.2.04/src.zip --> share/src.zip http://forums.gentoo.org/viewtopic.php?t=157312
It looks like I'm not allowed to re-open this bug.
+1 vote for keeping directory layout of sun, even if it's ugly
*** Bug 98433 has been marked as a duplicate of this bug. ***
We should follow what Sun documents on their website: http://java.sun.com/j2se/1.5.0/docs/tooldocs/linux/jdkfiles.html Reopening to fix this.
This also affects ibm-jdk-bin so we should check all our jdks for this.
*** Bug 94141 has been marked as a duplicate of this bug. ***
betelgeuse: so would you prefer moving it, and linking from share/ or just adding link from / to share/ ?
(In reply to comment #12) > betelgeuse: so would you prefer moving it, and linking from share/ or just > adding link from / to share/ ? > I would say to link it if it's just a revision bump as the directory in /opt will stay the same. If it's a version bump, just move as the director in /opt will change any way so you need to update the location any way.
(In reply to comment #13) > > I would say to link it if it's just a revision bump as the directory in /opt > will stay the same. If it's a version bump, just move as the director in /opt > will change any way so you need to update the location any way. > Yeah and just slap some elogs there so it will not go unnoticed when the old location goes away.
sun-jdk fixed. Now just all the rest of the JDKS.
jrockit-jdk-bin layout is not affected by this bug.
IBM is fixed, I think only blackdown's left
Fixed blackdown in -r16, let's get the oldest opened java bug closed, yay.
