Java JDK 1.0 (1996) | Hacker News Reader

Java JDK 1.0 (1996)

github.com

148 pointsgzer045 comments

I remember being very excited when this came out. What impressed me right off was the java.net package -- back then, few language environments (except in Unix-land) had built-in networking support. That was usually a (kludgy) add-on package. That, along with Threads made Java really stand out as the language for the era of distributed computing. Applets were a great idea that unfortunately didn't pan out.

It still has a lot of good qualities, but is one of my least favorite languages to use (much more into Go now).

Applets may be dead now, but they did deliver a lot of value during their lifetime. That's a success in my book.

was expecting the actual vm source code, which I believe is written in C and is an engineering marvel. This looks like just the end user install package

https://github.com/ufuu/JDK10/blob/main/misc/DOCS/ACROBAT/DO...

Might not be exactly what you are looking for, but I just added the original VM spec PDF going over the JVM architecture in C

The original JDK didn't have the kind of things you're probably thinking of when you talk about an engineering marvel, like the JIT and advanced GCs.

Interesting! Well is the sourcecode for the Java JVM not open and available?

Yes, and it's available on GitHub now!

Here's the heap implementation, for example: https://github.com/openjdk/jdk/blob/master/src/hotspot/share...

The GraalVM is a Java implementation of the Java compiler and VM and it's also on GitHub: https://github.com/oracle/graal

It really was nice and simple back then!

I always chuckle when i come across this class, which has been there since the beginning, and does absolutely nothing:

https://github.com/ufuu/JDK10/blob/main/src/src/java/lang/Co...

What do you mean by "does absolutely nothing"? It does something, namely load a dynamic library that presumably implements its methods. Now maybe that library has never done anything, but that's impossible to tell from the code you linked.

I mean that the native methods it ultimately calls do nothing, and never have.

The early versions of the JVM didn't include a compiler, they were purely interpreting, so those calls had to be no-ops. Later versions included a JIT, but the decision of which classes and methods to compile was made by the JVM, and again, those calls were no-ops. As far as i know, there was never a JVM from Sun / Oracle where those methods did anything.

It's possible that IBM's or some of the other JVMs did something with those calls. But in general, having user code be involved in the decision of which methods to JIT is the wrong approach.

I vaguely remember that in the 1.0 era, the plan was that JIT compilers would be third-party plug-ins to the Sun JVM. So you'd buy a compiler from, say, Borland, install it into your JVM installation, and then when java.lang.Compiler was used, it would load your shiny new Borland compiler, which would somehow magically interact with the JVM to compile bytecode. I never heard of this happening. There wasn't a published JVM API for the compiler to talk to, so it would have required a lot of close cooperation between Sun and the compiler vendor.

An even earlier release is here: https://github.com/Marcono1234/HotJava-1.0-alpha/tree/master...

Note that this is under a proprietary license (see toplevel COPYRIGHT code). Given the rather messy history around the Java API, it might be legally problematic to look at this code.

I just did a legally problematic thing.

I doubt Oracle is going to sue

Yeah, they're not the kind of company that sues.

One Reasonable Adult Called Larry Elison

Just let me know when they sue.

I wouldn't at all be surprised if they did.

A nice C&D will suffice.

That was my risky click for the day!

Interesting, Java 1.0 has 6 top level packages

Java.applet Java.awt Java.io Java.lang Java.net Java.util

I came across this post [1] in which the author discovers an undocumented feature in the JVM.

"Although the first stable release of Java used bytecode version 45.3, the JVM will actually accept classfiles with versions starting at 45.0. Furthermore, there’s an undocumented feature in the JVM where it parses Code attributes slightly differently when the version is 45.0 - 45.2.

In a normal classfile, the stack, locals, and code length fields of the Code attribute have lengths of 2, 2, and 4 bytes respectively, but in a pre-45.3 classfile, the JVM expects them to be 1, 1, and 2 bytes instead. Normally, this means that a pre-45.3 classfile produced by ASM will just crash when run on the JVM because the JVM encounters garbage data while parsing and rejects it.

However, if you are very careful, it is possible to construct a classfile that is valid when parsed with the 2,2,4 widths, and also valid when parsed with 1,1,2, but parses as different code in each case. This means that it is possible to craft a classfile that executes one piece of code when run on the actual JVM and displays a completely different set of fake code when viewed with reverse engineering tools"

TL;DR JVM contained an undocumented feature in the JVM where it parses Code attributes slightly differently when the version is 45.0 - 45.2. The stack, locals, and code length typically has 2,2,4 bytes rspectively; in pre-45.3 classfiles, the JVM expects them to be 1,1,2 bytes instead.

[1] https://blog.polybdenum.com/2021/05/05/how-i-hacked-google-a...

[2] https://github.com/openjdk/jdk/commit/eedc99c9ab2647f0233e48...

It's discussed here: https://news.ycombinator.com/item?id=27064800

There is classes.zip with a warning not to unzip. Now it would be classes.jar

The String class was much simpler back then! https://github.com/ufuu/Java-JDK10/blob/main/src/src/java/la...

I guess that all the Java programs that might be consider as slow back then may be running pretty fast right now.

The network is the computer.

write once, run everywhere

Ahead of its time.

I remember this. Java was exciting back then. They did numerous things that were either new or that no one outside of fringe/research was using.

The AWT GUI toolkit was very minimal, but I was able to develop nice desktop apps by writing my own widgets.

Before Swing.

Also, I wrote a themeable, JNI-using installer that ran a JRE from a CD-R. It was slow to load at first but it seemed impressive to users.

Interesting!

The code looks very readable!

Most of the complexity is hidden in the JVM and its native methods. But, I agree that base classes are very readable.

Also, it didn’t really contain state of the art GCs, nor JIT compilers, so the complexity was less back then.

https://github.com/ufuu/JDK10/blob/main/src/src/java/util/Da...

> private int tm_year; /* years since 1900 */

when you have 4.3 billion years to choose from but decide for 1900.

That's a verbatim copy of struct tm from C.

Sounds like downright pragmatism

int is signed.

It would be possible and kind of hilarious to use a negative offset from year 2b.

You don't want to go back 2 billion years from 1900?

on x86 and arm. not on s390.

In a Java Virtual Machine, it is a 32-bit signed value: https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-2.ht...

my bad you're right. I got confused on if we are on the java or on the c side of things, because we discussed 'verbatim copy of c struct... fields'

apologies.

Think about it.

Judging from the downvotes, a good portion failed at thinking about it. Answer:

In the 20th century, we commonly expressed the year by its last two digits, you know this is why we talk about "70s", "80s", "90s". It's a small number, not ambiguous, and it also happens to be "the number of years since 1900". So of course a computer in the mid to late 20th century would choose this base. IT means the number is convenient for display, but also works for the machine, because "years base 1900" is a valid machine model as well. And it became a popular time format others picked up.

Lo and behold, though, the world didn't end in 2000. What do we do? Well, let it go over 99 and we add "1900" to it for display purposes, so we can maintain BC.

There. That's why we didn't choose any other base from 4.3 billion years or whatever.

Reply on news.ycombinator.com