Java Turns 30 (theregister.com) 53
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.
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 Post Brought To You By Java FirstPostBot 1.1 (Score:1)
Glad I made it first! Just finished starting the VM and loading all the class libraries!
Re: (Score:1)
Write once, runs everywhere painfully (Score:3)
Python is the real no-nonsense, no headache write-once-run-everywhere.
Re:Write once, runs everywhere painfully (Score:4, Insightful)
Re: (Score:3)
I'm talking cross-platform.
A Python v2 or v3 file will usually run equally well on Windows, Linux, whatever... in the same version of the interpreter.
Python does break stuff on a regular basis and create headaches because they still don't give a very big shit about backward compatibility. But my point is, whatever works or breaks on one platform with work or break more or less the same on another.
Java on the other hand is a complete crapshoot, depending on platform, which JVM and which version you use, whet
You're quite mistaken (Score:2)
I'm talking cross-platform.
A Python v2 or v3 file will usually run equally well on Windows, Linux, whatever... in the same version of the interpreter.
Python does break stuff on a regular basis and create headaches because they still don't give a very big shit about backward compatibility. But my point is, whatever works or breaks on one platform with work or break more or less the same on another.
Java on the other hand is a complete crapshoot, depending on platform, which JVM and which version you use, whether the moon was blue the night before...
I literally had the opposite experience. I've worked with Java for 25 years...never experienced a legit cross-platform issue (unless you're counting that you can't read C:\myfile.conf on Linux. I once had an issue in JUnit where I had a bug in my unit test that was exposed on Linux, but worked on Windows...but again...that was my fuckup....and JUnit specifically told me not to do what I was doing.
My first Python experiences were it working on MacOS, but breaking on Ubuntu, then fixing it on Ubuntu and t
Re: (Score:2)
I have had the opposite, especially with UI stuff. JVMs and different revs meant the difference between running, versus lots of vague exceptions thrown that had no real context, other than to "try another JVM". Ages ago, even Visual J# was better, because it would convert Java code into .NET IL, which worked well enough.
Java had a ton of promise. It would have been an awesome embedded language, back in the days of Jbuttons and iButtons. It even had CPUs being worked on to execute Java bytecode in hardwa
Re: (Score:1)
Why write nonsense posts like this?
A) it is simply not true
B) exceptions are never "vague". What the fuck is that claim? The exception tells you exactly where it happened and why it happened.
It would be nice for a write once, run anywhere language to come back, but this may not happen until some F500 company decides to make it and pushes it, which is highly unlikely as of now. there are several, Java for instance, FACEPALM, or C# even, JavaScript, SmallTalk (yes, it still exists), Nim, Elixir, Dart.
Java mea
Re: (Score:1)
Java on the other hand is a complete crapshoot, depending on platform, which JVM and which version you use,
That is nonsense.
It absolutely does not depend on platform.
It might depend on version, but that ha several easy fixes:
a) generate bytecode for old VMS - oops that is t easy right?
b) instal the proper Java version, and fix your PATH - wow that is also to easy?
Java is a compiled language: so obviously it has not the ease of Python or JavaScrip that are simply text.
Yes: dumbass, Python is text. Show me an
Re: (Score:3)
Good thing no one would ever do that.
Re: (Score:1)
Why would anyone do that when he simply can use LLVM and produce WebAssembly and ship that?
Wait ... that is an idea for a startup ...
Re: (Score:2)
What I have found is that the only sure way to know your code works on any platform is to write tests to ~100% coverage and then run said tests on the platform. See if they fail and see if you get the same level of coverage. You cannot claim 'runs on Y platform' when you do not try it yourself. Anyone who is building Python any version on new platform Y (like a new OS and CPU) and not passing the full test suite + not passing the test suites of the packages they install is just running on hope.
I maintain a
Re: Write once, runs everywhere painfully (Score:3, Insightful)
Re: Write once, runs everywhere painfully (Score:2)
Re: (Score:1)
It is not so easy to get it running on iOS or Android.
There are mostly only toy apps.
I think Juniper Notebooks run, though. Never tried it, have to do that.
Re: (Score:3)
There is not, and probably never will be, a no headache write-once-run-everywhere solution. Different OSs have different capabilities and ways of doing things.
If you're writing a library that doesn't have any user-interface, cross-platform is much easier. As long as you stick to the least common denominator APIs (e.g. POSIX), it won't be hard. But even file systems have their cross-platform quirks... such as case-sensitivity, directory separator characters (is it '/', '\' or ':'), allowed characters in a pa
Aimed where? (Score:2)
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)
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)
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.
Ah java! (Score:2)
Re: Ah java! (Score:1)
Productivity, right?
Re: Java sucks (Score:2)
respected...but not missed. (Score:4, Informative)
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)
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.
Re: (Score:2)
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)
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)
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.
Re: (Score:2)
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.
Re: (Score:1)
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.
Re: (Score:2)
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.
Re: (Score:2)
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)
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
Re: (Score:1)
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)
Re: (Score:1)
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
It's All About Concurrency (Score:2)
Write Once Run in any cloud!!!! (Score:3)
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.
Re: (Score:2)
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:3)
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
Re: (Score:1)
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.
Thirty years young! (Score:2)
I remember when it launched (Score:2)
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
Re: (Score:2)
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]
Re: (Score:1)
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.
Java: the Enterprise language (Score:1)
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
JVM Still Relevant (Score:2)
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
Re: (Score:1)
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
And, thanks to these 30 years, this could happen (Score:1)
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]
Java is the new Cobol (Score:2)