random neuron misfires

There have been dozens and dozens of posts attempting plenty of weird, unsupportable hacks and workarounds to get ADS working under the ARM cores used by the Apple M1/M2 chipsets. You need a few dependencies installed and configured to get this working, and Rosetta2 does not work in this situation.

Simply installing Apache Directory Studio from their download page or brew, will result in the following error message when you try to launch it:

This is because the version of Java installed via the OS or from Oracle’s own download page, will not work when it’s the native ARM or aarch64 version.

There are many posts that include installing the version of Java from temurin but that too, will give you the wrong version of the JDK to make this work.

brew install --cask temurin

You need at least Java version 11 in order to run Apache Directory Studio, but version 20 will also work, with the steps here.

Also, editing the path in the Info.plist in /Applications/ApacheDirectoryStudio.app/Contents/Info.plist to point to the temurin JDK, will also fail.

There’s an XML block at the bottom of the file that implies you can just point to a different java version you have installed and it will use that. It does, but then crashes with the following dialog, even with the temurin version installed:

<!-- to use a specific Java version (instead of the platform's default) uncomment one of the following options, or add a VM found via $/usr/libexec/java_home -V
    <string>-vm</string><string>/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Commands/java</string>
    <string>-vm</string><string>/Library/Java/JavaVirtualMachines/1.8.0.jdk/Contents/Home/bin/java</string>
-->

To see the versions of Java you may have installed, you can run:

$ /usr/libexec/java_home -V
Matching Java Virtual Machines (3):
    20 (arm64) "Oracle Corporation" - "Java SE 20" /Library/Java/JavaVirtualMachines/jdk-20.jdk/Contents/Home
    20 (x86_64) "Eclipse Adoptium" - "OpenJDK 20" /Library/Java/JavaVirtualMachines/temurin-20.jdk/Contents/Home
    17.0.6 (arm64) "Oracle Corporation" - "Java SE 17.0.6" /Library/Java/JavaVirtualMachines/jdk-17.jdk/Contents/Home
/Library/Java/JavaVirtualMachines/jdk-20.jdk/Contents/Home

Ok, enough of the context of the failures… let’s get on to fixing this. You can leave the line you edited into your Contents/Info.plist and let’s get the right version of the JDK installed. The version we install will just replace the version in that same directory, and you won’t need to change it (unless you get a different version of Java in these steps).

Even the Oracle installer refuses to continue when using the x86_64 version:

Instead of installing temurn using brew reinstall --cask temurin, you’ll want to visit the Adoptium Temurin download page and grab the version for x86_64, not aarch64, as you normally would get with brew or the Oracle downloads.

Once you download the x86_64 version of Temurin, it will install cleanly.

Now you can run ApacheDirectoryStudio directly from /Applications or your Terminal, and it will work!

The recent and critical Java CVE necessitates that everyone either uninstall, remove or update Java immediately.

My employer uses a lot of Java, and removing or uninstalling it across thousands of machines just isn’t possible. We also support 4 platforms for each new release (in 32-bit and 64-bit), so pushing out a new version of Java involves downloading, unpacking, deploying and releasing 8 different builds per version. Today’s recent news, means I have to download and deploy 16 separate builds of Java for 1.6u38 and 1.7u11 to meet the security requirements and keep us current.

Oracle’s website is painful enough to navigate, and downloading new Java releases from their site requires an interactive click-wrap agreement to be acknowledged before you can continue with the process; before the download links become visible or active in a browser to be clicked. When you attempt to download, you’ll be presented with a page that contains this:

To download an Oracle Java release from here, you have to go to their Oracle Java Download page, click “Accept License Agreement”, and then click each version of Java you want to download, to download interactively using your desktop browser to your desktop.

In a word: Ugh.

If you need to use those on a UNIX or Linux host as I do, you then have to then take those downloads that you’ve pulled with your browser, and scp/pscp (with PuTTY or similar) or rsync those over to your UNIX/Linux machine from your desktop.

Could this process possibly be more convoluted and complicated?

But there’s a solution: Wget! (with some secret sauce)

Read the rest of this entry »

The corporate VPN software I use to get onto the work LAN uses a Java-based “viewer” applet in a browser to get to my desktop machine (think “remote desktop”, but using a browser + Java applet), is an HTML page which uses Flash to deliver a Java applet, which then is used to do the “remote desktop” functionality. Yes, you read that right… HTML delivers the Flash which delivers the Java.

But I’ve recently rebuilt one of my Windows machines here at the office to include a 64-bit version of Windows Server 2003, and because of that, it’s been a bit of a struggle to find and reload all 174 applications I was previously using on the previous machine, in 64-bit format, as well as the 64-bit drivers necessary to support the peripherals (network, disk, scanner, printer, etc.). One of those was making sure my browsers were functioning correctly for everything I use it for, including accessing the VPN when I work remotely.

To that end, I installed the 32-bit version of Firefox for Windows, then the 32-bit Java SE Runtime 6u13, but that didn’t let Java applets to function in Firefox at all. about:plugins showed that Java u13 was seen and enabled as a valid plugin but applets would not work in Firefox. I tried using the Java Applets Test page, and it would just show a blank region where the applet should have been.

So I tried downloading the 64-bit Firefox for Windows and the matching 64-bit Java SE Runtime 6u13, but that too failed.

After I installed both versions of Java onto the machine, I decided to try the VPN connection using Internet Explorer, which worked, so I knew Java and Java applets were functioning correctly.

After some poking around, I found that there was one minor tweak that was required to get the Java applets to function in Firefox (either bitness).

While MSIE is loaded, go to the Java Test page and while there, you’ll see a Java applet icon in your Taskbar. Right-click on that, and you’ll see something like the following:

In the Java Control Panel, there is an option under (Advanced | Java Plug-in) labeled “Enable the next-generation Java Plug-in (requires browser restart)”. Disable (uncheck) that checkbox to enable Java to function correctly with Mozilla, as shown below:

Also, verify that Mozilla is enabled under “Default Java for browsers”, as shown below:

Click Apply, click Ok, then launch Firefox and try your applet again. You should see something like the following:

That’s it, you’re done! Now Java u13 should work fine in Firefox on 64-bit, without any issues.