I’ve downloaded the JDK from Oracle’s website, and I’ve used the following commands in Terminal:
chmod +x j2sdk-1_3_0-linux.bin
and
./X
yes
X = file name with extension
“yes” agreeing to the license
which normally would extract the JDK in a folder. However, Terminal prints:
Unpacking...
Checksumming...
0
0
Extracting...
./j2sdk-1_3_0-linux.bin: 221: ./j2sdk-1_3_0-linux.bin: ./install.sfx.3963: not found
Done.
Can anyone help?
Edit- Looks like it doesn’t work for J2SE1.4 either. It extracts the folder, but the folder itself is blank. There is no data inside of it.
These are 32-bit binaries and you’re probably running a 64-bit OS, without the libs needed for backwards compatibility.
You didn’t say what OS you’re running, but using apt or yum install an “:i386” or “.i686” package, and watch it pull a bunch of 32-bit libraries, then try again.
You might also try “–help” and see if there’s a command-line arg you can supply to just extract the archive to a folder. If not, perhaps you can use unshar (from sharutils) to do so. Then you can run ldd on the installer executable, and see what libraries it needs.
I don’t feel like signing-up for an Oracle account to try it…
Would you mind explaining what the heck it is you’re trying to accomplish? Because it looks like whatever you’re doing is quite unusual, most Java SMEs will have a hard time not asking why you’re playing with such old JDKs. It’s possible you’re going down a much harder path than you need to.
Are you on some super old machine? rcxb is probably on the right track that you may not even have the right files. And hell, ditch Oracle’s distributions too if you don’t actually need those fossil JDKs.
Java is largely backwards compatible, especially for older versions. So assuming you aren’t doing something exotic that requires older JDKs, I would recommend trying to use at least JDK 8. It can be installed on Linux easily with SDKMAN (extremely helpful for situations where you need multiple versions installed, no OS really handles that situation very well without help):
They also have a few older Azul Zulu builds for 6 and 7 available, but nothing so ancient as what you’re referring to here. IIRC just two commands gets it installed:
Hey, I just got the same message after accidentally trying to extract a 32-bit/x86 version of JDK 5. This leading me to believe that I think you’re correct.
Just did a test install with Ubuntu 17.04 32-bit/x86 in a virtual machine, and it looks like it has extracted it to its entirety. 1.4 appears to have worked, but 1.3 is locked for some reason.
I’m not quite sure just how old java 1.3 or 1.4 is but let’s just say… nearly old enough to drink in Australia. Certainly old enough to consent.
edit:
1.3 has been able to drink in the USA for 2 years now. 1.4 is old enough to drink this year. As above, not sure what exactly you are trying to achieve here but I’d strongly suggest “don’t” unless its some niche crapware you’re trying to make work?
I’m trying to remember if Java 1.3-1.4 was from the days of Linux using libc5 as opposed to glibc being the c library shipping with Linux. Around about that time there was a big changeover and heaps of software broke with the shift.
That’s a big no. That was circa 1997, years before java-1.3’s release.
Not so much. Java-1.3 was initially released just a hair before Linux 2.4, and over a year before the first RHEL. But Java-1.3 continued to be supported/updated until 2006, so you could have reasonably have been running it on RHEL4 (kernel 2.6.9) or Fedora 5 (kernel 2.6.15).
Depending upon the distro, you can get 32-bit stuff working. On Arch, enable the multilib repo. In Fedora, I think RPM Fusion has the 32-bit libs - or perhaps they’re shipped with the default repos. I don’t know if Ubuntu still supports 32-bit, and if they do, it’s on borrowed time afaik.
Haha, hey you weren’t supposed to come back with an actual valid sounding reason!
Okay, so maybe “just use a modern version” may not accomplish that.
I do have a suggestion - you can achieve a similar effect by changing language level settings in your IDE/compiler to 1.3 or 1.4. Specifically “source compatibility”… so you could do this with a “modern” Java 8 JDK installed. I could explain how it’s done in Gradle, but Gradle isn’t exactly that old either…
At least syntax and feature wise, that’ll give you errors for features that aren’t supported. You may consider this cheating, since IDEs back then would’ve been a little less developed… but I guess it depends on what type of pain you’re looking to experience.
I guess NetBeans would give you the closest experience to back then, being old as dirt. NetBeans probably has an option somewhere to tell it what language level to use (been years since I used it), if you just create a regular Ant/Java project.
But yeah if you really want the authentic experience, you’re probably going to need some more drastic measures like using an older OS/machine.
