> Although Java has evolved over the years, the core of the JVM has maintained stability – to the point where applications compiled with Java 1.0 can still be run on modern JVMs, albeit much faster. The bytecode format has (largely) remained unchanged;<p>Java has many warts but the bytecode stability is an admirable achievement.
Might be unknown to many how close we were to total MS dominance on the server side (in addition to the desktop which was owned by MS anyway) around 1992-6 and the push that Java and also the web got from Unix and open systems fans who weren't comfortable to surrender it all to MS.<p>Around 2000ish there was this push for "100% pure Java" re-implementations for common libs and stuff showing the power of a community sharing a common goal, but also the blueprint for a language-centric ecosystem (not my cup of tea) that's also present in today's Rust, Go, Python, and Node.js communities, though Node.js booted off CommonJs and older SSJS initiatives who were mostly Java drop-outs fleeing from Java's AbstractEnterpriseIntegrationPattern-ness.
I was involved using Java right from the very start, in 1995 while it was still available as a beta.<p>I remember being distinctly annoyed that the Java 1.1 broke the model introduced in Java 1.0, in which a JVM which had no Windows showing or Threads running would terminate automatically. When Java 1.1 was created, the event dispatcher thread was created (incorrectly, in my opinion) as a non-daemon thread, which meant as soon as you loaded the toolkit the JVM would never close until you hit System.exit. Here's the bug I proposed a fix with in November 1998:<p><a href="https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4030718" rel="nofollow">https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4030718</a><p>The shutdown hook never got fixed; these days there's convenience methods to add a shutdown hook to the (J)Frame so that on close it would call System.exit for you.<p>I've written a bit more about my history here if you're interested:<p><a href="https://alblue.bandlem.com/2021/01/java-1.0-turns-25.0.html" rel="nofollow">https://alblue.bandlem.com/2021/01/java-1.0-turns-25.0.html</a>
I was working in C++ when Java came out, and I remember my initial reactions:<p>1. Nice language, a relief after the complexity of C++, which was a complicated mess even in the early 90s.<p>2. GC! A great relief.<p>3. Completely bizarre memory model, due to the inability to physically embed one object inside another.<p>25 years later:<p>Language: My view of the language itself is lower than it used to be. This is not due to the current "objects are evil" fad, not due to the preposterous AbstractFactoryManagerFactory abstractions that are sometimes enforced, and not due getters/setters (don't use them if you don't want to, I don't).<p>No, I think there are two basic problems with the language itself. First, type erasure is just bad. It does simplify a number of things for implementation, but it leads to non-intuitive hacks required to get things right. Second, they got closures all wrong, basically limited to constant values so that the implementation can rely on copying. So many other languages get it right. (Have they fixed this? I haven't been an active Java user for a few years.)<p>GC: Still nice, but: GC performance is still an issue. This is undeniable -- Oracle is still experimenting with new GCs. Tuning is getting so arcane, that I think I might actually prefer the C model. Valgrind was not available when I was an active C++ developer. It makes C memory debugging so simple, and GC tuning is such a mess, that my preference for GC (at least in Java) has diminished.<p>If I had to rank memory management models, I think I'd go with 1) C + valgrind, 2) GC, and a very distant 3) Swift-style reference counting.<p>Memory model: The lack of physically embedded objects is still a miserable choice. I understand why they did it -- it makes object identity much more complicated. But it really does rob Java of some critical tools for improving performance. Project Valhalla (value types) seems to be perpetually several releases in the future.
In principle I like Java but there are a few minor details that just make it not worth dealing with it. Getters and setters are incredibly annoying. There are lots of crazy things going on in the JEE ecosystem. The latter is a big deal when you accept an average "Java job".<p>If you were to give it a small facelift I wouldn't have to worry about all the tiny flaws that add up. I don't really need Kotlin, Scala or dead JVM language x. Just a slightly better Java.
An Oracle marketing person reached out to me for some video clips talking about Java last Summer. One of the questions they asked is where do you see Java in 25 years? At that point in time, with a six month release cycle, the answer was Java 64. :)<p>I got on the Java roller coaster in the Java 1.1 days... so some 23 years since I wrote my first Applet that tied to the mainframe via RMI/CORBA. Java has really evolved. Seems there is a wide range of Java developers - those fluent with streams, lambdas and other features introduced in Java 8 - and those who don't even seem to know what Java 7 try with resources are. I suspect C++ and other languages that have been around for multiple decades see the same thing. Not sure if it is the starting education or just dated material.
I look at the history of Java as a case study in how original intentions don't play out. Hype, disillusionment, irony.<p>Hype: Java <i>"write once run anywhere"</i> JVM was super hyped as the "Microsoft killer". In reality, the forces that reduced MS's desktop power were Apple iPhone & Google Android. MS's server software influence was reduced by Linux/MySQL and by further by Amazon AWS running that open source stack.<p>Java was also predicted to be the "C++ killer" because all those wasted extra cpu cycles on fat desktops could be used for GC to make "manual memory management" obsolete. Java did succeed on the server (e.g. Ebay, Amazon, Google, all run a lot of Java on backend servers) but C++ today still has the spotlight for machine learning, games, desktop apps, etc.<p>Irony: Java was the "serious" language for browsers and Javascript the "toy" language. In reality, Java Applets died along with Adobe Flash and MS Silverlight and <i>Javascript</i> evolves by bottom-up popularity to code complex browser apps.<p>On the desktop side, it looks like a Javascript runtime (Electron, Deno) will have more deployment than a JVM-based runtime.<p>If I can be bold and apply learnings from Java's history to today's landscape... I don't think Julia will achieve massive popularity for math programming even though the language was designed for it and the evangelists predict it. Instead, Python usage will always be ahead in that domain. Julia needs an influential player like NVIDIA CUDA or Google Tensorflow to adopt Julia as a first-class API to change its future trajectory and it doesn't look like that will happen.<p>Similar counterintuitive history with the BASIC language. The "B.A." in "BASIC" stands for "Beginner All-purpose" but it turns out that Python became the more popular beginners language.<p>The eventual history doesn't always agree with original design intentions of the programming language.
I was really excited about Java back in the day. My friend and I back in the 1990's started working on a STEM website that would have made use of Java applets. The idea was to present algebra concepts with graphing applets where you could modify a formula for a parabola, and then see the results on-screen in real time. Like what you could do with a graphing calculator, but with a more explanatory text surrounding it.<p>I just took a look at the first page of google results for "learn algebra parabola" and found plenty of learning resources... but not a single one was interactive?<p>With all the fancy Javascript-heavy pages these days, has noone has done this sort of thing? I also took a look at Khan Academy, and they have some interactive stuff, a lot of it is just videos.
Java has amazing longevity. People have been writing articles about its demise, and yet, it is still here.<p>I have programmed in Java for a long, long time. Getters and setters, Maven and its vagaries, abundant use of patterns - all of these make sure people have strong opinions about it.<p>If any new person wants to learn Java, my two cents: Master generics and lambda. Do not learn, master them. Learn to write bullet-proof code using those two concepts, including proper exception handling. You will learn about a lot of things in Java, just by mastering those two concepts.
I started developing Java in my first job in 1998. On that workplace, some developers before me had evaluated some kind of Java framework called "San Francisco", if I remember it right, before I joined, but decided against it. If I remember it right, it was IBM that were behind that. Is someone familiar with it? Some pre-J2EE thing..?
I am not nostalgic for the old versions of Java. I learned on Java 3, when they designers were still saying, "yOu Don't nEEd typE paraMeterS BeCAusE yOu CAn cAsT tO Object!"
I remember the announcement, and being thrilled as I poured over the documentation and did some Java experiments.<p>I didn't really get into programming it for my job until 1.1.4 though, and I remember being skeptical about the language's future when they changed the versioning a year later to Java 2, 3, etc.<p>I continued with Java as my main language on the job until 2017. I should note that my coding for work became a mix of Android Dalvik Java and J2EE around 2009, and then focused on Android from 2013 to about 2016, with some Elixir and occasional J2EE work (Java 8). In 2016 my main language at work became C++, with some Rust.<p>Revisiting Java and learning modern Java (Java 13-16) is one of my goals for 2021. That's driven by commercial necessity though. That is second to laying the groundwork for a full time Rust job though. Rust is the language that fills my heart, through and through.
Maybe someone here knows with something I've been struggling with lately. In modern systems when running a java created binary, I find it runs much slower on a mac, then on a PC especially. Not sure, but I find the ui jitters and stalls (imagine running heavy app in a vm container) when there is a lot of data pulling from a remote site.<p>Is there a way to drive performance to the JVM, or shed light to what might be the cause? Thoughts to why a much older pc with less memory, worst memory card, seems to perform flawlessly.<p>Here to look for any other solutions I could try. I love to be working on the mac, but like to have the performance I find when running the java app (with ui elements) on a pc. Something that comes to mind at the moment is maybe trying here a remote desktop to a windows machine to see if performance is better than running natively on the mac.<p>Sorry in advanced for the slight vagueness on the specific app running and lack of specs provided.
Heh. I remember the Java 1.0 days. At work someone showed me Java and just running a "Hello World" took a few seconds to start. And complex code was sloooow.<p>I immediately concluded that no-one will ever use it and that's it's just a fad. (Just like I predicted there's no way to make money from a search engine :) ).<p>Things changed a lot with Java 1.3, which, for the first time, came with JIT compiler.<p>And with modern escape analysis, lock elision, new GCs, etc, I no longer (OK very rarely) look to C/C++ for performance anymore.<p>I still miss real pointers (better unsafe, et al), native types collections (there are external ones) and more control over what gets put on the stack vs. on the heap (escape analysis is not good enough, yet.) sometimes.
I'm like not that amazing of a programmer, but Java seems pretty legit.<p>It's a lot of cruft to pull together and manage to make stuff work. But once it does it's fast and the codebase is fairly easy to mentally model and absorb. Yeah the boilerplate stuff is kinda annoying but whatever.<p>Java with Akka adds the actor and some flow/functional stuff that seems to be useful for building a distributed and complex system that would be used in the future landscape of functional computing.
I remember when Java was first announced. I was in college. I read "The Java Language: A White Paper" and I was immediately excited. The benefits touted were:<p>- simple<p>- object-oriented<p>- distributed<p>- robust<p>- secure<p>- architecture-neutral<p>- portable<p>- interpreted<p>- high performance<p>- multithreaded<p>- dynamic<p>Quite a list! See the original paper here:<p><a href="https://tech-insider.org/java/research/acrobat/9503.pdf" rel="nofollow">https://tech-insider.org/java/research/acrobat/9503.pdf</a><p>I was one of the first students to do a project in Java (which I suggested myself).<p>Yes, at that time, Java was cool technology.
I learned a bit Java 1.1 in my young years, but never used it much later. I still think Java Applets, embedded Apps in websites was a great idea and much better than anything we have today. But it never happened, because they did not took security so serious and so it was dangerous and never became a thing, sadly.
JDK 1.1 still works on windows (and on linux via wine).<p><a href="https://www.oracle.com/java/technologies/java-archive-downloads-javase11-downloads.html" rel="nofollow">https://www.oracle.com/java/technologies/java-archive-downlo...</a><p>Everything I tested works flawlessly.
Does anyone remember the first Java IDEs? I know there was Visual Age for Java by IBM, but Sun had something, too. Was it called "Java Workshop" or something similar?
The only thing I wished Java had from the get-to is lexical scoping closure with a real function as first class.<p>These alone would have cut down so many boilerplate codes.
What is so insane to me is how Java was the one that came out when Sun had so many other things going on.<p>The Self language had all the tech, they had a full compiler team, a high performance implementation and could reasonably do everything Java could. So much that the same people ow did Self eventually end up working on the JVM as well.<p>And Java Script, end-up up itself being basically like Self in many ways.<p>Maybe the Self team focused to much on research and the Java team focused more on getting it out there.