[HN Gopher] Java JDK 1.0 (1996)
___________________________________________________________________
Java JDK 1.0 (1996)
Author : gzer0
Score : 135 points
Date : 2021-05-15 10:21 UTC (12 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| ape4 wrote:
| There is classes.zip with a warning not to unzip. Now it would be
| classes.jar
| wanyehood wrote:
| thank God for dr Moses Buba for helping me with pills for penis
| enlargement and cure my friends diabetes, he has been putting
| smile on my face, and on the faces of my loved ones, I got his
| email address via facebook platform on a penis size forum on
| facebook so I decided to contact him directly on his email
| address, and my encounter with this herbal doctor is a lifetime
| mind blowing testimony, so to all the other men out there about
| little penis , and other people that are sick of all other deadly
| diseases such as kidney problems, diabetes, leukemia, herpes and
| those that needs pills or creams for erectile dysfunction,
| premature ejaculation, kindly contact him directly on his email
| address via: buba.herbalmiraclemedicine@gmail.com or WhatsApp him
| on +2349060529305 or call me for more details +15019914802 He is
| the best herbal doctor I have ever came across during my search
| for a cure, Good luck to all the sick people out there, I love
| you all
| neilv wrote:
| 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.
| trias wrote:
| 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.
| quickthrower2 wrote:
| Sounds like downright pragmatism
| slver wrote:
| Think about it.
| [deleted]
| vbezhenar wrote:
| int is signed.
| rzzzt wrote:
| You don't want to go back 2 billion years from 1900?
| froh wrote:
| on x86 and arm. not on s390.
| rzzzt wrote:
| In a Java Virtual Machine, it is a 32-bit signed value: htt
| ps://docs.oracle.com/javase/specs/jvms/se7/html/jvms-2.ht..
| .
| froh wrote:
| 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.
| formerly_proven wrote:
| That's a verbatim copy of struct tm from C.
| javap wrote:
| Interesting, Java 1.0 has 6 top level packages
|
| Java.applet Java.awt Java.io Java.lang Java.net Java.util
| anthony88 wrote:
| I guess that all the Java programs that might be consider as slow
| back then may be running pretty fast right now.
| muizelaar wrote:
| An even earlier release is here:
| https://github.com/Marcono1234/HotJava-1.0-alpha/tree/master...
| Flex247A wrote:
| Interesting!
|
| The code looks very readable!
| csunbird wrote:
| Most of the complexity is hidden in the JVM and its native
| methods. But, I agree that base classes are very readable.
| kaba0 wrote:
| Also, it didn't really contain state of the art GCs, nor JIT
| compilers, so the complexity was less back then.
| gzer0 wrote:
| 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...
| mobilio wrote:
| It's discussed here:
| https://news.ycombinator.com/item?id=27064800
| doggodaddo78 wrote:
| 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.
| fnord77 wrote:
| 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
| chrisseaton wrote:
| 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.
| unixhero wrote:
| Interesting! Well is the sourcecode for the Java JVM not open
| and available?
| brabel wrote:
| Yes, and it's available on GitHub now!
|
| Here's the heap implementation, for example: https://github.c
| om/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
| gzer0 wrote:
| 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
| zozbot234 wrote:
| 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.
| akie wrote:
| I just did a legally problematic thing.
| emma-w wrote:
| That was my risky click for the day!
| [deleted]
| johnwheeler wrote:
| I doubt Oracle is going to sue
| hota_mazi wrote:
| Yeah, they're not the kind of company that sues.
| anoncake wrote:
| One Reasonable Adult Called Larry Elison
| andrewshadura wrote:
| I wouldn't at all be surprised if they did.
| dvfjsdhgfv wrote:
| A nice C&D will suffice.
| twic wrote:
| 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...
| tom_mellior wrote:
| 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.
| twic wrote:
| 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.
| [deleted]
| eplanit wrote:
| 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).
| throwaway4good wrote:
| The network is the computer.
| hyperpallium2 wrote:
| write once, run everywhere
| throwaway4good wrote:
| Ahead of its time.
___________________________________________________________________
(page generated 2021-05-15 23:01 UTC)