Java Turns 30 (theregister.com) 100
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:2, Informative)
Glad I made it first! Just finished starting the VM and loading all the class libraries!
Re:This Post Brought To You By Java FirstPostBot 1 (Score:1)
Please don't feed the sock puppets (Score:2)
The way you propagated the sub-vacuous Subject.
Lousy FPs are somewhere on the list of problems Slashdot will never fix. Blame the broken business model?
Write once, runs everywhere painfully (Score:-1, Offtopic)
Python is the real no-nonsense, no headache write-once-run-everywhere.
Re:Write once, runs everywhere painfully (Score:5, Insightful)
Re:Write once, runs everywhere painfully (Score:2, Interesting)
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...
You're quite mistaken (Score:5, Insightful)
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 then it breaks on Fedora. Granted that was a long time ago, it seems to have gotten better.
Sorry, across Windows, Linux, MacOS, and even sometimes Solaris way back in the day....never an issue with Java. Never saw a cross-platform issue at any job site, ranging from tiny apps to massive, massive ones. Also, Java is a LOT LOT LOT faster than Python and far more efficient...but hey, if you like huge cloud bills...use Python! My bigger concern with Python is the lack of a compiler means you better write really really good unit tests or your customers will find your mistakes 5 years down the road when you hand off your app to another team.
But hey...you write PERFECT unit tests, right?...requirements rarely change?....so....shouldn't be a problem, right???
Re:You're quite mistaken (Score:4, Interesting)
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 hardware. However, it fell out of favor, eroded by Flash, HTML5, and many other things.
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.
Re:You're quite mistaken (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 means: you have a single jar file, which runs everywhere, Python means, you distribute it in source, other languages require you to build for each target platform, but that is usually not a problem.
CPUs for Java Byte Code still exist. However the operation model of primitive opcodes on a stack is not super efficient, so the big iron Java CPUs have a cross compiler for VLIW and/or SIMD instructions. Either in the loader of the OS or in the CPU itself.
Ages ago, even Visual J# was better, because it would convert Java code into .NET IL, which worked well enough.
That is utter nonsense. Who the fuck cares what kind of byte code it is?
Re:You're quite mistaken (Score:0)
Are you doing anything other than flaming in your stream-of-consciousness, mindless rant? Yes you know a few tidbits about bytecode, but you sound like the full-stack devs I worked with, who got all laid off. For people that actually code, sometimes exceptions don't give any help whatsoever, or you get code that runs and terminates with an error 0, so you have to step by step it, and find out it works great on Oracle's JVM, but not another. This is something that any experienced Java coder learns, and why companies set a standard on a JVM/JDK.
But, keep it up. I'm guessing that there is a school of thought that trolling other people will make you a better programmer, and a god amongst men, just like yelling obscenities into your mic when your team loses on Call of Duty will make everyone a better gamer. Keep up the insults and flames, that will make you a winner, yes, really it will.
Re: You're quite mistaken (Score:2)
"Try another JVM"???
If the application was built for Java 1.8 then you install a 1.8 JVM, it's really simple. The byte code is literally marked with the version in the first few bytes, you can cat the class file and figure it out ffs. You don't randomly mix runtime versions, not with JVM, not with glibc on Linux, not with visual c++ runtime for windows, not ever. This is as asinine as grabbing random glibc builds from other distros and hoping one works with your binary. More power to the brave jr sysadmin that wants to try, live and learn lol, but no... this is just not done.
Write once run anywhere refers to writing your code once, targeting Java 1.8 for example, and deploying it on all of Linux x86, Linux ARM, Linux PPC, Windows x64, Windows IA64 each with a Java 1.8 runtime installed. It works. It's not rocket science.
Re:You're quite mistaken (Score:2)
Pretty much exactly what you wrote is my experience.
Mainly server side stuff, java has been rock solid for me.
Re:You're quite mistaken (Score:0)
Re:You're quite mistaken (Score:2)
My bigger concern with Python is the lack of a compiler means you better write really really good unit tests or your customers will find your mistakes 5 years down the road when you hand off your app to another team.
In capitalism, the whole point of most products or services is to last just long enough to get paid enough to no longer care about what happens. As you can just find another sucker and repeat the cycle again,
A fictional character said it best,
Have you ever used Sabre electronics Jim? They're cheap, they're unintuitive. The Sabre store would work if we adopted the carnival model of leaving town once everyone is wise to us.
Re:Write once, runs everywhere painfully (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 any Java Source file that is compiler dependent ... for that you need to know a little bit about Java, which you obviously don't. Yes, you will find some ... that don't compile on very old compilers ... same as Python 3 does not run under a Python 2 interpreter: if you use features that are not available.
Stupid haters.
When in rel life did you ever had a Java program that did not run out of the box on your computer? Never ...
I had that problem once, as a stupid vendor did not provide Mac packaged versions of a product. So I took the linux version, which required a certain Java Version which "officialy" did not exist for Macs. So, I installed a 3rd party Java VM, wrote a 2 line shell script to set the PATH, the CLASSPATH and execute the VM, with the JAR file. Trivial Absolutely completely trivial. If you have any other problem with Java: then something is seriously wrong and you should figure what it is.
Re:Write once, runs everywhere painfully (Score:2)
That isn't to say Java is faultless because tweaking heap and GC can be a pain in the ass and the language itself feels its age especially compared to more modern languages.
Re:Write once, runs everywhere painfully (Score:-1)
Re: Write once, runs everywhere painfully (Score:2)
Everyone starts thinking that. It is intuitively ugly, but it's practically great. Python demands the indentation you should be doing anyway.
Re: Write once, runs everywhere painfully (Score:1)
Curly braces can be modified quickly (say to place a block of code into a condutional branch, just insert if(){ on one line and } on the other) and then indented automatically for readability. Not so with python.
Re:Write once, runs everywhere painfully (Score:2)
Re:Write once, runs everywhere painfully (Score:2)
You mean the one you could complete with a single command, 2to3 ?
Re:Write once, runs everywhere painfully (Score:4, Insightful)
Good thing no one would ever do that.
Re:Write once, runs everywhere painfully (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:Write once, runs everywhere painfully (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 lot of Python packages on Gentoo and MacPorts. Especially on Gentoo we always try to make sure Python packages pass their test suites when installed.
Re: Write once, runs everywhere painfully (Score:5, Insightful)
Re: Write once, runs everywhere painfully (Score:2)
Re: Write once, runs everywhere painfully (Score:0)
Not once have I seen perl used in an embedded environment. Never even heard of anyone doing this. Mainly because it's an incredibly slow interpreted language. I think you're full of beans.
Re: Write once, runs everywhere painfully (Score:2)
Re:Write once, runs everywhere painfully (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:Write once, runs everywhere painfully (Score:3, Interesting)
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 pathname, ... if there is a '?' in one of your file names, you have a cross-platform bug. On a Mac, you can have a '/' in a filename. Does your code handle this correctly or somewhere (possibly deeply buried in a library) make an assumption that '/' is the directly separator? If you have 'foo.jpg' and 'Foo.jpg', you have a bug. You have to test on all the possible target file systems to see if your code has a problem.
If you have any sort of user-interface, unit tests don't really help a lot (for the display code). Even HTML isn't 100% compatible between Chrome, Firefox and Safari, so you have to test on each platform (and each version you wish to support). But of course, nobody today does that - it is just too costly.
A desktop application has even harder problems. To be widely accepted by users, the program has to behave like a native application. "Look and feel" is important. The best a totally cross-platform toolkit can do is choose a least common denominator approach. This is what Java did, what Electron does - the UIs are often terrible because of this need to only use the least common denominator. I personally HATE using pgAdmin 4 on Windows... it just doesn't work like other Windows applications (I go back to pgAdmin 3 when possible, though that is a lost cause). Postman is also irritating. SOAP UI (a Java application) always feels clunky and the windowing just doesn't work right. I understand why developers choose this sort of thing (it is a lot less effort), but in the end the user experience is much degraded.
Aimed where? (Score:3)
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:Aimed where? (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:Aimed where? (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:Ah java! (Score:2)
In case in you care: C'est la vie.
Ce est, c'est. It is, it's.
Java sucks (Score:0, Flamebait)
I mean wtf is it good for? It's a piece of shit.
Re: Java sucks (Score:2)
Re: Java sucks (Score:1)
Ok ya got me there. Billions of dollars wasted, entire careers wasted, and global productivity blown, but hey it annoyed me. That's a win. That makes it worth it.
respected...but not missed. (Score:5, Interesting)
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:respected...but not missed. (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:respected...but not missed. (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.
Re:respected...but not missed. (Score:0)
You don't nee j2ee, just java itself and a jdk/jvm does the job just fine, this entire crazy stack nonsense, including Spring is garbage not worth using for any purpose where you need clarity, curtness, ease of implementation *and* debugging and maintaining the code. You don't need XML inside your application, it was something forced upon people for the same reasons people later started trading NFTs - the mentality of the sheep, where those, who are selling the idea make all of the money and the rest end up suffering and bleeding.
Java is used by the enterprise, enterprise buys into grandiose promises sold by snake oil salesmen sent by the likes of SAP, Oracle, IBM, Microsoft, Salesforce, Amazon, Adobe, VMWare, etc.etc. these guys know how to take enterprise money and you cannot really fight them once they are done with you, likely they have more money than you do. Everyone's service becomes shittier and for stupid reasons out of all of the things that could be blamed, a computer language takes a huge brunt... silly. I like Java for what it is - a great language to code server side business systems.
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:The idealogical language (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:The idealogical language (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:The idealogical language (Score:2)
I assume you mean the java.util.concurrent package? Hugely complicated, a PITA to work with. So many things in Java are like this.
Re:The idealogical language (Score:2)
It is only complicated if you do not know how fundamentally complicated concurrency is.
Re:The idealogical language (Score:2)
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.
Re:The idealogical language (Score:2)
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.
Re:The idealogical language (Score:2)
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]
Re:The idealogical language (Score:2)
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.
Re:The idealogical language (Score:2)
>> 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 end that hits a database. Node is very well suited for that.
Re:The idealogical language (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:The idealogical language (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:The idealogical language (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 -- neither of which is satisfactory for code where correct error-handling is important.
That's the problem that Java tried to solve, and I don't think they were successful, but I understand the motivation.
Re:The idealogical language (Score:2)
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 your code do you want to place the "oh I have to give up, that except came out of nowhere and I have no idea what to do now" code?
Handle the CheckedExceptions as you need, and use unchecked ones if you think "that is better".
C++ has checked exceptions, too.
I fucking have no idea why people call themselves programmers when they do not even grasp the simple concept of exceptions and how to use them correctly.
Re:The idealogical language (Score:2)
Re:The idealogical language (Score:2)
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 possible exception.
Re: The idealogical language (Score:1)
Re:The idealogical language (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.io.* you can convert them into unchecked ones and be done with it ....
Lucky that you are not on my team ...
If you want to write "quick and dirty" in Java, why not use Groovy? It automatically converts all checked exceptions into unchecked once where appropriated, and gives you the freedom to write code that looks exactly like Java, or very groovishish ...
Re:The idealogical language (Score:2)
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 route of creating wrappers, you still have a whole lot of code to write, that you shouldn't have to write...and test.
So, quick-and-dirty is one use case for not catching exceptions. Another is using a bubble-up strategy. Very often, when an exception happens low down in your stack, the middle layers don't care and don't know how to handle exceptions, that happens at the top. For example, a RabbitMQ worker often just succeeds or fails. A single catch all at the very top is sufficient. "It failed. Here's why. Log the error and go on."
Exception handling is just one of many things about Java that I don't like. It's way too verbose overall. Languages like C# and C++ are more concise. Why should I have to write a setter and a getter method, if all I want is a "dumb" property?
Also, Java requires a lot of boilerplate code for tasks like multithreading. By contrast, C# just requires prefixing a function with the keyword "async" and (if you want to wait for the result) prefix the function call with "await". I like that kind of coding efficiency.
Re: The idealogical language (Score:1)
Re: The idealogical language (Score:2)
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?
Re:The idealogical language (Score:2)
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. Sometimes without any trace or message or whatever: boinig! Was there not a window with some programming langauge text a split second ago? I could bet I worked the last 4h on some code, and was not daydreaming!
Why should I have to write a setter and a getter method, if all I want is a "dumb" property?
Then you just use a dumb property. No idea what your point is.
Package level access or public.
Also, Java requires a lot of boilerplate code for tasks like multithreading. By contrast, C# just requires prefixing a function with the keyword "async" and (if you want to wait for the result) prefix the function call with "await". I like that kind of coding efficiency. Same as in javaScript or Dart.
However the keyword clearly indicates what it is: asynchron.
In other words: it has nothing to do with "multithreading".
In general your program has two or three main threads.
The thread that is started when the main() - method/function is executed, and *one single helper thread* - in case of a GUI, you might have two helper threads.
"async" marks a method as possible asynchron and using the await keyword inside of its body. That means the method is not compiled as an ordinary method, but into a helper object. It only looks like a method in text.
When the async method is called, all the "await points" are converted into helper objects, too. Those helper objects get pushed into a worker queue, which is worked on with the above mentioned *one single helper thread*.
So, unless you go the "hard Java way" (which is not so hard anymore since we have the concurrent framework), you are never doing "real multi threading".
My contention is that getter and setter methods serve no useful purpose, in cases where you don't need additional logic.
That is in general correct. In C++ I used to use a property pattern, the setter and getter is the same, name of the property, and simply returns a reference to the property.
I think 99% of the world misunderstood Kay's statement about "everything should be a message". For example: there is no syntax in SmallTalk to even access an instance variable/attribute from outside, you have to use a message - which is automatically generated by the system, and it looks "just like accessing a dump property".
Having the mantra of getters and setters in Java breaks the spirit of SmallTalk. Look at Dart, if you like. It is a fine language. Their getter/setter syntax is so laughable simple, it is mind boggeling. And unless you "need" a getter/setter: no one is using one, everything is public by default.
On the other hand, having getters/setters in Java as the "industry standard" makes tooling that generated code easy. For example OR-mappers enhance the setter to flag an object as "dirty" and know to include it into the next transaction. Same with the mantra of using interfaces, especially for collection classes. Frameworks substitute the standard ArrayList etc. with their own ones.
If I write a single Java file, for a single purpose with a hand full of classes, I let fly all exceptions to main. Usually I do not even catch one, because the runtime prints it out anyway. And usually all variables are "standard" aka "package" access ... And if it is already on the system: I use Groovy anyway.
So there are only two times the keyword "public", one for the main class, and one for the main() method.
Do you know C++ well? Do you know that you can overwrite "operator ++"? Do you know th
Re:The idealogical language (Score:2)
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 understand operator overloading well, both in C++ and C#. No arguments there.
I don't agree that "99% of everything should be a message." I've encountered this philosophy, especially in the world of microservices. Microservices have their place, but they are not the best tool for everything. Messages have their place, and are used extensively in Win32, but they too aren't the best tool to solve every problem.
Re:The idealogical language (Score:2)
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 throw checked/hard exceptions.
Half the planets IT is running on "system level" Java ...
You must be living under a rock :P
Re:The idealogical language (Score:2)
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 run on a different thread than the caller. How is that not multithreading?
Re:The idealogical language (Score:2)
The point is that YOU are not doing multi threaded programing. :P
You are using language features and a threat pool that is already there.
No idea why you are nitpicking
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 async/await keywords. You should look into them if multi threading is a problem.
Re:The idealogical language (Score:2)
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 problems relatively far away, and avoiding a lot of scenarios of potential hazard.
Re:The idealogical language (Score:2)
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 would I want to manage threads, when there is a built in tool that manages them for me? And if the tool manages them for me, how does that make it "nothing to do with threads"? I don't have to roll my own threads, to be doing real threading.
Re: The idealogical language *Checked Exceptions* (Score:1)
Re: The idealogical language *Checked Exceptions* (Score:2)
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 requiring a getter and setter function for every property, even if the property has no logic attached to it. Also, multi-threading requires a lot of boilerplate code, while other languages like C# just require an "async" keyword on the background function, and (optionally) an "await" keyword on the caller.
For these and other similar reasons, I prefer a concise language like C#.
It's great for Big Software (Score:2)
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.
Re:It's great for Big Software (Score:2)
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 microservices, you don't want to have middle layers catching exceptions. You want them to bubble up to the top, where they are caught, causing the task to fail with an appropriate error dump. Handling exceptions at intermediate levels, is actually counterproductive to troubleshooting, because the original exception detail can easily get lost.
It's All About Concurrency (Score:2)
Write Once Run in any cloud!!!! (Score:4, Insightful)
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:Write Once Run in any cloud!!!! (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:5, Interesting)
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.
Re: Write Once Run in any cloud!!!! (Score:2)
Containers fix a problem with Python runtime distribution. We didn't need them for Java apps.
Re:It's All About Concurrency (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.
Re:It's All About Concurrency (Score:2)
True question: you really like Dart's model (isolate) ?
Re:It's All About Concurrency (Score:2)
For its simplicity, yes.
But I never used it for a serious project, so I have no real clue about its drawbacks.
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 never seemed to pan out. That's what I'll always remember Java as, something that was supposed to save us from Windows.
Instead we got a bunch of Web games that ran slower than Flash, then they went and named something JavaScript that wasn't even the same language and 20-odd years later it's something that runs pretty much on corporate Linux VMs for corporate stuff.
Re:I remember when it launched (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:I remember when it launched (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.
Re:I remember when it launched (Score:2)
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 touch it with a ten foot pole.
Re:I remember when it launched (Score:2)
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. They looked for a "servlet" programmer. So I sent a short email, asking what is this about? A mistake in the job description? Or do you really need a "bare bone servlet programmer" ...
They never answered, I think it was a 20 year old post, that got "reposted" by accident.
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/python and lower level languages when the performance is required. It's faster to write, runs faster on AWS, and normal people can still maintain it.
I'm sure if you are writing native applications C# or Java might make the most sense. For me though, especially after Apple dropped native support for Java, I just don't see the point.
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 I like Scala, too.
Re:JVM Still Relevant (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 from Java to Dart, not so much from C# for their originally braindead decision to make class names lower case.
However with the var keyword, most people write:
var someText = "bla bla anyway";
Unfortunately they did not get rid of semicolons, as I write code in some toy languages with similar syntax, that is sometimes confusing.
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]
Re:And, thanks to these 30 years, this could happe (Score:2)
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).
MOD UP (Score:2)
Java is the new Cobol (Score:3)
Re:Java is the new Cobol (Score:2)
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.
Never been able to like it (Score:2)
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.
Darling of the bean counters (Score:2)
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 believe that all it takes for code to work is not to crash.
In fact, some of the pointy-haired bosses even decided to try their hand at programming in Java, ended up with non-crashing code, and concluded that "it's easy".
The end result is that large programs (systems?) written in Java have much crappier code than C++ by the time they finally start to crash. But the programmers that are maintaining these projects are much cheaper to hire than the ones for equivalent projects written in C++.