Java and system32
-
So it turns out Java installs a "java.exe" to the windows system32 folder.
Now you may think wtf, why is java installing into the core system folder?
Well this explains that:
To complicate things further the java.exe in system32 is just a dummy. It looks in the registry and then decides which real java.exe to use. The last JVM installed gets to be the one used, even if it is older.
Wait, so how do I pick a JVM to use?
To switch JVM s, you must normally reinstall the one you want.
Seriously, in the year 2014 why is this retarded form of Java version selection still here?
-
How else would you choose which version to run? It's horrible but I can't think of better solutions.
You don't need to reinstall, it's not hard to find and fix the registry value. Which also isn't a good solution, but I think the case of having multiple versions of Java installed and needing to choose a specific version to run isn't all that common. Just install one.
-
You can always explicitly run the one you want by full pathname, too. Which is probably a better way of doing it.
-
True. Or set in eclipse.ini, or set JAVA_HOME for many tools, or mess with your PATH.
-
Doesn't excuse them with installing junk into a core system folder
-
How would you solve the problem?
-
How would you solve the problem?
Just... not do it?
What "problem" does putting java.exe there solve, exactly? Somehow Chrome, Outlook, MechWarrior Online all manage to work fine without being in System32...
-
How many versions of Outlook do you have installed at one time?
How do other programs determine which version to run when they need Outlook?
-
How many versions of Outlook do you have installed at one time?
... but we've already determined that Java doesn't support having multiple versions installed at the same time. You have to uninstall and reinstall, or do a registry hack. So how does putting a copy of java.exe in the System32 folder help?
How do other programs determine which version to run when they need Outlook?
They just ask the OS to run the mailto: handler, and Windows decides for them.
A better question would be, how does a run WinForms application, or ASP.net application tell the OS what .net version it needs? The answer is obviously sorcery. Surely if the expert geniuses at Sun and Oracle can't figure it out, the only possible solution is dark magic.
Seriously, though. Java's been around since 1995. How is it possible that basic fucking problems like "version selection" or "coming up with a reasonable path for a Home folder in Windows" remain unsolved? Sure, .net had a lot of benefit learning from Java's mistakes, but it's been fucking 20 years and Java still hasn't fixed any of the mistakes!
-
How else would you choose which version to run? It's horrible but I can't think of better solutions.
On Debian:
# update-alternatives --config javaNot sure of all the stuff it fiddles with but...
onyx ~ readlink /usr/bin/java /etc/alternatives/javaBah, powerline is terrible for pasting stuff around
Changes the symlink at the very least. Probably updates
JAVA_HOMEas well.update-alternativesis a part ofdpkg, so it's a part of the package manager.On Windows, I don't know how you'd do it since I'm far from an expert on Windows internals, but I'd be surprised if there's no saner way.
-
How many versions of Outlook do you have installed at one time?
How do other programs determine which version to run when they need Outlook?
A better analogy is probably all of the versions of the MSVCRT you have floating around on your system. Or WoW64. 32 vs 64 bit java is an obvious use case for multiple versions of java. AFAIK, there's no sane way to do that.
-
I'm not sure why this is really an issue?
There's the dummy exe in SYSTEM32 because Windows looks there as part of the PATH by default, so unless the PATH is really screwed up it makes it easy for any app requiring Java to find the default version on that machine even if JAVA_HOME isn't set and it's not part of PATH.
If you need/want a specific version you can use JAVA_HOME and PATH to do it.Outlook and Chrome aren't the same scenario - you're either opening the exe directly, or launching a file associated with that exe by the OS.
Java might have JAR files associated to it, but might not, and it's most likely not going to have the EXE in the same folder I'm launching a class file or JAR file from.
I can be in any folder on Windows and launch java by just typingjavaat the command line and I cannot do that for Outlook (and I don't need to, either).
-
- It pollutes a core system folder.
- It shoves it in system32 without informing the user during install, the installer only asks for the main java install path
- This causes Java to need escalation to administrator when it really doesn't and shouldn't during install.
There's the dummy exe in SYSTEM32 because Windows looks there as part of the PATH by default
Hey the say could be said in Linux, we could just install /usr/sbin/, /usr/bin, /usr/local/bin into just /bin! Why bother?The partially sane way is making a /Program Files/Java/Java Selector/ folder and adding that to the system path.
-
This causes Java to need escalation to administrator when it really doesn't and shouldn't during install.
Is this why UAC interrupts what I'm doing to ask if I want Java to update, but then when I accept, it just pops up a notification balloon telling me that an update is available and that I should click to install?
-
This seems like a workaround (around?) some issue with the Windows PATH and EXE's. Probably it's the only way for Java programs that use an EXE to be run on Windows.
About having different versions of Java, of course this is a requirement, specially for developers.
-
What "problem" does putting java.exe there solve, exactly?
The problem of adding java to the system CLI's repertoire of commands without needing to do violence to the PATH environment variable. Adding executables to System32 on Windows is a very close analogue of adding them to /usr/bin on Unix.
The parallel case on Unix normally involves /usr/bin/java being a symlink rather than an actual executable; on many Linux distributions it resolves to /etc/alternatives/java, which is itself a symlink to the actual executable (which will be somewhere like /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java, the functional analog of C:\Program Files\Java\jre7\bin\java.exe).
/etc/alternatives is a forest of symlinks, designed to centralize the management of application programs for which alternative implementations are frequently offered. On Windows, that's part of the Registry's job.
Symlinks are not a supported feature on all Windows filesystems, so using an executable shim that does something exactly equivalent to symlink resolution via a Registry lookup strikes me as perfectly reasonable.
-
Adding executables to System32 on Windows is a very close analogue of adding them to /usr/bin on Unix.
And why is this a problem? Almost every software in Linux installs to
/usr/bin
-
This is a better way of explaining it. I was trying to remember what the equivalent on Unix was.
And why is this a problem? Almost every software in Linux installs to /usr/bin
It's not.This causes Java to need escalation to administrator when it really doesn't and shouldn't during install.
As it would on UNIX.lrwxrwxrwx 1 root other 16 Mar 11 2008 java -> ../java/bin/java
-
And why is this a problem? Almost every software in Linux installs to
/usr/bin
Except non-packaged binary software which install to a subdirectory of/optin order to avoid conflicts, and need a manual PATH update...
-
I'm not sure why this is really an issue?
Oracle doesn't own System32 and has no right to mess with Windows' buzinezz.
There's the dummy exe in SYSTEM32 because Windows looks there as part of the PATH by default, so unless the PATH is really screwed up it makes it easy for any app requiring Java to find the default version on that machine even if JAVA_HOME isn't set and it's not part of PATH.
So they do it in the off-chance the PATH variable gets hosed? Seriously? This is the reason?
If you need/want a specific version you can use JAVA_HOME and PATH to do it.
I don't know who "you" is in this scenario, but the issue here is that the Java executable itself doesn't have a way of specifying which version of the VM it requires, and even if it did, there's no way currently to install multiple versions of the VM at once.
This is a problem that exists in no other bytecode environment I'm aware of. Or, as Boomzilla points out, no other runtime-requiring environment I'm aware of. Even back in the 90s, by some miracle VB5 runtime apps could co-exist with VB6 runtime apps on the same OS at the same time.
Outlook and Chrome aren't the same scenario - you're either opening the exe directly, or launching a file associated with that exe by the OS.
Right; it was a terrible example, so we forget it and move on.
I can be in any folder on Windows and launch java by just typing java at the command line and I cannot do that for Outlook (and I don't need to, either).
Sure; but that only requires an entry in the PATH variable. Which Java already sets. So the System32 launcher-thing is, again, useless for solving this problem.
I'm still interested to hear what problem Oracle thinks it solves.
-
The problem of adding java to the system CLI's repertoire of commands without needing to do violence to the PATH environment variable.
That's what the PATH variable is for. And Java does "do violence to it", unless they've stopped that practice very recently. So no, this does not compute.
Adding executables to System32 on Windows is a very close analogue of adding them to /usr/bin on Unix.
Is it a close analog? Meaning if someone did that on Linux, you'd say, "why the fuck are those idiots screwing around in this folder they shouldn't be touching?"
Symlinks are not a supported feature on all Windows filesystems, so using an executable shim that does something exactly equivalent to symlink resolution via a Registry lookup strikes me as perfectly reasonable.
Whether they use a symlink or executable isn't the point. The point is it does not go there. Everything in the Windows directory belongs to Windows, it is not yours to touch, and the fact that you even can touch it is an unfortunate side-effect of history.
-
Oracle doesn't own System32 and has no right to mess with Windows' buzinezz.
And? Java is not the only software to do it, and I still don't see the problem.So they do it in the off-chance the PATH variable gets hosed? Seriously? This is the reason?
I don't work for Sun/Oracle so don't know, it's certainly handy that it does it.I don't know who "you" is in this scenario, but the issue here is that the Java executable itself doesn't have a way of specifying which version of the VM it requires, and even if it did, there's no way currently to install multiple versions of the VM at once.
There's a registry entry for the "default" version, and the exe in system32 uses that.
Unless I'm misunderstanding - you can have multiple versions at once.Sure; but that only requires an entry in the PATH variable. Which Java already sets. So the System32 launcher-thing is, again, useless for solving this problem.
I have 3 different versions of the JRE installed - none of them are in PATH for whatever reason. So it's either been removed, or it never added it.
-
And?
And you don't mess around with other people's shit!
I'm sorry, did you not attend kindergarten? Is this really a revelation to you?
Java is not the only software to do it,
Oh well you know kindergarten debating tactics, at least.
and I still don't see the problem.
Look, since I know it's impossible to explain anything to anyone on this forum, especially anyone who actually likes Java, I'll just say this:
You don't have to see the problem for it to be a problem.
-
Everything in the Windows directory belongs to Windows, it is not yours to touch, and the fact that you even can touch it is an unfortunate side-effect of history.
But System32 no longer has 32-bit stuff, so you can't trust the Windows directory and all bets are off.
-
It pollutes a core system folder.
Meh. You say "core system folder"; I say "well-known system folder; first place the CLI looks for executables by default". The only truly reasoned objection to just stuffing whatever you damn well please in System32, it seems to me, is the potential for namespace conflict with whatever MS decides to put in there. But MS has been dealing with far worse app-specific backward-compatibility issues than that for a very long time - they're surely used to it by now.
It shoves it in system32 without informing the user during install, the installer only asks for the main java install path
That's because System32 is a well known folder. It has its own KNOWNFOLDERID GUID and is chosen at Windows installation time, not Java installation time.
This causes Java to need escalation to administrator when it really doesn't and shouldn't during install.
Escalation to administrator is also required to make changes inside Program Files, which is where most of Java goes, just like any other system-wide package. Objecting to installers needing elevation is crazypants.
> There's the dummy exe in SYSTEM32 because Windows looks there as part of the PATH by default
Hey the say could be said in Linux, we could just install /usr/sbin/, /usr/bin, /usr/local/bin into just /bin! Why bother?
/bin exists in the root filesystem and its job is to contain the minimal set of executables needed just to make Unix start up and/or fix it when every other filesystem has broken.
/usr/bin is where executables installed by the distro maintainers are supposed to go.
/usr/local/bin is where executables installed by the local system administrator are supposed to go. By convention, /usr/local/bin is ahead of /usr/bin in PATH, so the local sysadmin can substitute local versions of stuff for what the distro provides without doing any violence at all to the distro's package management arrangements. This is handy for e.g. adding instrumentation and logging to existing commands, or installing locally-compiled versions of stuff when the distro-supplied version is not suitable for whatever reason.
The /sbin variants are for commands that require elevated privileges and should therefore not make themselves available by default in non-root shells. Typically you will only find the /sbin variants in the PATH for a root shell.
The partially sane way is making a /Program Files/Java/Java Selector/ folder and adding that to the system path.
I agree: that's a partially sane option. An even more partially sane option would be for Windows to provide a special folder analogous to /usr/local/bin, for non-MS packages to use; expecting every package to stick its own installation folder in PATH pretty rapidly makes PATH maintenance unwieldy.
-
Meh. You say "core system folder"; I say "well-known system folder; first place the CLI looks for executables by default". The only truly reasoned objection to just stuffing whatever you damn well please in System32, it seems to me, is the potential for namespace conflict with whatever MS decides to put in there. But MS has been dealing with far worse app-specific backward-compatibility issues than that for a very long time - they're surely used to it by now.
You are a horrible person.
-
non-packaged binary software which install to a subdirectory of /opt in order to avoid conflicts, and need a manual PATH update...
The Right Thing is to put your stuff in a subdirectory of /opt, and ask the sysadmin where to put symlinks to your launchables; in most cases this will end up being /usr/local/bin. PATH bloat is every bit as ugly on Unix as on Windows.
-
I have 3 different versions of the JRE installed - none of them are in PATH for whatever reason. So it's either been removed, or it never added it.
Oracle is very inconsistent about this. They don't really understand Microsoft Installer- Last time I dove into their installer, they were delivering an self extracting EXE and then launching it via custom action, which meant that repair installs would never, ever work.
You need UAC anyway, if you're writing to Program Files, so the java.exe that redirects doesn't seem all that bad to me. Still, either the PATH statement or the registry entry needs to point to the correct JRE, and the guys who write their installers are pretty crap about doing things the same way more then a few releases in a row.
Yeah, it's a bit weird, but it's far from the worst thing a java install does.
-
I'm sorry, did you not attend kindergarten? Is this really a revelation to you?
Me not touching your stuff and applications adding things to system32 aren't the same thing in my opinion.
Look, since I know it's impossible to explain anything to anyone on this forum, especially anyone who actually likes Java, I'll just say this:
You don't have to see the problem for it to be a problem.
Liking it wouldn't stop me agreeing it was a problem if I actually thought it was one, but I can't see the problem, so let's just agree to disagree rather than going around in circles.
-
You are a horrible person.
And disagree? Well... no-one durst
He's the best of course of all the worst
Somethin wrong /bin done he done it first
And he stinks so bad his bones /bin chokin and weepin greenish drops
In the light of the purple dildo
Where the torture never stops
-
-
Me not touching your stuff and applications adding things to system32 aren't the same thing in my opinion.
Yes, well, your opinion is wrong. Microsoft makes the OS, so Microsoft makes the rules, and their rules says, "don't touch our shit!"
Hello GlaDOS
Read that again and tell me he's not a horrible person.
"Well, it's wrong, and I know it's wrong, and it creates work for someone else to fix but... meh... that person already has a lot of work."
Yeah, uh, that's called "being a sociopath."
-
their rules says, "don't touch our shit!"
If that's what their rules said, Administrators would not get write permissions on System32 by default.
It's more of a guideline.
-
If that's what their rules said, Administrators would not get write permissions on System32 by default.
They don't, and haven't since 2007. Please duck low while exiting the timepod.
Did you seriously not know that? I'm really finding it hard to believe you can be this incompetent and still manage to feed yourself each morning.
-
-
They don't, and haven't since 2007. Please duck low while exiting the timepod.
This clean installation of Windows 7 disagrees with you.
-
Pssh. Obviously an ORACLE product is going to back your pro-Java propaganda.
Somehow I get this:
Which proves me right forever.
-
Administrators would not get write permissions
I think we can see where the next shot is coming from...
-
If you need to provide administrator permission to copy to a folder, you're not a member of Administrators.
Whether this is because you're using a limited account, or whether it's because you're using the non-elevated security token for an admin account, doesn't matter.
Did you seriously not know that? I'm really finding it hard to believe you can be this incompetent and still manage to feed yourself each morning.
-
I'm having a lovely time watching this exchange.
-
-
As an aside: Windows gets much more useful if you put sed.exe in System32.
-
-
/me gives @Keith a huge bowl of popcorn
Share and EnjoyTM
-
As an aside: Windows gets much more useful if you put sed.exe in System32.
As an additional aside: Windows gets ever so much useful when you install linux instead.
EDIT: popcorn?
-
If you need to provide administrator permission to copy to a folder, you're not a member of Administrators.
Oh for fuck's sake-- this bullshit again? Didn't we just do this like a week ago?
I'm not going to have the same fucking pedantic dickweed debate every fucking day. UAC being turned on is the default, I don't give a shit what you think because what you think is fucking wrong. And you know it's wrong. And you're only making this pedantic dickweed "well you're not really Administrator" argument to score forumpointzz.
Look, let's cut to the chase: if you think Java is a good product, you are fucking wrong. There are a billion things on this forum alone proving you wrong.
-
=(
)=|
=0
=|
=0
X| *gulp*
=D
-
/me gives @Keith a huge bowl of popcorn
The only thing worse than having the same stupid debate every fucking week is seeing the same unfunny shitty jokes over and over. Jesus Christ, even Dane Cook comes up with new material sometimes, people.
-
As of the time of this post the highest post number is....149849
10e9/149849 = 6673.somethingyou are claiming that each and every post here shows over 6 thousand unique examples of Java being a bad product?
would have bought it if you claimed that about discourse, but Java? nope. not buying it.
also refusing to accept your assertion that it's hyperbole. because reasons that are every bit as valid as yours for hating Java
-
If you think I think Java is a good product, you are fucking wrong. The Java installer is a broken-ass buggy piece a shit and it has caused me, personally, hours of wasted time.
There are so, so many things the Java installer gets wrong. Installing a launcher shim in System32 is probably the best thing it does.
java.exe : Java Glossary
