Recursive Java Installer



  • I need to access a shitty government website that requires Java.  But it doesn't work properly, so I uninstall Java, download the latest version and launch the installer.

     

    WTF?  So I click on "Yes".

     

    To recap:

    • Java is shit
    • The installer is written by morons
    • Why the fuck do people insist on using Java?
    • "Recursive" may not be the proper word but I'm going with it 
    • Fuck You Java


  • @El_Heffe said:

    I need to access a shitty government website that requires Java.  But it doesn't work properly, so I uninstall Java, download the latest version and launch the installer.
    That's your problem; shitty government websites require you to install an obsolete version with known security vulnerablilities.

    I have the latest update to Java 7 on my computer. Some of my employer's internal training pages don't work on anything more recent than 5. (Even the ones that work with recent Java don't work in anything other than IE, but that's probably no surprise to anyone.) I have to go find some random computer that hasn't been updated, but all of these that I know of (formerly used by contractors who are no longer with us, thus now redundant) have now been taken be coworkers whose own machines have broken for one reason or another.

     



  • Dynamic linking is why we can't have nice things



  • @Ben L. said:

    Dynamic linking is why we can't have nice things
     

     This thread is now about finding good insults towards people that prefer static to dynamic linking.

     I liked the one from the last thread with how deliberately static linking is like shitting in an outhouse out of fear that the plumbing network will come down any second now, but I think we could do better.



  • @fire2k said:

    @Ben L. said:

    Dynamic linking is why we can't have nice things
     

     This thread is now about finding good insults towards people that prefer static to dynamic linking.

     I liked the one from the last thread with how deliberately static linking is like shitting in an outhouse out of fear that the plumbing network will come down any second now, but I think we could do better.

     

     

    How about, "Static linking is like driving your car through the side of a convenience store for fear that you won't be able to find it in the parking lot"

     



  • More fun Java/programs that use Java fuckups:

    One of our departments relies pretty heavily on a piece of software called FileMaker and a specific plugin called SuperContainer. I'm not sure if they're shitty programs or the were installed/configured shittily, but they're extremely fragile and non-intuitive and I pretty much try to avoid touching them at all. We had an issue about a month ago where FM would crash as soon as it loaded. Open the program, splash screen, and then boom - crash to desktop. A couple of frustrating days later, I tracked the issue down to the latest Java release. Now, SuperContainer needs Java, supposedly, but couldn't deal with the latest version of Java. But here's the other interesting thing: completely uninstalling Java fixed the issue, and the plugin works fine. There's a few annoying dialogs about SC needing Java to run, but dismiss those and it runs just fine.

    Other fucked up Java issue: the fancy printer the graphic designer uses comes with fancy software for it as well, which also ceased to function after updating to Java 7, as it "couldn't find the JRE." It only works with Java 6. What happened to backwards compatibility? OTOH, that's probably the printer software being fucked up, not Java.



  •  A friend of mine says that he ships a version of JRE with all his software.

    Not an installer, but bare binary files in a subfolder of the program's installation folder.

    It works, he says...

     



  •  @OldCrow said:

     A friend of mine says that he ships a version of JRE with all his software.

    Not an installer, but bare binary files in a subfolder of the program's installation folder.

    It works, he says...

    That does work perfectly, and it was what our company did, back when we released Windows programs written in Java(Around jre 1.6.8 i think). Then the user can't fuck up anything by uninstalling/upgrading/downgrading java, and you know your bundled java is not going to fuck up any browser settings. (We also offered a jre free version, but  almost all customers prefered the "Install and forget" version with the jre files included in the program directory.

     

     



  • @mikeTheLiar said:

    also ceased to function after updating to Java 7, as it "couldn't find the JRE." It only works with Java 6. What happened to backwards compatibility?
     

    I've had situations where upgrades haven't updated JAVA_HOME environment variables, meaning applications looking at the original location. Which - given a Java upgrade doesn't overwrite the existing location but performs a fresh install into another location - means some things still apparently work until someone decides to clear out the older Java versions.

    I've also come across applications that request the location of the JRE bin directory (yeah, SQL Developer - you're one of them. Why not interrogate %JAVA_HOME%, useless fucktards) then store this in a config file - so upgrades don't seem to have any effect (confusion as to why a bug persists across an update).

    It really is a cluster of fuck.

    @OldCrow said:

    A friend of mine says that he ships a version of JRE with all his software.

    It works, he says...
     

    Given that a Java install/upgrade leaves a rancid cumstain over any OS, his approach is probably the most trouble-free approach. Hell, even Oracle provide this as an option for SQL Developer because they have no control nor influence over how the Java installer works.



  • @OldCrow said:

     A friend of mine says that he ships a version of JRE with all his software.

    Not an installer, but bare binary files in a subfolder of the program's installation folder.

    It works, he says...

     

     

     Gratulations, you are now security maintainer of a version of java. We hope you handle this gracefully and responsibly.

    And now do go celebrate.

     



  • I refuse to install java now, but sometimes want to use a java based sql client called SQuirreL. I download jPortable and extract it into a folder, and set up a batch file to set JAVA_HOME appropriately. This way, java's not actually available to browsers (avoiding some security issues perhaps), trying to install updates in the background, or generally littering my OS drive with files.



  • @OldCrow said:

     A friend of mine says that he ships a version of JRE with all his software.


    Write once, run in precisely one place and one place only.



  • @fire2k said:

     Gratulations, you are now security maintainer of a version of java. We hope you handle this gracefully and responsibly.

    And now do go celebrate.

     

    But that is no risk. Since the java is not installed(Just copied to the same folder as the program) it don't interact with any browsers or other software. And it is not in the system path, so it can't get run by accident.

     



  • @OldCrow said:

     A friend of mine says that he ships a version of JRE with all his software.

    Not an installer, but bare binary files in a subfolder of the program's installation folder.

    It works, he says...

     

    I believe this is the only correct way to ship something that uses external libraries on Windows. Don't bother trying to install them where other programs can use (and replace) them; you'll only end up with version conflicts out the wazoo. Just pack them in with your app, keeping the whole kit hidden away from the rest of the debacle that is dynamic libraries on Windows.


  • Trolleybus Mechanic

    @Vanders said:

    @OldCrow said:

     A friend of mine says that he ships a version of JRE with all his software.

    Write once, run in precisely one place and one place only.

     

    That one place being the developer's computer.

     



  • @lolwtf said:

    ]I believe this is the only correct way to ship something that uses external libraries on Windows. Don't bother trying to install them where other programs can use (and replace) them; you'll only end up with version conflicts out the wazoo. Just pack them in with your app, keeping the whole kit hidden away from the rest of the debacle that is dynamic libraries on Windows.
     

     In other words it's like driving a car through a convenience store for fear that either you won't be able to find it again or some other customer will accidentally take your car.

     



  • @Lorne Kates said:

    @Vanders said:

    @OldCrow said:

     A friend of mine says that he ships a version of JRE with all his software.


    Write once, run in precisely one place and one place only.

     

    That one place being the developer's computer.

     


    It works on my machine!



  • @Lorne Kates said:

    @Vanders said:

    @OldCrow said:

     A friend of mine says that he ships a version of JRE with all his software.


    Write once, run in precisely one place and one place only.

     

    That one place being the developer's computer.

     


    Write once, run anywhere.

    Seriously guys, you can physically move computers.



  • @lolwtf said:

    I believe this is the only correct way to ship something that uses external libraries on Windows. Don't bother trying to install them where other programs can use (and replace) them; you'll only end up with version conflicts out the wazoo. Just pack them in with your app, keeping the whole kit hidden away from the rest of the debacle that is dynamic libraries on Windows.

    Yes, this! You can easily meet or exceed the memory footprint achieved by any of those static-linking cowboys, and all without any risk that your stuff might start up as fast as theirs!



  • @lolwtf said:

    I believe this is the only correct way to ship something that uses external libraries on Windows. Don't bother trying to install them where other programs can use (and replace) them; you'll only end up with version conflicts out the wazoo. Just pack them in with your app, keeping the whole kit hidden away from the rest of the debacle that is dynamic libraries on Windows.

     This was one of the original causes of DLL Hell.  App A loaded blah.dll from its AppPath, later App B loaded blah.dll, expecting the version from its AppPath. The linker saw a copy of blah.dll was already in memory, and used it. If the user started App B before App A, both got version B of the dll, and so forth. This particular variant of DLL Hell has long since been 'solved' with the addition of version fields and ordinal matching.  What has grown out of that past though, developers installing application specific versions of dlls into system folders, continues to this day. windows side-by-side helps with some of this, but the behavior of many application developers / installation packagers is wrong.



  • @mt@ilovefactory.com said:

    @fire2k said:

     Gratulations, you are now security maintainer of a version of java. We hope you handle this gracefully and responsibly.

    And now do go celebrate.

     

    But that is no risk. Since the java is not installed(Just copied to the same folder as the program) it don't interact with any browsers or other software. And it is not in the system path, so it can't get run by accident.

     

     

     

    What if it does (like 90% of apps nowadays)? What if it's something like let's say JDownloader (which both ships it's own JRE and asks for a 32-bit JRE PATH manually), which does nothing but interact with external websites? What if your app consumes Files like JPEGs? If your application is extremely useless I really don't see any advantage in shipping 30megs of JRE with it.

     



  • @fire2k said:

     Gratulations, you are now security maintainer of a version of java. We hope you handle this gracefully and responsibly.
     

    Whatever. Do you really think that an up-to-date version of Java is harder to exploit than an old one?

    (And if the old one is version 5 or less, it's likely more secure.)



  • @BC_Programmer said:

     In other words it's like driving a car through a convenience store for fear that either you won't be able to find it again or some other customer will accidentally take your car.
     

    After the first hundred times that another customer takes your car, I can understand why people go through that route.



  • @GrizzlyAdams said:

    This was one of the original causes of DLL Hell.  App A loaded blah.dll from its AppPath, later App B loaded blah.dll, expecting the version from its AppPath. The linker saw a copy of blah.dll was already in memory, and used it. If the user started App B before App A, both got version B of the dll, and so forth
     

    DLL Hell doesn't mean what you think it means. It was because the installers were dropping the DLLs to Windows directory.

    The DLL loader does path search and name matching within the process boundary only, and only when a DLL is loaded by the base name. DLLs in different processes with different AppPath are searched independently.

    If the same DLL file is loaded to different processes, they will share the read-only executable pages which reduces the physical memory pressure.



  • @GrizzlyAdams said:

    developers installing application specific versions of dlls into system folders
    That's the problem. 

    There's an old saying that I just made up:  If it can be done, some idiot will figure out how to do it wrong.



  • @El_Heffe said:

    The installer is written by morons
    It's using Windows Installer, and both errors come from it. I still don't understand how Microsoft managed to fail so spectacularly when writing the engine which is used by a large number of Windows applications. This might be of some help.
    @GrizzlyAdams said:
    This was one of the original causes of DLL Hell.  App A loaded blah.dll from its AppPath, later App B loaded blah.dll, expecting the version from its AppPath.
    Only if you're thinking of COM stuff, which can only be registered once per system (but if you install and register a COM library in a private location, you deserve all the pain that results from that). Regular DLL hell happened because everybody put their shared libraries to System32, often without checking if a newer version of library is already installed. (the loader always used full pathname when checking if a library is already loaded, so even if programs A and B both installed a private copy of a DLL, each would load their own version when run)

    One solution to DLL hell was SxS, but that brought it's own bag of problems.



  • @Mcoder said:

    @fire2k said:

     Gratulations, you are now security maintainer of a version of java. We hope you handle this gracefully and responsibly.
     

    Whatever. Do you really think that an up-to-date version of Java is harder to exploit than an old one?

    (And if the old one is version 5 or less, it's likely more secure.)

     

     

    I don't know why you people can't distinguish between something having security holes and something having more (and more publicised) security holes

    Yes, Java is pretty insecure. Yes, Oracle is pretty bad at patching. No, that is no reason to be running Java SE6U6.

    Or to quote myself from the last discussion about HTTPS: "A door can be broken into, let's never lock anything ever again"

     



  • @ender said:

    This might be of some help.
    Holy Crap Welcome to a whole new world of WTF.

    First, to recap:

    • Uninstall Java from Windows Control Panel
    • Search hard drive and registry, deleting anything that appears to be related to Java
    • Reboot
    • Try to install Java
    • Installer says Java is already installed and can't continue because Java is not installed

    OK, now onto the Microsoft Fixit program. I run it, it does some stuff and then gives me a list of programs and tells me to choose one to uninstall.  Java is not listed so I select "Not Listed" (clever, eh).  And I am presented with this:

      (click for embigification)

    What . . . The . . . Fuck.  I am supposed to know or find this product code . . . . how?  You've got to be shitting me.  But wait.  It gets better.  And by better, or course, I mean worse.  Onward to Plan B.

    Plan B: The day before I ecountered this problem I did a backup.  I'll just do a restore from that image and at the very least I'll be back to where I started.  A few minutes later, everything is back to (more or less) normal.  Love that Acronis True Image.  

    Run the Microsoft Fixit program again.  This time Java is listed, so I select it to uninstall.  The program churns for a while and then announces that is has successfully uninstalled Java, complete with a nice green checkmark to tell ime it did the job.  There's just one small problem.  IT'S STILL FUCKING THERE!!  Absolutey nothing was removed.

    I've never been a Microsoft basher, but this is one useless piece of shit.

     



  • @El_Heffe said:

    I've never been a Microsoft basher, but this is one useless piece of shit.
    Welcome to the world of pain that is Windows Installer. Hope you never have to fix a broken HP driver installation (FixIt usually works, you just have to run it for each of the 30 modules that HP installs separately - not fun when you have 15 computers which all keep popping up with ToolboxFX errors, and where neither the Control Panel uninstall, nor HP's batch file [that's supposed to remove the crap] works).


    Anyway, another thing you may try is this: open regedit, navigate to HKEY_CLASSES_ROOT\Installer\Products, press Ctrl+F and search for Java. Delete any key that has Java in ProductName (and since you have TrueImaage, you can always restore if you screw something up).


    And since we're talking about TrueImage, is it just me, or is it very very very slow when doing restores? Full backup of my SSD takes around an hour, restore took almost 6 hours (my SSD died on Friday)...


  • Discourse touched me in a no-no place

    @El_Heffe said:

    If it can be done, some idiot will figure out how to do it wrong.
    The problem is that the universe has an infinite supply of greater idiots.

    The fix is to use live grenades for the idiot-proofing…



  • Do you have UAC turned off? What does it say in event manager?



  • @El_Heffe said:

    First, to recap:

    • Uninstall Java from Windows Control Panel
    • Search hard drive and registry, deleting anything that appears to be related to Java
    • Reboot
    • Try to install Java
    • Installer says Java is already installed and can't continue because Java is not installed

    Yeah, I had a bunch of school workstations in that state. It was a pain in the arse and there is indeed wtf in every direction.

    Here's an untested cut-n-paste of the relevant bits of my well-tested school update script; see if it works for you. Requires msi-info.js.

    set "bin=%ProgramFiles%"
    if "%PROCESSOR_ARCHITECTURE%" == "AMD64" (
    	set "bin32=%ProgramFiles(x86)%"
    ) else (
    	set "bin32=%bin%"
    )
    

    set del=@call :del
    set rmdir=@call :rmdir
    set run=start "Waiting..." /wait
    set msiexec=%run% msiexec /passive /norestart
    set msiinfo=cscript /nologo "%bin%\flabdablet\msi-info.js"
    set return=goto :eof

    title Uninstalling Java runtime environment...
    net stop "Java Quick Starter"
    taskkill /f /im jusched.exe
    set filter="^Java(TM) 6 |^J2SE Runtime |^Java 7 "
    for /f "tokens=2" %%G in ('%msiinfo% %filter%') do %msiexec% /x %%G
    for /f "tokens=1-3* delims= " %%F in ('%msiinfo% %filter%') do @(
    echo %%I
    reg delete "HKCR\Installer\Products%%F" /f
    reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products%%F" /f
    reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall%%G" /f
    reg delete "HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall%%G" /f
    %del% "%%H"
    )
    %rmdir% "%bin%\Java" "%bin32%\Java"
    %return%

    :del
    @for %%F in (%*) do if exist "%%~F" del /f /q "%%~F"
    @%return%

    :rmdir
    @for /D %%D in (%*) do if exist "%%~D" rmdir /s /q "%%~D"
    @%return%



  • @ender said:

    And since we're talking about TrueImage, is it just me, or is it very very very slow when doing restores? Full backup of my SSD takes around an hour, restore took almost 6 hours
    TrueImage has always been very speedy for me.  And now with my SSD, recovery takes less than 10 minutes (backup takes longer, but still fast).  That's why I love it.  If I fuck up (and I won't mention how often that happens) I can have everything back in working order in a matter of minutes.

    Are you running it from within Windows? I always run TrueImage from the bootable CD.



  • @El_Heffe said:

    Are you running it from within Windows? I always run TrueImage from the bootable CD.
    I do backups from live system (which is fast - under an hour for full backup, a few minutes for incrementals backups). Restoring single files is reasonably fast, too (again, on a live system), but when I need to do a full restore, it always takes ages (and I run that either from WinPE, or from the Linux environment they have). The weird thing about restore is, that TI doesn't seem to be doing anything most of the time (I've got Process Explorer in my WinPE environment, and it's graphs show no CPU utilization, while I/O graph looks like this: /_/_/\ - basically, do nothing most of the time). Because of the slow restore (it's been like that in all versions I used so far), I'm currently evaluating Macrium.



  • @mikeTheLiar said:

    ...ceased to function after updating to Java 7, as it "couldn't find the JRE." It only works with Java 6. What happened to backwards compatibility?
     

    Sounds like the software had a hard-coded path to Java 1.6... That's stupid design; not related to Java. Let's face it, while Java has its "moments", a lot of this sort of thing can be attributed to idiot developers who happen to be using Java.



  • @snoofle said:

    @mikeTheLiar said:

    ...ceased to function after updating to Java 7, as it "couldn't find the JRE." It only works with Java 6. What happened to backwards compatibility?
     

    Sounds like the software had a hard-coded path to Java 1.6... That's stupid design; not related to Java. Let's face it, while Java has its "moments", a lot of this sort of thing can be attributed to idiot developers who happen to be using Java.


    That is quite literally the point I made in the very next sentence of the quoted post.
    @mikeTheLiar said:
    OTOH, that's probably the printer software being fucked up, not Java.



  • For what it's worth, I tried out the cut-n-paste script above and it works. Even after simulating uninstaller failure by commenting out the line that runs %msiexec% /x, subsequent Java installations skip the doomed attempt to uninstall previous versions and run to completion.



  • @BC_Programmer said:

    @fire2k said:

    @Ben L. said:

    Dynamic linking is why we can't have nice things
     

     This thread is now about finding good insults towards people that prefer static to dynamic linking.

     I liked the one from the last thread with how deliberately static linking is like shitting in an outhouse out of fear that the plumbing network will come down any second now, but I think we could do better.

     

     

    How about, "Static linking is like driving your car through the side of a convenience store for fear that you won't be able to find it in the parking lot"

     

    I'd suggest that it is more like sitting in your car looking at an occupied space, waiting until the space is free, because you always have to use that space.



  • @OldCrow said:

     A friend of mine says that he ships a version of JRE with all his software.

    Not an installer, but bare binary files in a subfolder of the program's installation folder.

    It works, he says...

     

    I have just given up on trying to make Alice 2.3 work with any version of Java newer than the one it embeds. Fuck it. I've turned on NTFS file compression for its entire Program Files subfolder instead. Slows it down a tiny bit but saves more than the size of the bundled JRE.



  • @flabdablet said:

    For what it's worth, I tried out the cut-n-paste script above and it works. Even after simulating uninstaller failure by commenting out the line that runs %msiexec% /x, subsequent Java installations skip the doomed attempt to uninstall previous versions and run to completion.

    I'll try it out one day when I feel like messing with it.

     



  • @eViLegion said:

    @BC_Programmer said:

    @fire2k said:

    @Ben L. said:

    Dynamic linking is why we can't have nice things
     

     This thread is now about finding good insults towards people that prefer static to dynamic linking.

     I liked the one from the last thread with how deliberately static linking is like shitting in an outhouse out of fear that the plumbing network will come down any second now, but I think we could do better.

     

     

    How about, "Static linking is like driving your car through the side of a convenience store for fear that you won't be able to find it in the parking lot"

     

    I'd suggest that it is more like sitting in your car looking at an occupied space, waiting until the space is free, because you always have to use that space.

     

     

    I actually really like those both, but the main opposing argument to dynamic linking isn't that it doesn't work (which would be insane), but speed.

     So how about "Static linking is like driving your car through a wall into wal-mart, because parking would take too long. Everybody else had the same idea and there is no space left. Most of them drive the same identical shitty car as you do, trying to get the same products as you"

     


Log in to reply