Bugzilla – Full Text Bug Listing
| Summary: | osgi.requiredJavaVersion should be Java 1.6 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Technology] EPP | Reporter: | Andrew Overholt <overholt> | ||||||
| Component: | linuxtools-package | Assignee: | Project Inbox <epp.packager-inbox> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | david_williams, mknauer, overholt, thatnitind | ||||||
| Version: | unspecified | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Andrew Overholt
Created attachment 171738 [details]
patch to move from J2SE-1.5 to JavaSE-1.6
That's an important one... as it can lead to a lot of frustration. Note that I also adjusted the other platforms - I know it doesn't make sense, but to keep things in sync. Patch applied to CVS HEAD. I'm not really arguing with you changing this ... but ... are you sure? Well, I guess arguing a little maybe :) Normally, when there are bundles that require 1.6, they simply don't run in 1.5, but users can still use some function in 1.5 ... and maybe that 1.5 function is all they want/need? So, are you saying that "there's basically no useful function" if 1.5 used? Or, am I misunderstanding? This caught my attention since as far as I know it is the first large scale requirement for 1.6 .... where it is literally required as the minimum. A bunch of our plugins require 1.6. I guess we can leave the base requirement at 1.5 and let people discover why things aren't running for themselves. Would that be a better plan? (In reply to comment #4) > A bunch of our plugins require 1.6. I guess we can leave the base requirement > at 1.5 and let people discover why things aren't running for themselves. Would > that be a better plan? I guess the devil is in the detail, and you'd know better than I where the right balance point is. And, you know you adopters. If they all can/want to use Java 1.6 and most important bundles need 1.6, then sounds like no harm. I guess 1.5 users can "roll their own" ... the EPP packages are meant to be easy to use, get started quick. Thanks for the discussion. The adopters that I know are fine with the 1.6 BREE and a lot of our users are using their distribution-provided OpenJDK which is 1.6. I don't want to rock the boat, though :) (In reply to comment #6) > The adopters that I know are fine with the 1.6 BREE and a lot of our users are > using their distribution-provided OpenJDK which is 1.6. I don't want to rock > the boat, though :) Well now you have me curious and I'm going to have to install your package real soon to see for myself :) But, doubt I'd have any direct insight in time for your decision. It has been kind of controversial, or, at least confusing and probably even inconsistent across Eclipse. The real hard core platform or osgi guys would say "always specify the lowest you possibly can" but others would say "what's the big deal ... no one uses those old vms". In this case, though, if I'm reading the patch right, it is not really a BREE that is being specified, just a "minimum required" vm in the eclipse.ini file, for a _product_. And .... products do need to be concerned about "ease of use" and "appropriate, easy to understand error messages and directions". So, I do not think it would be wrong to specify 1.6, if you think there's really no use of trying to use 1.5 with it. It is more important to specify appropriate minimum BREE's in bundles ... since that does start to effect or limit how others might adopt your bundles (if, for example, they did want to use 1.5 for some special reason with some subset of what you provide). But ... for a product ... you are welcome to be the first :) [And, I don't actually know all EPP packages ... some of them might already spec 1.6. SOA? Didn't meant to draw our your decision ... I think 1.6 is fine, from your description ... now ... where is my linux laptop. :) I think we need to reiterate... In the past we decided (I am sure this is somewhere documented...) that # all packages must be available on all EPP platforms # all packages share some common components (in the last years this was the UDC, now it is UDC+MPC) # all packages are running on a JVM >= 1.5 The Linux Tools package is per definition an exception from this because it really doesn't make sense to distribute a windows version. So there is already a kind of exception here. I do know the OSGi reasons, but I don't think they apply to a package (~product) where we should not rely on the fact that the runtime decides what components are being activated. It is the user who *expects* to have things running in a certain way and he/she doesn't want to find out that some things are silently ignored. BUT... (and this is the *but* why I want to reiterate) maybe I was too quick when I applied this patch. My suggestion now would be to change the eclipse.ini. To be honest I am not entirely sure what it means if we change the execution environment in the .product file. I assume it will end up in the metadata that is generated from it, but I don't expect it will end up in the eclipse.ini file. So my changes would include now: # revert the changes from yesterday, i.e. reset the execution environment, unless we find out what the consequences are # change the *important* and user-friendly parameter in the eclipse.ini which tells the user in a dialog box that he tries to run this package with the wrong JVM; this would be -Dosgi.requiredJavaVersion=1.6 (instead of 1.5 which is now in the eclipse.ini) After re-reading this bug, I think osgi.requiredJavaVersion is what we had in mind, and not the execution environment. >
> After re-reading this bug, I think osgi.requiredJavaVersion is what we had in
> mind, and not the execution environment.
Yes, that sounds right. I was obviously confused reading this bug. Even though title said "bree", I didn't see bree in the patch and somehow that the patch was for the eclipse.ini. So ... first I was doubting the eclipse.ini setting ... but then changed my mind after the discussion ... and now discover that's not even what was being discussed! Whew, communication is so hard! :)
But, yes, I think the constraint in the product level eclipse.ini is the right place to specify the level "required" for the "product". Bundle brees on the other hand, should always be as low as they can be, for the language level in that one particular bundle. (And, to be exact, bundles with no java code at all (a resource only bundle), should not even have a bree!).
Created attachment 171802 [details]
patch for osgi.requiredJavaVersion
I applied the attached new patch to CVS HEAD.
I am quite sure that this patch is the solution for your/our intention, but if not, please let's go on with the discussion.
The patch
* reverts the changes to the execution environment
* pushes the osgi.requiredJavaVersion parameter in the eclipse.ini from 1.5 to 1.6
You are correct, Markus. Thanks for catching that. I've fixed the title to reflect end result. The advantages of open development demonstrated once again. :) Verified (long ago). |