sun-jdk-1.5.0 is masked for these reasons: # <strider@gentoo.org> (10 Jan 2004) # Masking since its a beta release. # <axxo@gentoo.org> # If you use 1.5 you will get sandbox violations on /dev/random # please don't file any more bugs on that issue # Also you'll have to remerge everything you merge with 1.5 if # you want to downgrade to 1.4 >=dev-java/sun-jdk-1.4.99 >=dev-java/java-sdk-docs-1.4.99 It is no longer in beta, and I believe the sandbox violations have been fixed by recent portage versions. Reproducible: Always Steps to Reproduce: 1. 2. 3.
The message now reads # <axxo@gentoo.org> # If you use 1.5 you will get sandbox violations on /dev/random # please don't file any more bugs on that issue # # 1.5 defaults too -target 1.5 making downgrading to a 1.4(/1.3) # impossible, see bug 65939 for more information/discussion >=dev-java/sun-jdk-1.4.99 >=dev-java/java-sdk-docs-1.4.99
I think the sandbox violations were fixed. Bug 53790 has been marked FIXED. Additionally, I don't think the -source/-target thing is a reason to mask the ebuild. It's in a different SLOT, so people will have their old JDK's still installed. I believe java-based ebuilds use whichever java is on the PATH, which is set by java-config. Unless sun-jdk-1.5.0 is the only VM on the system, the ebuild does not change the default system VM, so compatibility will not be an issue until users set it to be their default VM. I think the sun-jdk-1.5.0 ebuild could have a warning in its post-install about backwards compatibility and downgrading, but I don't think users should be prevented from installing it by leaving it masked. Additionally, I believe sun-jdk-1.4.0 broke compatibility in this way by changing the default -source and -target to 1.3. sun-jdk-1.4.0 was not masked like sun-jdk-1.5.0 is, however.
the ebuild does set 1.5 as the default system vm and the access violation are only 'fixed' in portage .51 not stable .50 And i do think the downgrading is a problem
1. Backwards compatibility How will you fix the downgrading problem? Will all future versions of sun-jdk be masked? If it really bothers you, you could install a second VM into java-config, called sun-jdk-1.5.0-compatibilitymode or something, which used a different "javac" which was a shell script that ran javac -source 1.3 -target 1.3. 2. Default VM The line in the ebuild that sets the default VM is: # Set as default VM if none exists java_pkg_postinst It says "if none exists." This contradicts what you said in comment 3. If the ebuild sets it as the default VM no matter what, this should be changed. It should only set it if no other VM is installed. 3. Sandbox problem I think that instead of masking the ebuild, sun-jdk-1.5.0 should RDEPEND on >=portage-2.0.51_rc1 or something similar. I think this should be configurable by a USE flag "nosandboxfix" or something.
The comment is wrong. Lets wait and see what the other java dev have to say about this.
I strongly agree with axxo, we should wait till the the issue of downgrading is solved, not everyone is willing to keep the 1.5 as default, but only wants to test it. Another problem is that if we unmask it then the users will install it, and if there are problems we need to support it. this we aren't ready for as we know there are to many breakages, and as long as we aren't ready with the basic stuff we shouldn't unmask it. axxo++ greetings SeJo@gentoo.org
Could either axxo or Jochen address my three issues in comment 4 separately? I think a sun-jdk ebuild shouldn't set itself to be default unless no other VM is installed, in all circumstances (not just 1.5.0). Don't you think my sun-jdk-compatibilitymode idea would solve the problem, for the probably small number of people who have problems and need to downgrade? The RDEPEND on portage would fix the sandbox problem. Please address these issues.
The vm's need to set themself as default vm at the moment because: When you have for example 1.3 installed, and an ebuild requires jdk-1.4 we can DEPEND on it, and it'll get merged and set to default, and the package will continue to merge Yes this will break if you allready had a 1.4 installed and set a 1.3 as default, and we should find a solution for it. But if you do that, you general know what you are doeing. This way it will work 'out off the box' for everyone that might not know alot about java and just install it as a dep for there favorite application
>1. Backwards compatibility >How will you fix the downgrading problem? Will all future versions of sun-jdk >be masked? > >If it really bothers you, you could install a second VM into java-config, >called sun-jdk-1.5.0-compatibilitymode or something, which used a different >"javac" which was a shell script that ran javac -source 1.3 -target 1.3. You are asking us to create a system to implement java 1.5 who isn't compatible, to make it compatible with the applocations. as axxo said ebuilds should by definition be out off the box working. We have a complete tree off java applications that won't work out off the box with sun jdk 1.5 address that please >2. Default VM >The line in the ebuild that sets the default VM is: > > # Set as default VM if none exists > java_pkg_postinst > >It says "if none exists." This contradicts what you said in comment 3. If the >ebuild sets it as the default VM no matter what, this should be changed. It >should only set it if no other VM is installed. Again, you are asking us to change current tested applications to suit an incompatible version. We are aware that more release will be the same, and we are aware that we will have to change them. However we cannot create for each java application (small or big) our own version untill upstream is ready to switch. I repeat what axxo said, users might install JDK 1.5 unknowingly (if it's in portage as unstable/stable) and have more problems with their current working applications. >3. Sandbox problem >I think that instead of masking the ebuild, sun-jdk-1.5.0 should RDEPEND on >>=portage-2.0.51_rc1 or something similar. I think this should be configurable >by a USE flag "nosandboxfix" or something. There is a reason why there is a sandbox. greetings
>>1. Backwards compatibility >>How will you fix the downgrading problem? Will all future versions of sun-jdk >>be masked? >> >>If it really bothers you, you could install a second VM into java-config, >>called sun-jdk-1.5.0-compatibilitymode or something, which used a different >>"javac" which was a shell script that ran javac -source 1.3 -target 1.3. >You are asking us to create a system to implement java 1.5 who isn't >compatible, to make it compatible with the applocations. Yes. >as axxo said ebuilds should by definition be out off the box working. We have >a complete tree off java applications that won't work out off the box with >sun jdk 1.5 >address that please They will work out of the box, if jdk15-compatibilitymode is set to default JVM by sun-jdk ebuild. >>2. Default VM >>The line in the ebuild that sets the default VM is: >> >> # Set as default VM if none exists >> java_pkg_postinst >> >>It says "if none exists." This contradicts what you said in comment 3. If the >>ebuild sets it as the default VM no matter what, this should be changed. It >>should only set it if no other VM is installed. >Again, you are asking us to change current tested applications to suit an >incompatible version. We are aware that more release will be the same, and we >are aware that we will have to change them. However we cannot create for each >java application (small or big) our own version untill upstream is ready to >switch. I think you misunderstood me, I said the jdk1.5.0 ebuild could be changed, to not set itself as the default VM. I'm not saying any other ebuilds should be changed. >>3. Sandbox problem >>I think that instead of masking the ebuild, sun-jdk-1.5.0 should RDEPEND on >>>=portage-2.0.51_rc1 or something similar. I think this should be configurable >>by a USE flag "nosandboxfix" or something. > There is a reason why there is a sandbox. The bug has been fixed in 2.0.51, why couldn't jdk1.5.0 depend on portage 2.0.51?
OK folks, now that we are on portage 2.0.51, what is the status of this thing?
As far as the compatibilty problem goes, what about this idea: Allow the user to set a target jdk version somehow, maybe in make.conf or something. This version would override the -target argument to the JDK, so that regardless of the active jdk version, you'd have compatibility to that version. If the user wanted to emerge a package that requires a 1.5 target, portage could just go ahead and build that pacakge targeting 1.5 despite the user setting, since really if it depends on 1.5 then backwards compatibility doesn't matter anyway. Same could apply to 1.3-1.4 compatibility... if the package requires 1.4 then the user can't expect it to run on 1.3 anyway. This way the user can take advantage of bugfixes and jvm enhancements present in the newer jvm without losing backwards compatibility, and can use newer jdk features for software they're developing, all without monkeying around with java-config all the time... heck, even a novice could figure it out. If this isn't possible or is not reasonable, hopefully it will at least give someone a brilliant idea on how to get jdk 1.5.0 unmasked, because after all, it's decemeber and still no jdk 5!
Um, looks like my idea is more or less how things ended up being carried out according to #69970, #74824, etc etc. So I guess you can ignore my rant above ;)
Some Internet banking sites have updated to depend on sun jave 5.0 and requires jave vm 5.0 to access the site. There was a lengthy discussion in the Singapore LUG recently. I encountered the same problem too. I had to access an Internet banking site. When I tried logging in with my gentoo machine having sun-jdk-1.4.2 installed using firefox-1.0-r3, I can't even get pass the log-in screen. Then I switch to a Windows machines with sun-jre-1.5.0 install and open the same site using firefox-1.0 and I encountered no problems at all. As you can see, upgrading to sun-jdk-1.5.x is not an option but a necessity for some desktop users. I hope the sun-jdk-1.5.0 will be unmasked ASAP.
you can install it, and it will work fine, just don't leave it as the system-vm then things will break we are working on it
Okay what do you mean just don't leave it as the system vm, says the clueless.......
Suggest package is moved to ~ immediately.
Any progress? I'm facing a problem like the one described in comment #14.
In order to let 1.5 loose in the tree, we need to 1) Make certain all packages compile with a 1.5 JDK. 2) Add support for merge-time switching of VMs. 3) Add support for merge-time build.xml rewriting.
Seems to me that there needs to be formal support for _dialects_ with Gentoo's Java support. Right now source can be targeted at 1.0, 1.1, 1.3, 1.4, 1.5...Gentoo happens to currently target 1.4. This is quite an arbitrary decision, taking Java history into account. Why not 1.1, or 1.3? The answer is that 1.4 was probably the "best" available release at the time that the java tools were released. Sun hasn't done anyone any favors -- they've released a new version of the language (generics, keywords, etc) and provided incompatible defaults between releases. That's reality, so we just have to deal with it. Any given Java package has a dialect (1.3, 1.4, 1.5) associated with its compilation. We can often (but not always) compile source with a later dialect. Compilation produces output that is target-specific; class files compiled with a given target cannot run on older vms, and those vms automatically reject the newer bytecodes. We'd like to disturb the existing code base as little as possible; it currently likes being a 1.4.x source and target. We also have the issue of default behavior of the command-line tools. If I type javac at the command line, what capabilities should I receive? The latest and greatest, or something that is compatible with a back-revision, like 1.4? java-config can currently switch between versions of the vm. I think we also need a java-dialect option or variable (java-config -d [dialect]). Execution of this command yields a java environment compatible with the given dialect using the currently configured release. java-config -d 1.4, if executed when the current system vm is a 1.5-compatible one, would cause javac to automatically include -source=1.4 and -target=1.4 as options. java-config -d 1.5 would fail if the currently configured environment is at the 1.4 level. Ascending dialects emit forward- but not backward-compatible classes. It would be used to have java packages be compiled more than once and be available, side-by-side, in multiple revisions. We might have /usr/share/java/dialect_1.5/ant-core, and /usr/share/java/dialect_1.4/ant-core. Appropriate runtime selections for classpaths can be performed based on the current dialect. It would be interesting to have build process automatically attempt _several_ builds, in descending dialect order, on packages. A package that successfully compiles at higher dialects without modification would get this behavior by default; packages that need patching or other work would then be compiled with a lower dialect automatically. If lower dialect versions are generated automatically packages that depend on others that are compilable at higher dialects will still compile, as they can compile against the lower-dialect version of the dependency target. Obviously this is a pretty big can of worms, but I think it's important to solve the side-by-side versioning problem. The 1.5 upgrade isn't the first time Sun has modified the source and target compatibilities and it certainly won't be the last. A clean Gentoo solution for tracking Java evolution is out there somewhere...
How is this any different from the gcc situation? The gcc c++ ABI changed from 3.3 to 3.4 (and presumably to 4.0. judging by the number of 4.0 compatibility patches in portage). If you compile your kdelibs with gcc-3.4 and then decide to downgrade back to gcc-3.3 -- you are mostly out of luck. I don't understand why gentoo java support should provide users with any more hand-holding than gentoo gcc...
Any chance this will be unmasked soon?
Why is >=dev-java/sun-jre-bin-1.4.99 masked in package.mask? It does not include javac, so neither of the stated reasons are relevant: # lotsa things in the tree don't compile with 1.5 yet # 1.5 defaults too -target 1.5 making downgrading to a 1.4(/1.3) # impossible, see bug 65937 for more information/discussion (this package is useful for getting a java plugin that works with internet banking sites while avoiding the compiler compatibility problems)
i have downgraded my java version from 1.5 to 1.4 (forced by package.mask) and i got this error http://forums.gentoo.org/viewtopic.php?p=2385790 how can i solve it?
equery depends jdk equery depends jre and emerge the union of the two lists. What you must do is rebuild all packages that contain Java code, this is my suggestion on how to find them.
If I unmasked sun-jdk 1.5, installed it. remerged net-beans, reset my jvm by java-config back to sun-jdk-1.4 for system vm and set my jvm to sun-jdk 1.5 for one user. after this would I have the following? 1) all packages using java emerged at this point compiled to a 1.4 target and source, 2) Net-beans running with the 1.5 jdk for the specified user. 3) all other programs running using the 1.4 jdk. Or would something very different be the result. The reason that I want the 1.5 jdk is I would really, really like to have the polymorphic Collection, List, Set, Map, ArrayList etc. In the mean time I am looking for a different way to solve my problem, but that would have made things much easier.
Any status on the aforementioned items required before 1.5 is released to the tree?, plus some questions. | 1) Make certain all packages compile with a 1.5 JDK. Compile using 1.5, or -target -source 1.5? | 2) Add support for merge-time switching of VMs. Again, merge-time switching of VMs or just targets? | 3) Add support for merge-time build.xml rewriting. I'm assuming this would be for rewriting targets in build.xml. I'm not sure I see the logic behind this. For example, if I'm the author of an application, and I've set my build.xml to target/source="1.5", perhaps thats because my source contains things such as generics, and won't compile in 1.4. In that instance, just like any other package in portage, the dep should reflect that against the JDK. Otherwise, if the target is lower, who cares? It will still run in a newer JVM. Even if something just seems to compile and "work" with an adjusted lower target there might be logic behind why the author has the target set at 1.4 (such as leaks, race conditions, etc), I'm not sure we should be second guessing that.
3) I guess build.xml that explicitely states source or target versions probably knows what it is doing. The trouble is that there are many build.xml files around where no version whatsoever is stated, and the defaults in some configurations simply won't do. Those situations could be resolved by rewriting the build.xml or any of the other approaches suggested in bug 86903, and no harm would be done.
Whats the status on this, any chance on it getting unmasked anytime soon? (People using only 1.5 and who don't want to downgrade don't have to worry, or?)
If you use http://gentooexperimental.org/svn/java/axxo-overlay/ Everything should work with 1.5 but be very carefull if you use that, since it has some huge changes on how java is handled (we are working on some documentation for it) if you are brave and try it please email me with _any_ feedback (axxo@gentoo.org)
How do I get it from svn ? Do I also need anything else, like http://gentooexperimental.org/svn/java/java-config-ng/ ? Any update steps I should take, apart from world update ?
from package.mask # lotsa things in the tree don't compile with 1.5 yet Can you give one example of a java program that *does not* compile with 1.5, please?
xerces and xalan will not compile with 1.5 due to some XML API changes. From what I'm told, it has to do with DOM Level 3 being used, where xerces and xalan want Level 2. Also, axxo has some written up some documentation: https://gentooexperimental.org/svn/java/axxo-overlay/README/docs/java-user.html https://gentooexperimental.org/svn/java/axxo-overlay/README/docs/java-devel.xml
Ah thanks. That's not what I would call a compilation issue, but ok in the end it doesn't 'compile', so now I see what the message means.
xalan xerces tiplea jboox xindine fop xmlc crimson batik dom4j jaxen adaptx castor iso-relax jessie gnu-jaxp openjms jext j2ssh nice octopus for starters do not compile with 1.5 (and that is not counting the ones that just need -source -target fixes)
> Ascending dialects emit forward- but not backward-compatible classes. It > would > be used to have java packages be compiled more than once and be available, > side-by-side, in multiple revisions. We might have > /usr/share/java/dialect_1.5/ant-core, and > /usr/share/java/dialect_1.4/ant-core. > Appropriate runtime selections for classpaths can be performed based on the > current dialect. Hmm, I'm not _that_ sure about what you say. You say that you can select -target... but it seems you forget that -source and -target _can_ be misaligned. In fact, generics are implemented only through an extended syntax (and possibly some additional records, which IIRC can be ignored by older VM). The same was true for assertions. I've seen people successfully compiling for M$ JVM by simply adding -target, without any other changes. I've not actually tested this, but I'm quite confident that you can use, only the two configs "-source 1.5 -target 1.4" and "-source 1.4 -target 1.4". Indeed, when you use -target 1.4 you only change a field in the .class, so you might still have problems for missing identifiers. But hey, on packages which compile with 1.4 you don't have this problem (the theoretical edge cases of a method becoming static, or such, would break binary compatibility for existing 1.4 apps, so Sun won't do it). === Also, using a java wrapper makes much more sense than rewriting all build.xml... xml is not good for sed usage. Or you can patch "ant" instead (actually I think it should allow selecting the Java compiler on a global basis, even through cmd line, don't remember exactly through). Sorry for the lenghty comment and not having precise ideas, it's a while I don't hack in Java...
No, at least Jext, xalan and xerces _do_ work with jdk 1.5. I suppose also everything from apache foundation is sufficiently supported to have been updated... Could you please check again? Sorry, a correction: Jext _does_ compile with Java 5.0, a special release (5.0) was done for that purpose. I know that as a former contributor of Jext (though I did not partecipate to the preparation of that release). Release available on: http://sourceforge.net/projects/jext (the project is _a bit_ dead). Also, I believe that other projects have also updated their code.... for instance, this message from xalan ML reports successful update to compiling under JDK 1.5 (and it's a mail from 2004 about xalan 2.6.0, and we are at 2.7.0!!): http://marc.theaimsgroup.com/?l=xalan-dev&m=107584585728182&w=2 Or even http://xml.apache.org/xalan-j/downloads.html. As a note: it currently seems you are a minor version behind on both Xalan and Xerces (they're both at 2.7.x, and it doesn't seem a "odd unstable" version). And all the xalan and xerces websites talk about DOM level 3. So, please, quote a mail which says "yes, we're the developer of this package, and we can't make it work under JDK 1.5". If on Gentoo you can't compile it with 1.5, but other people can, then I'd start supposing JDK 1.5 is not the problem, but it lays somewhere else.
-source 1.5 -target 1.4 is not allowed.
I would like to point out that we now have a Java 1.5 FAQ: http://www.gentoo.org/proj/en/java/tiger-faq.xml This is a work in progress, and will be updated as we receive feedback. I recommend anyone watching this bug to try the overlay discussed in the FAQ because it addresses all the issues related to using a 1.5 JDK to emerge your system.
http://issues.apache.org/bugzilla/show_bug.cgi?id=39183 -> Some maybe the following would help for all the broken ant scripts? <project> <presetdef name="javac"> <javac source="${ebuild.java.version}"/> </preset> <import file="${ebuild.ant.filename}"/> </project> Don't know if that syntax is entirely correct... Just an idea.
(In reply to comment #40) > -> Some maybe the following would help for all the broken ant scripts? In bug #86903 comment #12 I already suggested a build file to use this preset based approach. I guess that bug is the place to discuss common build file issues. I talked about this on irc, and at that time the opinion of the java deps was that the specification in the ebuild should take precedence over any version specification included in the ant build file. This is not possible using presets. Personally, I believe that if a dev specifies some version dependence, this setting should be honoured or the error be reported upstream. But I'm not a Gentoo dev, so their opinion counts.
The new Java system to support 1.5 has been unmasked. Marking fixed. See the upgrade guide: http://www.gentoo.org/proj/en/java/java-upgrade.xml
