I have opensuse 12.2 with openjdk 1.7
For development purposes (eg ensuring java apps I write will work on machines with older versions of java, in particular 1.6)
Id like to be able to install a jdk 1.6, but in such a way that it does not interfere with the rest of the system.
Is this possible (with reasonable difficulty).
Is there any reason to prefer the oracle/openjdk version in this case?
Can I install one of these in a directory without the installation affecting any of the rest of my system, so that I can just tell my IDE (NetBeans) to use the jdk there?
There are numerous posts how to do this in openSUSE.
There is an update-alternatives sub-system which supports easily switching between versions of subsystems and is commonly used to switch between installed versionsof Java (old or more common way to edit your bash profile can also work but is more trouble in the long run).
p8mode wrote:
>
> Hello,
>
> I have opensuse 12.2 with openjdk 1.7
> For development purposes (eg ensuring java apps I write will work on
> machines with older versions of java, in particular 1.6)
> Id like to be able to install a jdk 1.6, but in such a way that it
> does not interfere with the rest of the system.
> Is this possible (with reasonable difficulty).
>
> Is there any reason to prefer the oracle/openjdk version in this case?
> Can I install one of these in a directory without the installation
> affecting any of the rest of my system, so that I can just tell my IDE
> (NetBeans) to use the jdk there?
>
> Thanks in Advance.
>
>
There is no need for multiple versions of jdk. Install 1.7 and instruct
the compiler in Netbeans to produce 1.6 compatible class files
if you are compiling manually then do this
-target version
Generate class files that target a specified version of the VM.
Class files will run on the specified target and on later versions, but
not on earlier versions of the VM. Valid targets are 1.1, 1.2, 1.3, 1.4,
1.5 (also 5), 1.6 (also 6), and 1.7 (also 7).
The default for -target depends on the value of -source:
If -source is not specified, the value of -target is 1.7
If -source is 1.2, the value of -target is 1.4
If -source is 1.3, the value of -target is 1.4
If -source is 1.5, the value of -target is 1.7
If -source is 1.6, the value of -target is 1.7
For all other values of -source, the value of -target is the
value of -source.
Thanks for the helpful suggestion.
I had tried this already.
Actually the current version of NetBeans comes with a setting in the IDE (via Project Properties - sources) which allows one to set this from a combo box. It seems setting a source or target javac option separately wont work (so one has to use the IDE to set this or not at all) When I set this ui option (to use Jdk 1.6) I get no warning/error when using java.nio.charset.StandardCharsets, which was documented as having been introduced in Java 1.7.
I do however get a warning if I use a string in a switch statement (another new feature of 1.7). So I presumed that this is somehow broken in NetBeans.
Trying it on the command line (with the javac -source 1.6) produced the same results however. So it seems that the compiler option isnt working (or StandardCharsets were really introduced earlier than documented, which I doubt).
p8mode wrote:
> tsu2;2580768 Wrote:
>> There are numerous posts how to do this in openSUSE.
>>
>> There is an update-alternatives sub-system which supports easily
>> switching between versions of subsystems and is commonly used to switch
>> between installed versionsof Java (old or more common way to edit your
>> bash profile can also work but is more trouble in the long run).
>>
>> TSU
>
> Can you please be link some of these posts.
> Im not sure what an “update-alternatives sub-system” is. Can you
> please explain.
I think it would be reasonable for you to explain what you have done
yourself to try to find the information you’re asking for, before you
asked tsu2 to spend more of his time chasing it down.
For example, did you even try man update-alternatives ?
On general principles I would not use the switcher in Netbeans. Somewhere else I ran into something similar but noticed the Oracle app seemed to be designed to run on RH which does not have an update-alternatives system and appeared to only work if Java was installed in a very specific location which is not where you’d find Java by default on openSUSE.
So, my recommendation is to disregard that the Netbeans switcher. You should switch/set Java at the OS level, not at the application level.
tsu2 wrote:
> On general principles I would not use the switcher in Netbeans.
> Somewhere else I ran into something similar but noticed the Oracle app
> seemed to be designed to run on RH which does not have an
> update-alternatives system and appeared to only work if Java was
> installed in a very specific location which is not where you’d find Java
> by default on openSUSE.
>
> So, my recommendation is to disregard that the Netbeans switcher. You
> should switch/set Java at the OS level, not at the application level.
I don’t know much about Java development environments, but switching
“the” environment (Java version) for the entire machine seems likely to
be problematic on a development machine.
Don’t you want to leave the “system” Java in place to be used by any
other programs you happen to use that are written in Java? I’d have
thought you want to be able to test software that you are developing
using a separate environment (sandbox?) or preferably multiple
environments. My first guess would be some scripts to change the
environment variables that point to Java.
Which sounds like it might be what Netbeans is doing (I’ve never used
it) but perhaps the Netbeans facility is broken or at least not flexible
enough.
But that’s just my thoughts, not based on practical experience, so could
be completely crazy.
AFAIK the update-alternatives system cannot get more granular than switching the entire system.
If you need to get more granular, then you can still configure your Java environment the “non-SUSE way” aka how the rest of the *NIX world does it. When I run into that type of situation, I usually refer to this page How to Set JAVA_HOME / PATH variables Under Linux Bash Profile
Although its use breaks configuring Java using update-alternatives, if you <know> you’re doing it (eg it’s your personal machine and not something some else is going to mess with), then go ahead.
There can be other reasons to not use update-alternatives, so for instance one software project I work on requires all sorts of application settings to be configured in the profile (so of course you create a profile.local file). In this particular case, because those application-specific configs also require switching Java, I just put all those config lines in my profile file and either comment or uncomment sections of lines to enable/disable various Java and particular applications settings at once.
Bottom line is that I feel that <if> a system config is built to be installed into update-alternatives, I find its use easy and cool to use.
But, if I have to manually install a new system (eg a Java) then I find that work about equal to creating the necessary lines in my profile.local especially now that I have a working version and use it to template new options.
And, for special use like development… That’s one of my primary uses of Virtualization and why I heavily use both fully virtualized environments like KVM (or Virtualbox, VMware, Xen, etc) and LXC or chroot when I need to build stuff in a jailed but not fully virtualized environment.
Excellent responses Tsu on the pros and cons of update-alternatives and the mention of LXC for lightweight virtualization dev sandboxes. Though I’m a big fan of LXC, the OP might find configuring them unwieldy if they need to run GUI development tools in the containers, but it is an excellent suggestion.