Java Programming Language Celebrates Its 25th Birthday. What's Next? (infoworld.com) 75
May 23rd marks the 25th anniversary of the day Sun Microsystems introduced Java to the world, notes InfoWorld.
Looking at both the present and the future, they write that currently Java remains popular "with enterprises even as a slew of rival languages, such as Python and Go, now compete for the hearts and minds of software developers." Java continues to rank among the top three programming languages in the most prominent language popularity indexes — Tiobe, RedMonk, and PyPL. Java had enjoyed a five-year stint as the top language in the Tiobe index until this month, when it was overtaken by the C language, thanks perhaps to the combination of C's wide use in medical equipment and the urgency of the COVID-19 pandemic.
Nevertheless, Java represents a huge ecosystem and source of jobs. There were an estimated nine million Java developers worldwide in 2017, according to Oracle. A recent search of jobs site Dice.com found nearly 12,000 Java-related jobs in the USA, compared to roughly 9,000 jobs in JavaScript and 7,600 in Python. Plus, Java has spawned an enormous ecosystem of tools ranging from the Spring Framework to application servers from companies such as IBM, Red Hat, and Oracle to the JavaFX rich media platform.
The developers behind Java — including Oracle and the broader OpenJDK community — have kept the platform moving forward. Released two months ago, Java 14, or Java Development Kit (JDK) 14, added capabilities including switch expressions, to simplify coding, and JDK Flight Recorder (JFR) Event Streaming, for continuous consumption of JFR data. Up next for Java is JDK 15, set to arrive as a production release in September 2020, with capabilities still being lined up for it. So far, the features expected include a preview of sealed classes, which provide more-granular control over code, and records, which provide classes that act as transparent carriers for immutable data. Also under consideration for Java is a plan dubbed Project Leyden, which would address "longterm pain points" in Java including resource footprint, startup time, and performance issues by introducing static images to the platform.
Looking at both the present and the future, they write that currently Java remains popular "with enterprises even as a slew of rival languages, such as Python and Go, now compete for the hearts and minds of software developers." Java continues to rank among the top three programming languages in the most prominent language popularity indexes — Tiobe, RedMonk, and PyPL. Java had enjoyed a five-year stint as the top language in the Tiobe index until this month, when it was overtaken by the C language, thanks perhaps to the combination of C's wide use in medical equipment and the urgency of the COVID-19 pandemic.
Nevertheless, Java represents a huge ecosystem and source of jobs. There were an estimated nine million Java developers worldwide in 2017, according to Oracle. A recent search of jobs site Dice.com found nearly 12,000 Java-related jobs in the USA, compared to roughly 9,000 jobs in JavaScript and 7,600 in Python. Plus, Java has spawned an enormous ecosystem of tools ranging from the Spring Framework to application servers from companies such as IBM, Red Hat, and Oracle to the JavaFX rich media platform.
The developers behind Java — including Oracle and the broader OpenJDK community — have kept the platform moving forward. Released two months ago, Java 14, or Java Development Kit (JDK) 14, added capabilities including switch expressions, to simplify coding, and JDK Flight Recorder (JFR) Event Streaming, for continuous consumption of JFR data. Up next for Java is JDK 15, set to arrive as a production release in September 2020, with capabilities still being lined up for it. So far, the features expected include a preview of sealed classes, which provide more-granular control over code, and records, which provide classes that act as transparent carriers for immutable data. Also under consideration for Java is a plan dubbed Project Leyden, which would address "longterm pain points" in Java including resource footprint, startup time, and performance issues by introducing static images to the platform.
Next? (Score:5, Funny)
Re:Next? (Score:5, Insightful)
What is next is obviously another 25 years of both glib and over-wrought opinion articles about how Java is Dead.
Usually included is the author's favorite language that will take over Java's position.
In the meantime -- millions if not billions of lines of new Java code will be written.
Re:Next? (Score:4, Insightful)
Millions of lines will definitely be written.
If anyone of them will be other-than-boilerplate remains to be seen.
Re: (Score:2)
Re: (Score:2)
The policies Oracle have regarding Java will make some organizations hesitant to use that.
In many cases too complicated licensing is what slowly kills a technology.
Re: (Score:2)
Re: (Score:1)
You could not be more incorrect. (Score:5, Interesting)
I know, and I love the fact many proprietary application comes with it own java run-time and because it will not work with newer versions of java. So we are stuck with many different versions of java tied to various applications because vendor won't upgrade since that can impact the bottom line.
You could not be less informed about Java. It is fully backwards compatible with compiled binaries, unless you do bytecode manipulation (read and alter compiled binaries). The vendors provide their own JVM so users don't have to or to ensure you have the minimum version, not because they have to. It is a convenience mechanism. You can just install the latest JVM and unless you're manipulating compiled bytecode (which you really shouldn't do), it will work perfectly...I do this all the time.
(and even if you manipulate bytecode...which you really should never do... you usually just have to ensure you have the latest version of the lib).
I've been working with Java for most of it's 25 years as my full time job. I have worked on it for giant and small projects. It is far more reliable, particularly over time and OS upgrades, than Python, NodeJS, or native code, which I have worked with as well You install a JVM correctly and everything works. I have had so many python projects break on OS updates because the underlying libraries broke and we had to rebuild and recompile the library. Getting a 5yo NodeJS project to work on the latest libs was an absolute nightmare....very hard to find all the errors that a compiler would have just found.
I use a LOT of libraries that are 15, 20+ years old...without modification whatsoever...they even perform a LOT faster than they did 20 years ago due to JVM optimizations introduced.
Write once, run anywhere was originally marketed to help you deploy to Solaris, Linux, and Windows (or whatever obscure UNIX you were into). The glory of it today is that it truly is "build once, run many decades into the future without any hassle on your part." It is very much a set it and forget it platform. I work with many apps that haven't been touched in many years...they just run..they were written right the first time and no one ever thinks about them...they fully take them for granted. You can even update to the latest JVM...things just run. Java is definitely a much better investment for a business than Python, NodeJS, or native code for that reason alone...if you do it right the first time, it just runs indefinitely with no thought on your part and an occasional JVM update on your part for the security fixes. It is not the most fashionable technology right now, but in is the lowest maintenance platform I have ever used.
Re: (Score:2)
Re: (Score:2)
You could not be less informed about Java. It is fully backwards compatible with compiled binaries, unless you do bytecode manipulation (read and alter compiled binaries).
So why can't I run V9t9 [github.io] anymore?
Re: (Score:3)
Re:You could not be more full of shit (Score:2)
Minor version changes break the expensive proprietary wares we run, Oracle has left backwards compatibility behind and enterprises must keep various versions on clients and servers. Everyone knows this but you.
Re: (Score:2)
The remote media/kvm client with the hp ilo100 boards would only work with a specific revision of java 1.4.x, i ended up having to maintain a vm running that exact version for accessing these systems.
I could never get corel wordperfect for java (released 1996) to work on any new system.
It's possible to write portable code in many languages, and you're right about newer languages being worse from a compatibility standpoint. I have C code that was written in the 90s and still compiles and runs on modern linux
Re: (Score:2)
You managed to find some counter examples. Congratulations. And you provide anecdotal evidence of code you wrote in the 90's. Congratulations. You had to recompile it though, shame.
Your example however still don't take away from the *fact* that an old Java app is much more likely to run unmodified on modern hardware then C or Python.
Re: (Score:2)
Java apps that do still run are anecdotal too..
I have to recompile code i wrote in the 90s, because it gets compiled to native code and the processors which originally executed that code (m68k, sparc) are no longer in common use.
Linux binaries from early versions will still work on current systems assuming a compatible processor and presence of the necessary libs.
Windows binaries from the 90s will largely still work on current versions, with the exception of 16bit binaries on 64bit windows.
Solaris binaries
Re: (Score:1)
I know, and I love the fact many proprietary application comes with it own java run-time and because it will not work with newer versions of java. So we are stuck with many different versions of java tied to various applications because vendor won't upgrade since that can impact the bottom line.
You could not be less informed about Java.
hahaha ... Oh, wait, you're serious? Let me laugh harder! HAHAHAHA
It is fully backwards compatible with compiled binaries, unless you do bytecode manipulation (read and alter compiled binaries). The vendors provide their own JVM so users don't have to or to ensure you have the minimum version, not because they have to. It is a convenience mechanism. You can just install the latest JVM and unless you're manipulating compiled bytecode (which you really shouldn't do), it will work perfectly...I do this all the time.
Right [stackoverflow.com], maybe you should tell the ubuntu [launchpad.net] maintainers your theory of how JRE is always backwards compatible. The debian maintainers [debian.org] would also like to hear from you, considering they closed the backwards-incompatible bug without fixing it. Rather than dealing with the backwards incompatibility, Ubuntu/Eclipse simply shifted to delivering [snapcraft.io] the app with a runtime independent of the installed one.
And that's just one opensource app, there's literally the entire first dozen results [google.com] in google for bugs resulting from a newer java version that doesn't work with older apps. And that's just the ones we know about!
In my time at various institutions, every proprietary vendor would supply their own JRE with their app, specifically warning that using a newr version would break their app.
I've been working with Java for most of it's 25 years as my full time job.
How could you not have run into this, then, especially as it was far more unstable WRT backwards breaking changes in the first ten years. It appears to me that you may have 1 years of experience, redoing it 25 times over the last 25 years.
Re: (Score:1)
Re: (Score:3, Insightful)
Hi, Full disclosure: Java dev here (sorry).
Your examples seem to point at an eclipse dependency bug, not really java specific: "eclipse-platform version is 3.8.1-11 it depends on eclipse-rcp version 3.8.1-11 which in turn depends on libequinox-osgi-java (>= 3.9.1). But eclipse-platform-data expects libequinox-osgi-java version 3.8.1-11:". Let's be honest: eclipse has always been an unholy union of java and native code. It's been my bread and butter for 10 years, but I've moved on to greener pastures...
Re: (Score:2)
If they are compatible, then why do Java applications always need one very specific runtime? They always come with a requirement like "version 7.43 of FooBar needs JRE 8.236". Not 8.234, not 8.240, but exactly what we ask for.
Re: (Score:3)
Do they really "need" JRE version 8.236, or did the application's SQA team test the release only with 8.236, and because of that they only want users to run it on 8.236 because they are worried (justifiably or unjustifiably) that users who run on other JRE versions will run into a bug that the SQA team didn't find?
(i.e. the app would probably run just fine on any 8.x JRE, it's just that the app's developer isn't comfortable trusting that it would, and doesn't have the resources to test every version to find
Re: (Score:2)
You could not be less informed about Java. It is fully backwards compatible with compiled binaries, unless you do bytecode manipulation (read and alter compiled binaries). The vendors provide their own JVM so users don't have to or to ensure you have the minimum version, not because they have to. It is a convenience mechanism. You can just install the latest JVM and unless you're manipulating compiled bytecode (which you really shouldn't do), it will work perfectly...I do this all the time.
This open source application, Maptool [rptools.net], will neither run nor build with a JDK version greater than 10. It will NOT work with 11. Nor with 13. Nor with 1.8. None of the JDKs that are available as packages with Linux distros will work. You must sign up for an account with Oracle and get the exact correct JDK version, which must be manually installed since there are no distro packages for this JDK.
It's open source. Prove me wrong.
Re: (Score:2)
You know, I have encountered one Java application that barfed because it was running on a newer version of the JVM. I've run older applications on Java and OpenJDK without issue. My older apps, one of them written around 2001 or so, runs just fine.
I left Java 8 year ago and never looked back (Score:5, Interesting)
In Java, in addition to writing a functional program, you have to build an extensive type system. That's half the work, and yet it's not really programming... it's documentation and runtime error prevention.
Same thing is going on right now with TypeScript. Are custom types worth the bother? I'm on the fence. For quick and dirty stuff, types get in the way. For more complex applications, types can be very very useful (and also have a very very difficult inheritance chain to follow). Thats why, when programming in Java, you really need an IDE to do the bookkeeping for you.
(I really liked Groovy, where I could mix and match typed and untyped approaches within the same application. Too bad about all that reflection though.)
Re:I left Java 8 year ago and never looked back (Score:5, Insightful)
Same thing is going on right now with TypeScript. Are custom types worth the bother?
Using types will reduce your bugs by 15% [ucl.ac.uk] or maybe even by 38% [reddit.com]. Instead of avoiding types altogether, try to think of ways to make your type system simpler, so it doesn't feel so heavy (btw, if you have a good IDE, creating a new type is as easy as "right-click->create-new-class".)
The real win for a good type system is in refactoring, though. If the type system is done well, it's like self-documenting code. If the system is done poorly, you can still use a lot of the automatic refactoring tools that are not possible in a dynamic language. Even renaming variables is easier with a type system.
As for typescript itself, it feels a little kludgy. Eventually we'll all be writing frontend code in the language of our choice, and compiling it to web assembly.
Re:I left Java 8 year ago and never looked back (Score:5, Insightful)
Are custom types worth the bother? I'm on the fence.
Not sure what fence you are on but I'm pretty sure you got a lot of splinters in your crotch.
The reason for Typescript strong typing is so the IDE can more easily help you write code (auto-completion, type checking, etc) that compiles first try and so the IDE can help you find stuff in imported modules. All while still making the weak typing of Javascript available for when that is an advantage.
You have to know what you are doing regardless of the language. No language is going to save you from your lack of preparedness for a given project.
Re: (Score:3)
In Java, in addition to writing a functional program, you have to build an extensive type system. That's half the work, and yet it's not really programming... it's documentation and runtime error prevention.
Ahh horse hocky. It's no better or worse than C/C++. If you're spending half your time on a type system then either your type system is too complicated, or you're coming from a Javascript background where there are no types.
Re: (Score:3)
Ahh horse hocky. It's no better or worse than C/C++.
The type systems in C and C++ are so dramatically different that this sentence doesn't make sense.
Re: (Score:2)
the type systems in C and C++ are so dramatically different that this sentence doesn't make sense.
I wasn't comparing type systems, I was comparing the difficulty of the type systems.
Hate documentation? I hope we never work together (Score:5, Insightful)
In Java, in addition to writing a functional program, you have to build an extensive type system. That's half the work, and yet it's not really programming... it's documentation and runtime error prevention.
Wow!....Documentation is one of the most important facets of professional software development. It feels tedious to build so many classes, trust me...if you succeed at your job, it will be handed off to another team and they will put you on another project, if not promoted to a different role. I work at a large company and love that I can just download the source and easily figure out what is going on. That boilerplate makes the code much more reliable, especially 5 years later when the original author left to create his dream startup or get fired or poached by a better employer, etc. The vast majority of real programming is wiring together existing libraries and documenting business logic and workflow that is unique to your project and employer, almost no one gets paid to create algorithms or whatever you think is "real programming."
When you're not making money or your team is small enough to fit in a minivan, do whatever you want. If your money is on the line and your project need to last more than 5 years, that documentation is very important as people leave, get promoted, etc. There's a reason Java has been on top longer than any modern language in the business world and that's that culture of documentation, object oriented design and strong typing. It becomes mission critical in real world use as authors move on and projects grow in size and scope. It is definitely less fun, but I have inherited many "fun" projects from idiots in love with their own intelligence and creativity...it was impressive when first demo-ed, but a NIGHTMARE to maintain or make production-grade.
You may be able to write it twice as fast by skipping documentation or design...but then it will get handed off to anther team to make it production grade and secure and they will spend twice as long fixing your idiosyncrasies and your project would be way farther behind than had you just done it right the first time.
Re: (Score:3)
I find that boilerplate code tends to grow as the winds of fashion blow. Abstraction is a COST. You don't blindly add costs to your software without the corresponding benefits and analysis. Sadly, people DO just blindly add boilerplate, "because that's how we've always done it".
Not everything needs to be split into a reusable hierarchy 42 level deep and 16 wide.
Some things are just small, tight, self-contained, not-used-anywhere-else pieces of logic. I don't need the kinds of extreme boilerplate second-syst
That's an HR issue, not a Java one (Score:4, Insightful)
Some things are just small, tight, self-contained, not-used-anywhere-else pieces of logic. I don't need the kinds of extreme boilerplate second-system-syndrome that demands every string needing left padding needs a special class hierarchy to handle it. (I point out a piece of stupidity from the JS community here, but Java programmers are among the primary offenders here, regardless of which language they might be in.)
That's not a Java issue. That is an HR issue. Any useful tool can be misused. If there's too much OOP ceremony, that is bad code, plain and simple. A lot of Java programmers are absolute garbage. A lot overengineer. There's a happy middleground between insane and impractical complexity and "cowboy coding"...which is extremely idiosyncratic code, written quickly, with no documentation, validation, weird structure, etc.
The best practice is to have the right amount of structure, no more, no less. Most people that complain about Java don't seem to have many years experience or seem like they are working at young startups. I found OOP/Java off-putting at first 22+ years ago when I was used to scripting languages. However, once I handed off code and had code handed off to me, I greatly appreciate it. The JVM is awesome, but so are many platforms. The Java language is good, but not really much better/worse than it's competitors. The reason Java succeeded was a mix of technology and culture that JavaScript, PHP, Go, and Python never replicated...highly documented best practices, near-universal conventions for everything, backward compatibility over language innovation and my favorite is the fact that once compiled everything just runs...decades into the future. If you did it right the first time, it is very low maintenance, even many decades later.
I have horrible JSF code I wrote 15 years ago which still runs today. I am embarrassed by it (the technology is really dated and the UI is very basic and amateurish now), but the company that paid me got their money's worth. All they do is update the JVM and some libs from time to time. No one has touched the source code in 12 years. It still has 100s of daily users for mission critical clinical data processing. The team that inherited it when they laid off my division like our apps for that reason...they just work...no drama, no fuss, that app may very well outlive me. It's ugly as sin, even for it's day, but it works, has passed lots of security audits from many companies, scales well, and just keeps running. A team that has never met me keeps adding on to it.
Re: (Score:2)
Not everything needs to be split into a reusable hierarchy 42 level deep and 16 wide.
I think that's more a problem of overly-elaborate object-oriented programming. Object-oriented programming is great but it's not a magic bullet and it's not the only way to achieve reuse. When used correctly it actually has significant constraints, which are sometimes clues that a problem really calls for something else like composition.
Re:I left Java 8 year ago and never looked back (Score:4, Insightful)
I'm afraid that's incorrect. A type system is exactly programming. Without it, you're not writing code, you're just hoping that what you wrote will run.
Look into Type Theory. The fundamental concept is that a compiler performs a mathematical proof of correctness of your code. It guarantees mathematically that your program will provide a particular set of outputs given a particular set of inputs. That's huge! With a well structured type system you can eliminate whole classes of errors, making your code unquestionably better.
Re: (Score:2)
I've heard, on many occasions lately, that we should't even be trying to design or specify our software, because we can't possibly know what we want, and it's all too complex, and people will wants changes, and, and, and....
The net claim made at the end of these statements is always that thinking through a design first is a waste of time. The proponents of these arguments suggest that you should sit down at your editor, without any clarified intention held in your mind (forget specified on paper), and, as i
Re:I left Java 8 year ago and never looked back (Score:4, Insightful)
If you have a language that's strongly typed, then refactoring that code will be much easier because the risk of introducing errors is reduced many fold thanks to the compiler warning you about type mismatches.
So yes, if you use a strongly typed language with a picky compiler, then just program. Refactor later.
If not, then either design upfront or redesign the entire app in 3 to 4 years because it is unmaintainable.
Re: (Score:2)
I've heard, on many occasions lately, that we should't even be trying to design or specify our software (...) Well, sure. Blind brute force works for evolution too. It just comes with ridiculous vestigial appendages and insane inside-out-and-upside-down-ass-backwards gotchas, relies on constant breakage, and takes a few million years to produce results of questionable value.
Sure, but how do mismanaged waterfall projects go? You produce a ton of crap somebody thought was a good idea three years ago when they were scratching their ass trying to come up with a specification full of things it turns out they don't actually want or need, either because it turned out to be stupid in practice or the perceived need has disappeared. Also the progress went to 90% on time because everybody was pressured into keeping the project on track or at least claiming to, but the last 10% will take
Re: (Score:2)
There is value in implementing a prototype quickly to check whether the implementer and the customer are on the same page regarding what kind of system needs to be built. That doesn't mean formal methods are useless though.
First, a prototype is not the same as a production system and for important and/or complex systems, it can be worth doing a more formal specification after the prototype is built.
Second, regardless of what behavior the customer expects from the system, there are a lot of possible behavior
Re: (Score:1)
why would you ever want to put something quick and dirty in production?
Kotlin (Score:3)
Re: (Score:2)
I've done some Kotlin now, I agree in a number of ways it's probably better, or at least more modern than Java... has it gotten any traction outside Android though?
Like would we be seeing EJB (or other enterprise) stuff being developed in Kotlin?
Re: (Score:2)
Yes, but not as much as it deserves. For example, Rod Johnson, founder of Spring (defacto standard enterprise Java framework) raved about Kotlin, called it a game-changer. But it is not like every second Java backend is using Kotlin now. Some places do - Netflix for example.
So that's backend. Meanwhile it can compile to JavaScript and native. I tried JavaScript, and even though I like the language better than TypeScript, the latter was much easier. Better tooling, community, etc. I haven't tried native yet
Re: (Score:2)
It's a nice trail ground for features to be added to Java later.
26th (Score:5, Funny)
obviously
How things have changed (Score:4, Insightful)
6-7 years ago I looked into Java again and I quite like it. That 20-30 second delay starting a program is gone. The language is pretty damned verbose which, as I like 80 column windows, is a bit of a problem. But streams is awesome, it's like *nix pipes in a program. I'm not gonna be writing a device driver in Java, but for everything else I prefer it over C++.
Re: (Score:3)
Re:How things have changed (Score:4)
The startup delay isn't gone, it's just masked by massively more powerful hardware. The overhead is still there, and wasting resources which other options would not.
Re: (Score:2)
You are partially right. More powerful hardware helps, and with Java, it will actually run on such hardware even if that hardware didn't exist yet at the time of writing. However there have been substantial wins in reducing overhead, better GC and better compilation.
Other options however waste a far more precious resource, developer time, usually significantly more at multiple fronts: compiling, programming, debugging.
Congratulations to Java! (Score:5, Funny)
Who knows how great Java might have become if Microsoft hadn't forked it?
Re: (Score:2)
You joke but Microsoft did have their own JVM for a while in the 90's. In the typical Microsoft way, it wasn't fully compatible with Sun's JVM so you either had to target Sun Java or Microsoft Java. Since the Microsoft JVM was part of Internet Explorer this likely hurt Java on the web the most, as it wasn't as simple as "Does this need to run on Windows?" for desktop applications. Sun eventually sued Microsoft over their shenanigans and Microsoft quietly killed off their JVM.
Sure? (Score:2)
25??? 25 years ago I was still in high sch... no wait... when Java came out I was at uni...
Thanks for reminding me I'm old
Re: (Score:2)
The worst part of getting old is watching all the youngsters ignore decades of past experience, only to have to re-learn it the hard way. It's particularly gut-wrenching when an entire industry does it repeatedly (cf. Web 1.0, 2.0, 3.0). The sane people get out at or shortly after the peak of these waves, a whole bunch of new people reinvent all the wheels, and anyone dumb enough to stick around (like me), gets to make the same tired arguements over and over.
An article on switch expressions (Score:2)
For those that have not seen them before, here's a good rundown [medium.com] (yeah, it's on Medium... sigh) on what makes switch expressions so much more powerful than the classic Swift construct... this is a feature that has been added to a number of new languages so it's nice to see Java get it.
Re: (Score:3)
Wake me up when I can write Duff's Device [catb.org] in Java.
Thanks! (Score:1)
That is extremely interesting and despite having seen a lot of unique C stuff in my life, I had never seen that... very cool.
I am personally a fan of the fall-though.
My prediction? (Score:2)
Java Programming Language Celebrates Its 25th Birthday. What's Next?
Next year it will celebrate its 26th birthday. (That's how calendars and anniversaries work -- right?)
Back to the Browser, of course! (Score:3, Informative)
If you haven't heard, Java is heading back to the browser!
Several tools let your Java code run in modern browsers without plugins or applets. The best-performing tool is TeaVM:
http://teavm.org/ [teavm.org]
It powers many large websites, and is the technology behind CodenameOne for the web ( https://www.codenameone.com/ [codenameone.com] ) and SnapKit ( http://reportmill.com/snaptea/ [reportmill.com] ).
Read more here: https://blogs.oracle.com/javam... [oracle.com]
I can finally have 25 years of Java experience (Score:1)
1995? Sounds about right (Score:2)
I have a clear memory of going to lunch one today while working at West Tasman, Cisco's new HQ back in the 90's, and the conversation was "hey did you hear there was a team from Sun in visiting today. They've invented a new programming language that they call Java and they were trying to persuade us to re-write IOS in it!". We all laughed. IOS was written in GNU C.
The irony is that all my (now ex) Cisco colleagues, who still code, are writing network stacks for routers in Java.
Recruiters... (Score:3)
Finally learn that Java and Javascript are not the same thing?
Well a couple of things (Score:2)
Everybody using Java to do anything important will hope that it becomes the "new COBOL" in that it essentially never changes and just works for decades. Oracle however wants it not to become that and therefore changes minor things while still not accepting the noteworthy improvements of Java2K.
Re: (Score:2)
We moved over to OpenJDK a couple of years ago with no I'll effect. Won't touch Oracle again.
Perl6 (Score:2)
Can Processing Be Rewritten Without Java? (Score:3)
What's next? That's easy. Kotlin. (Score:2)
Kotlin is Java modified by all we've learned in the last 25 years.
And you can just drop-in Kotlin into existing Java setups.
I've had multiple people recommend to not even bother getting into Java but use Kotlin right away.
Seeing the difference I totally get it.
trap (Score:2)
Call the Fonz. (Score:1)
Oracle and Java jumped the shark. Nothing to see here. Move along.