Community
Participate
Working Groups
Or, perhaps better, have an option that in one way or another says "use library only". I know on my 64bit systems, I've tried to set a 1.3 JRE, but it won't let me, because its 32 bit JRE. And I've looked and looked, and there is no 64 bit 1.3 JREs. (There were no 64 bit architectures, back then :) Perhaps this simply requires some sort of "user education", but wanted to enter this problem I have seen, since some users might see it too, especially for some of the third part bundles that (still) specify 1.3 as EE. Thanks,
To explain this "use case" with a little more detail. As you know, our bundles have BREEs all over the map. So to have a proper "development environment" setup, commmitters should have several VM's installed, and have them associated with proper "Execution Environment" as this effects how they are compiled, even if there's never any intent to "run" with that VM. Likewise, when we do a (proper) build, we must use "toolschain.xml" with JRE's associated with each BREE level. So, for a while (though not at the moment) we had one, SWT or something? That had BREE of 1.3. I learned I could define that in maven's toolchain.xml, and even though it was a 32 bit JRE, it will worked fine, for our build, because our build only uses the libraries to compile against ... it doesn't actually execute anything from that BREE. But, when I tried to set up my development environment to "match", it would not let me use the 32 bit JRE, knowing I could never "run" it, since I was running with 64 bit system (Eclipse and VM as well has hardware). So, the question is, it there some way to define "1.3" in such a 64 bit system so the libraries can be used at compile time ... even though of course never used to "run". This issue is visible again in our use of objectweb's ASM bundles, which (even though we don't compile them) normally have a BREE of 1.3 set (from the third party supplier). Just wondering if there is a way to "match" what they (and Tycho/Maven builds) do ... in the easiest possible way.
I've been bitten by having a 32-bit JRE and trying to launch a target workbench, but I don't see what we could do about that. It sounds like you are describing something different though. Can you explain exactly when you are encountering this and where you would expect to see a "use library only" option?
(In reply to Curtis Windatt from comment #2) > I've been bitten by having a 32-bit JRE and trying to launch a target > workbench, but I don't see what we could do about that. It sounds like you > are describing something different though. Can you explain exactly when you > are encountering this and where you would expect to see a "use library only" > option? Well, little that I know about it, when you go to "add a JRE runtime", the dialog gives you 3 choices: EE Description, Standard 1.1x VM, Standard VM. I was thinking "around there" somewhere ... I guess it'd be a "4th choice"? And user might have to provide some info normally inferred from executables? (such as, version)?
(In reply to David Williams from comment #1) > So, the question is, it there some way to define "1.3" in such a 64 bit > system so the libraries can be used at compile time ... even though of > course never used to "run". > My best advice is to define an EE file that is set to be 1.3 - I do this on Mac OS since there is no 1.4 / 1.5 jdk available. https://wiki.eclipse.org/Execution_Environment_Descriptions When you are crafting your EE file set the ids / levels to be 1.3 like: -Dee.id=J2SE-1.3 -Dee.class.library.level=J2SE-1.3 -Dee.language.level=1.3 then point the executable / libs at another version (64-bit). Then with your new EE file in hand, go to the Installed JREs page > Add... > choose the EE description option, then point it at the file.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the stalebug whiteboard tag.
