Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
Java Programming Software

Java Turns 30 (theregister.com) 100

Posted by BeauHD from the enterprise-never-looked-back dept.
Richard Speed writes via The Register: It was 30 years ago when the first public release of the Java programming language introduced the world to Write Once, Run Anywhere -- and showed devs something cuddlier than C and C++. Originally called "Oak," Java was designed in the early 1990s by James Gosling at Sun Microsystems. Initially aimed at digital devices, its focus soon shifted to another platform that was pretty new at the time -- the World Wide Web.

The language, which has some similarities to C and C++, usually compiles to a bytecode that can, in theory, run on any Java Virtual Machine (JVM). The intention was to allow programmers to Write Once Run Anywhere (WORA) although subtle differences in JVM implementations meant that dream didn't always play out in reality. This reporter once worked with a witty colleague who described the system as Write Once Test Everywhere, as yet another unexpected wrinkle in a JVM caused their application to behave unpredictably. However, the language soon became wildly popular, rapidly becoming the backbone of many enterprises. [...]

However, the platform's ubiquity has meant that alternatives exist to Oracle Java, and the language's popularity is undiminished by so-called "predatory licensing tactics." Over 30 years, Java has moved from an upstart new language to something enterprises have come to depend on. Yes, it may not have the shiny baubles demanded by the AI applications of today, but it continues to be the foundation for much of today's modern software development. A thriving ecosystem and a vast community of enthusiasts mean that Java remains more than relevant as it heads into its fourth decade.
This discussion has been archived. No new comments can be posted.

Java Turns 30 More

Java Turns 30

Comments Filter:

  • This Post Brought To You By Java FirstPostBot 1.1 (Score:2, Informative)

    by Anonymous Coward

    Glad I made it first! Just finished starting the VM and loading all the class libraries!

  • Aimed where? (Score:3)

    by Entrope ( 68843 ) on Friday May 23, 2025 @06:11PM (#65400073) Homepage

    Initially aimed at digital devices, its focus soon shifted to [...]

    Well, I guess in theory it's helpful to know that it wasn't originally aimed at analog computers, die presses, lawnmowers, and so forth.

    • Re: (Score:2)

      by Jeremi ( 14640 )

      Well, I guess in theory it's helpful to know that it wasn't originally aimed at analog computers, die presses, lawnmowers, and so forth.

      Back in the mid-90's, the Hot New Thing was the "set-top box", a.k.a. a little dedicated box that would sit on top of your TV set and let it stream content from the Internet. That's the "digital device" that the Java developers were targeting (as opposed to traditional computers with a mouse and keyboard attached to them) -- today we'd call that "embedded hardware", or maybe just "Roku".

      • Re: (Score:2)

        by Entrope ( 68843 )

        Yes, I remember the original hype about where it was targeted, but saying a programming language is targeted at "digital devices" is just unclear, lazy writing. "Interactive TV" (as Wikipedia puts it) would be more precise.

  • I really wanted to love it. I wrote a great application for it, that almost worked perfectly. There was a single bug I couldn't get past and eventually had to debug the Java code itself before I found the issue, and it was an easy fix! Thats pretty amazing that a hack like me could fix a programming language bug. But my boss wasn't so keen on running a solution on a hacked up tomcat server... Se la vie

  • Java, and more so J2EE, just sucks the brains out.

    Case in point, outside of Apache projects and JBoss (which try to implement J2EE standards as free things to avoid buying IBM's proprietary packages that implement the "standards" that IBM intentionally shoved into the standard in order to get people to buy IBM's "solutions"), who codes in Java open source anymore?

    Back in the plain Java/Swing days, yeah, and I really loved being in THAT version of MVC and was really closing to writing a book for it...

    but when IBM took over J2EE web dev architecture and that became the 'norm'? f' it. I had no brains left, every cell was being used to just get my work code to work.

    and that didn't change, for me, or for anybody else. Outside of the Apache/JBoss services there was no open source community, no 'hacking', no...anything. because just doing the job sucked your brains out. I once had to explain, as I was leaving my prior company in 2010, that any "feature" they asked for required me, on a "full-stack", to mentally think and write in 12 different languages, once you realized that each XML configuration was really a different language from any other.

    There's reasons the react, node, and general JS "stack" has so many packages and components available to it...it is because the typescript/javascript realm doesn't suck your brains out.

    Yeah, it got me through 15 years of my 30 year career...but I'll never miss it.

    • Re: (Score:2)

      by Tatsh ( 893946 )

      At least it wasn't PHP.

      And with regards to the JS "stack", the reason it has millions of packages is because the standard library (Node or ECMAScript and/or the DOM in web browsers) is small and terrible. This is a bad thing.

    • Totally agree, except I don't respect Java. I had to use it for many years, a miserable language to work with. I always felt like it was fighting me, you write code with one hand tied behind your back. I realize a lot of people love it for some reason, but that ain't me.

      And these application environments like JBoss (now defunct) truly did suck. It is Node/JavaScript and Python for me now all the way.

  • Nonsense (Score:4, Insightful)

    by phantomfive ( 622387 ) on Friday May 23, 2025 @06:54PM (#65400143) Journal

    Yes, it may not have the shiny baubles demanded by the AI applications of today,

    That is nonsense. The AI "baubles" have nothing to do with the language itself, that's all about the libraries.

    In general, people don't choose languages these days because of features of the language. They choose languages because of availability of libraries.

  • The idealogical language (Score:3)

    by Tony Isaac ( 1301187 ) on Friday May 23, 2025 @07:07PM (#65400177) Homepage

    Java is an example of what you get when you take ideology to its ultimate conclusion. For example, requiring that a function specify which checked exceptions can be thrown, and requiring that any caller must handle those exceptions, is an example of a good practice that goes too far, resulting in code full of litter that distracts from what the code is actually trying to do.

    I prefer more pragmatic languages, that "suggest" good practices, but don't necessarily force them. As counterintuitive as that may seem, I want to be in control of how well I write my code. Sometimes quick-and-dirty is just the right approach, sometimes handling every known possibility is the best approach. I don't want the language to tell me that I must always do the latter.

    • Java is painfully wordy with picky syntax. Frequently is very tedious to debug in my experience. The threading implementation is dreadful. Not event-driven without a lot of hassle, which means slow. I've been paid a lot of money to code with it but always disliked it.

      • Java has no "thread implementation".

        It has _threads_ just like C/C++ and any other language with a thread library.

        Perhaps you want to read up the new (cough cough) concurrency packages in Java, they solve your not-event-driven, quite nicely.

        • I assume you mean the java.util.concurrent package? Hugely complicated, a PITA to work with. So many things in Java are like this.

          • It is only complicated if you do not know how fundamentally complicated concurrency is.

            • I work with Node, which is fundamentally concurrent and event-driven. All I/O is non-blocking by default. You have to jump through a lot of hoops to get that with Java.

              • Well....I dunnot how to tell you this....but Node is /not/ multithreaded and not even really concurrent. It is, however, event-driven and mostly non-blocking by default ( arfff promise.....). In a certain way, the concurrency model of node is similar to the GIL of python in how it serializes the events.

                • I didn't say Node is multithreaded. It can run concurrently on each CPU core and you can spawn as many workers as you want;
                  https://nodejs.org/api/cluster... [nodejs.org]
                  https://betterstack.com/commun... [betterstack.com]

                  • Are there really software that can't run concurrently on different cores? I mean, unless explicitly forbidden because it uses a local ressource or some other reason. Stuff like PM2 is a crutch. It's great if you are doing web requests, not so much for heavy calculation outside the main thread.

                    • >> Are there really software that can't run concurrently on different cores?

                      The claim was that Node is "not even really concurrent", but it is with just a few lines of code. Other languages, much more complicated in my opinion.

                      >> not so much for heavy calculation outside the main thread

                      Event-driven isn't very helpful if you are doing heavy calculation I agree. I use Python for anything related to data science. But an awful lot of software consists of the browser as a user interface and a back en

    • Linters and other tools to analyze code have taken over this role. Back when Java came out the only option was baking it into the language itself, which I agree is too rigid.

      • I don't use lint or its cousins for the same reason that I don't like Java. These tools tend to spit out so many garbage warnings that you can't really tell what's important.

    • Re: (Score:2)

      by Jeremi ( 14640 )

      For example, requiring that a function specify which checked exceptions can be thrown, and requiring that any caller must handle those exceptions, is an example of a good practice that goes too far, resulting in code full of litter that distracts from what the code is actually trying to do.

      OTOH one of the things I dislike most about exceptions in C++ (to the extent that I simply avoid using them whenever possible) is that there is no way to determine what exceptions might be thrown from any given function you might want to call, and therefore no way to determine if your code will handle all exceptions correctly when it runs. Your options are either to manually grovel through every line of code in all of your codebases and their dependencies, or just catch(...) somewhere and hope for the best

      • Java has two kinds of exceptions:
        - checked exceptions, which each method has to declare that it is throwing them or allowing them to escape if some other called method throws them
        - unchecked exceptions, which are not declared at the method signature

        You use / handle the first one to interact with the OS and the outside world, there is no point in continue running your program if you can not handle a "FileNotFoundException" or "NoSuchHostException".

        If you do not know "oh an exception might coming" where in yo

      • Re: (Score:2)

        by gwjgwj ( 727408 )
        It was possible to specify exceptions thrown by a particular function in C++, but it has been deprecated in C++17.

      • In general, when an exception is thrown, there's just one appropriate response required, regardless of what the specific exception is: display an error and fail. Occasionally, there's a case where you want to do something different with *one* specific exception, such as maybe a timeout or a file not found error. In that case in C++ or C#, you can catch the specific "special" exception and then add a catch all. But usually, just a catch all is enough, it's rare to need to perform special handling for each po

      • Perfect summary. Imperfect implementation which solves a problem C++ leaves as impossible to solve, making C++ codebases awful at runtime, and Java harder to live with at compile time.

    • For example, requiring that a function specify which checked exceptions can be thrown, and requiring that any caller must handle those exceptions, is an example of a good practice that goes too far, resulting in code full of litter that distracts from what the code is actually trying to do.
      That is the same in many many other languages.

      And: no one forces you to use checked exceptions, you can use unchecked ones.

      And if you do not like to handle the Checked Exceptions of the OS level layer classes like java.i

      • No one forces you to use checked exceptions, you can use unchecked ones

        That's true as long as you wrote the code throwing the exception. If it's thrown by a library you didn't write and don't want to maintain, you're stuck.

        you can convert them into unchecked ones and be done with it

        So you're proposing as a solution, modifying the code in java.io? That adds a whole layer of complexity to managing your code. I use libraries or runtimes because I don't *want* to maintain that code. Once you start tweaking the library, it's a never-ending nightmare. Every time the library gets updated, now you have to reapply your changes. Or if you go the

        • > Why should I write setter methods Donâ(TM)t all the IDEs automate this stuff?

          • IDE-written code still has to be maintained, by you. And when debugging, the more code you have to step through, the longer it takes and the more complex the process, whether the IDE wrote the code, or you did. My contention is that getter and setter methods serve no useful purpose, in cases where you don't need additional logic. You might as well insist on requiring a function be written to get or set any local variable too. Why would you do that?

        • Well,
          my main point is that it is not the *language* but the way it is used.
          The library designers decided to have *hard* exceptions for everything that is a serious problem.

          C# did the opposite, and it is a mess to do system programming in it. Write a plug in for Visual Studio. Suddenly the IDE crashes because some core library threw an undocumented (unchecked) exception, your plugin crashes. And - no idea how it is now - instead of crashing the plugin, reloading it, or disabling it: the whole IDE goes puff.

          • The library designers decided to have *hard* exceptions for everything that is a serious problem.

            You mean, like the designers of the java.io library? It throws checked exceptions _everywhere_.

            C# did the opposite, and it is a mess to do system programming in it.

            C# isn't designed to do system programming. Nor is Java. C or C++ or Rust are better tools for that job.

            Suddenly the IDE crashes because some core library threw an undocumented (unchecked) exception

            VS plugins that crash, down usually take the IDE with it.

            You're right about getters and setters, my mistake.

            However, your assessment of async/await is incorrect. C# uses actual threads to implement these background tasks, threads that are maintained in a thread pool. https://dotnetfullstackdev.med... [medium.com]

            Yes, I under

            • Message means: method call.

              However, your assessment of async/await is incorrect. no, it is correct. As it is explained in your link.
              Doing an await creates a helper object, that is put into a task queue that is worked on by a thread pool.

              That is exactly what I wrote ....

              You do not do any multi threading with async/await. ... you have absolutely no control about any thread involved.

              Java is excellent for system level programming. That is why everyone is using it: because the close to the hardware libraries thr

              • However the keyword clearly indicates what it is: asynchron.
                In other words: it has nothing to do with "multithreading"

                This is incorrect. Just because the threads are in a thread pool, doesn't make it "nothing to do with multithreading." The threads are real threads, they're just not started by _you_. It's not some sort of "message queue" like the old days of Windows 3.1, when the only kind of threading was really just a message pump, which required each worker to periodically call Yield() in order to let a different task have some time. These are real OS-level threads.

                You do not do any multi threading with async/await. ... you have absolutely no control about any thread involved.

                This also is incorrect. The background task does indeed

                • The point is that YOU are not doing multi threaded programing.
                  You are using language features and a threat pool that is already there.
                  No idea why you are nitpicking :P

                  Classical Java exposes how to do multi threading with the synchronize/d keywords and the implementation of monitors in the VM.

                  That is of course not straight forward - even for advanced programmers.

                  In Kotlin the compiler is generation monitors and locked sections for you. In Java some clever guy wrote helper libraries, but they did not add asyn

                • This also is incorrect. The background task does indeed run on a different thread than the caller. How is that not multithreading?
                  The machine is running multiple threads. And in general: a predefined amount.
                  You are using them, but you are not programming them, creating them or what ever.
                  In general: the programmer has no idea what exactly is going on under the hood (which is not a bad thing), except that he says: "I do multi threading".

                  One is basically firing dumb task objects into a queue, delegating proble

                  • Your argument is like saying that if you're not using assembly language, you're not really programming. That's silly. Higher level languages hide the complexity of machine code, and let programmers work in a way that is more friendly to humans. It's still programming. I don't have to roll my own machine code, to be doing real programming.

                    What you said was, that async/await has nothing to do with threading. That, my friend, is false. No, you don't have to manage the threads, but that is not the standard. Why

    • Checked Exceptions are every bit as painful as you state. But they are also sensible coming from the Java âoefill the holes in C++â thinking patterns. What gets raised where is nearly impossible to determine statically since any function called at any level can raise anything. And so either you solve that problem the Java way and create a nasty nasty mess that requires your IDE to help you code your way out of it, or you ignore the problem and let the IDE simply detect what can be raised, so

      • In most cases, there is only one thing to do when there is an exception: display a message or log it, and fail. It's almost never necessary to separately handle each type of exception.

        In many use cases, what you really want is for the exception to bubble up. A RabbitMQ (or other microservice) worker is an example. Anything that throws an exception, should generally just bubble up to the top, get logged, and the task fails. Java doesn't make this easy to do.

        Some of the other over-engineered things include re

    • Java sucks for small projects because of all the mandatory rituals and ceremonies, but it works great for large projects where different teams who will never meet have to interact only through code. I would even say that Java is great as the sys admin that has to run the big convoluted pile of crap because when something goes wrong, it's usually going to be obvious once you scroll through the backtrace logged with the terminal exception. Much better than software that logs only a null string when it fails.

      • I'd argue that in both scenarios (the log that just has a null string, and the log with a clear call stack and error details) it's up to the developer to decide what to send to the log. Other languages, like C++ and C#, are capable, with trivial effort, to generate great logs when there is a problem. And it's not necessary to catch each type of checked exception, just catch the generic exception, even at the top of the stack, and tell it to log the error details.

        In many types of applications, such as micros

  • The interesting thing about Java to me is that its main purpose when it was created is now one of its most mundane features. The fact that Java can run on every major platform is good for development, but in production it mostly just runs on Linux. The far more interesting feature for Java nowadays is the way it handles concurrency via EJBs. I'm still not aware of any platform that makes multithreaded programming as easy as Java and I don't understand why more languages haven't created concurrency framew

    • Write Once Run in any cloud!!!! (Score:4, Insightful)

      by Somervillain ( 4719341 ) on Friday May 23, 2025 @08:44PM (#65400365)

      The interesting thing about Java to me is that its main purpose when it was created is now one of its most mundane features. The fact that Java can run on every major platform is good for development, but in production it mostly just runs on Linux. The far more interesting feature for Java nowadays is the way it handles concurrency via EJBs. I'm still not aware of any platform that makes multithreaded programming as easy as Java and I don't understand why more languages haven't created concurrency frameworks with a similar level of simplicity. I realize that having a VM probably enables many of these features, but it's still possible to implement those features for other languages with a bit of extra effort.

      Nope, still VERY valuable...you can compile on Ubuntu, any kernel, and your jar will run perfectly on any cloud platform. You're correct we all run Linux now, but what Linux? what processor? what cloud platform? The write once run anywhere is more valuable today than when everyone wrote code on Windows and deployed on UNIX/Linux. I didn't see it coming either, but very glad it's here and we're not having to recompile for each server environment.

      • Nope, still VERY valuable...you can compile on Ubuntu, any kernel, and your jar will run perfectly on any cloud platform. You're correct we all run Linux now, but what Linux? what processor? what cloud platform?

        Containers provide all of that functionality, with the only major exception being the distinction between ARM and x86_64 processors.

        • How many 25yo containers do you use? (Score:5, Interesting)

          by Somervillain ( 4719341 ) on Saturday May 24, 2025 @01:52AM (#65400803)

          Nope, still VERY valuable...you can compile on Ubuntu, any kernel, and your jar will run perfectly on any cloud platform. You're correct we all run Linux now, but what Linux? what processor? what cloud platform?

          Containers provide all of that functionality, with the only major exception being the distinction between ARM and x86_64 processors.

          I have 25yo jars in my classpath...that run better than they did 25 years ago. They were compiled on Solaris by the Sun corporation or Apache and used in Windows, Linux. Yes, containers alleviate some of this, but how often do you rebuild containers?

          Also, Java was doing most of what Docker was doing long before Docker came around. Docker is an upgrade, but not a revolutionary one. It's like going from a late model blackberry to a first generation android....an upgrade, but all the core functionality you had before.

          In fact, everything we do in Kubernetes today, I was doing in JBoss long before...rolling deployments, multiple version deployments, etc. But, in fairness, most JBoss users weren't as advanced as my previous employer. I'm not saying I want to go back. I concede that Docker/K8 is better...it's just like if you forced me to downgrade to ios or android from 5 years ago...I am not really sure I would be losing out on anything too vital.

          However, the point remains is that Java is very portable and that's very useful. It's also very fast. It's also very easy to use. It also has great libs. It also has probably the world's biggest talent base. It's a great platform...the portability isn't of appeal to you?...well, it's faster than every business language platform around today...the only way you're going to get it any faster is in rust or native code. It's MASSIVELY faster than node.js or python, it's 2 main competitors. It's also a LOT faster than Go...which rust makes look like a steaming pile of dogshit. It's a great platform that's taken for granted by most, but having used all of it's competitors, it's far superior.

        • Containers fix a problem with Python runtime distribution. We didn't need them for Java apps.

    • Actually using multi threading is not super easy, but it is via EJBs for example, hidden from mundane programmers.
      You have multi threading in the back ground without even knowing it.
      And thread/concurrency libraries if you seriously want to do it your own.

      Other languages with nice and simple multi threading are Dart and Elixir.

  • Well done Java.

  • I was running OS/2 on a PC hoping that the promise of Write Once Run Anywhere meant we didn't all have to run Windows 98 on our PCs. I remember Lotus wrote an entire Java version of their SmartSuite that had the potential to replace Microsoft Office. Too bad Java was so dogshit slow, launching the Java Lotus Word Pro took ages, hard drive thrashing like a blender until you forgot why you clicked on it and what you wanted to write.

    The promises of those slim network clients that were Java workstations just

    • If you just looked on Wikipedia for it you won't find it, but it did exist: https://www.cnet.com/tech/tech... [cnet.com]

    • That was Lotus' fault and still is.
      Has not much to do with Java itself.

      I guess most of it are wrong configurations. I used Lotus on AIX and it was lightning fast. We did our Y2K reenginering audits with it. I mean: the paperwork. All super nice.

      Then I encountered a few companies that use it as "we organize everything with it", that always was super slow. Sometimes minutes until a window opened.

      • That was Lotus' fault and still is.
        Has not much to do with Java itself.

        Java WAS dog shit slow prior to 1.4 (Project Mustang), and was practically unusable. However, 1.4 DRAMATICALLY improved performance in general, and Swing was introduced to replace AWT. That turned Java into my platform of choice for business desktop software. I can develop on Linux or Windows, and run my programs on Linux, Windows, and (I presume) Mac with the same JAR.

        The worst Java nightmare I have ever experienced was trying to use it for Web development. It absolutely sucks for that purpose, and I won't

        • Java never was slow.

          Download of an App via internet was slow.

          The slowest Java implementations without Jit were about 10 times slower as C.

          And: a normal user never sees that difference.

          The worst Java nightmare I have ever experienced was trying to use it for Web development. It absolutely sucks for that purpose, and I won't touch it with a ten foot pole.
          It actually shines for that purpose. But it might depend on what library or parts of the language you are using.

          There was a Job posting n Linkedin lately. Th

  • Java was one of my first programming languages. Nowadays if I need to interact with it is is in a enterprise application with all of the odd architecture decisions that make it hard to understand and impossible to edit with vim.

    Most of my work is in lambdas nowdays. I'm working on making a framework in Japan for Japanese companies. Does anyone remember how long it took to load a Java applet in the 90's on a older computer? Its like dejavu with AWS lambda.

    Most of my work is converting these to typescript

  • For a time, Java was the main language I used (for enterprise and web application development). Today the main language is probably Javascript, but I also use Swift, Kotlin, and C# (which strikes me as slightly improved Java) a lot. And I occasionally need to do something in C or C++, and I work in some F# development when I can (I like it best out of the ".NET" languages). I don't miss Java, but I don't mind other languages on top of the JVM. For example, I think Kotlin and Clojure are both excellent, and

    • You might want to look into Dart (the language) and Flutter (GUI framework).
      Syntax more or less like Java/C# but simpler getter/setter, more object oriented (everything is an object, with clever NAN encoding pretty fast, too), cross platform:
      - web site or PWA
      - iOS, Android, Fuxchsia
      - Windows, Linux, macOS (command line and GUI)

      Can run from command line as "text" or precompiled.

      Pretty big eco system, despite that it seems it gets not "to much" attention "in news".

      Some code might even be copy/paste compatible

  • Enjoy it; it’s absolutely fantastic:

    HelloWorld.java, by Nanowar of Steel: https://youtu.be/yup8gIXxWDU [youtu.be]

    Source code: https://github.com/NanowarOfSt... [github.com]

    • That was absolutely hilarious. No spoilers but the end had me in stitches. The prefect sound for that I feel.

      Also not sure what I was expecting, but noticed it's from a legit record label (who I know from Gloryhammer).

    • That was absolutely great! Especially the very end (as already mentioned).

  • Java is the new Cobol (Score:3)

    by simlox ( 6576120 ) on Saturday May 24, 2025 @03:37AM (#65400899)
    At least here in Denmark, C# takes all new projects, where Java could have been used. Java and derivatives are for existing projects. A good explanation is that our engineering schools teaches C# as main language.

    • Re: (Score:2)

      by Tablizer ( 95088 )

      C# and Java are not that much different.

      Things I like about C#: optional named parameters (love those things!) and set/get shortcut syntax.

      Things I like about Java: the libraries didn't get caught up in the "async" bloat like C# did.

      There's probably more that don't come to mind yet.

  • It must have some great appeal, somehow, to somebody, but it's never clicked with me.

    It does seem to be the language of choice for code monkey organizations; those who have huge teams with like one guy working on each function or something. That's just a casual observation based on not much though.

  • I had to use Java in a few places and I got to understand why it is loved so much by hiring managers and bean counters.
    The very authors of Java called it "C++ --". They took C++ and cut off the sources of 90% of the bugs encountered in C++ (pointers and operator overloading), added garbage collection, effectively baby-proofing the language.
    This lead to non-crashing code being written by really bad programmers that are cheap to hire. The trouble is that the pointy-haired bosses of the programming industry be

Slashdot Top Deals

Your program is sick! Shoot it and put it out of its memory.

Close