I got 99 problems but a switch() ain't one: Java SE 13 lands with various tweaks as per Oracle's less-is-more strategy Oracle on Monday announced the release of Java SE 13 (JDK 13), saying it shows the tech titan's continued commitment to make innovation happen faster by sticking to a predictable six-month release cycle. No evidence was provided to demonstrate that enterprise innovation is actually accelerating as a consequence of biannual …
The new switch is nice.
The option to release memory to the OS quickly should help small devices, like cellphones. Hopefully Google hasn't forked the Android JVM innards so it's technologically stuck again.
Preparation for Project Loom (back to the old many:many ratio between Java and Kernel threads) is ambitious but I still need some convincing that the complexity is really worth it. I haven't run out of native threads since 1998. WebSockets involve massive numbers of idle TCP/IP connections but they're message-based so non-blocking I/O isn't too complex for them.
"because waiting three or four years between major releases just isn't done anymore, for the most part."
But it should be. In my opinion, rapid release beings all sorts of unnecessary badness and is currently one of the major things causing the decline of software quality.
There are LTS releases in the mix as well, for those of us rightly inclined towards using software with support windows measured in years and not months. The big advantage of the increased cadence means you don't have to wait for a big-bang release if you *need* a new feature, you don't have to take your chances on nightly builds to develop for future-state features and the APIs are versioned more frequently, so we're not stuck with bad decisions for as long.
It's a nice balance so far.
My personal belief is that all Enterprise software should always be LTS with bug fixes and security patches (that you need for support) and the occasional feature release that you can take or leave without affecting support.
Home users, whilst often less technically adept, can make for ideal late-beta testers (but absolutely not pre-Alpha/Alpha/early Beta testing which seems to be far more the norm right now).
This rush to release what are often pointless "features" just to hit some arbitrary bi-annual deadline that they've created for themselves is what is leading to so many code quality problems.
> The big advantage of the increased cadence means you don't have to wait for a big-bang release if you *need* a new feature
True, but it's not like you get to pick just that feature - you get all or nothing, so if people are rushing out half-baked "features" (because, errr, marketing) then you'll get them too, bugs and all.
The downside with going from LTS to LTS is that each time you get 3 versions worth of breaking change each time. On the other hand you're only doing this every few years.
Even then, I don't really see the point of having such a quick release schedule for a language that's supposedly mature.
Except they're *not* LTS. They just hang around slightly longer than the squirrel-on-methamphetamines schedule that the devs would prefer. Until Windows 10, windows lifetimes were about a decade. As the article mentions, C++ is only updated once every 3 years. Many linux distros LTS releases go 5 years.
The problem here is a matter of attitude. The newer generation is composed of devs for whom ADHD is considered a goal to strive for. They think it's entirely reasonable to do a complete rewrite of whatever they've done, because the framework they used is now a week old and is now boring.
Meanwhile those of us who have real jobs that require us to not dick around, are getting completely crushed by the overwhelming churn because there are simply no resources available to keep up.
Applications updating frequently is one thing. They need to adapt to changing user needs, and yes, those can change wildly. But IT Infrastructure? The exact opposite. People depend on infrastructure. People's *lives* depend on infrastructure. Their *money* depends on infrastructure. Infrastructure, and by extension, things like programming languages, MUST be stable. This isn't a philosophical viewpoint. This is hard and gritty reality, which anyone who has done IT work for more than a few years will have learned.
All you need to do is look at the most long-term successful technologies and you see one very common factor: They are stable. The HTTP protocol is a perfect example. Do people honestly think the web would exist as it currently does, if people made major changes to the HTTP protocol every 6-weeks to 6 months? No, it wouldn't. And until people start remembering this lesson, we are headed into a technological dark ages where entire technology stacks will be invented, implemented, and dropped again without so much as leaving a footprint in history (except maybe as a bad idea).
>You are showing your ignorance - the core use of Java isn't on the front-end, it's server-side - and it's HUGE. Financial circles and big enterprises in particular.
Keeps those busy and employed in cybersecurity I guess just as British Leyland cars were once an excellent source of income for garage mechanics.
the cost of replacement parts in modern cars has gone up (I don't mean the main ancillaries/parts like alternators, starter motors, brake discs/pads etc which can be shared across a range of cars and manufacturers), but the more bespoke parts for a given model - making the less frequent dealer visit a still profitable transaction for the dealer/vehicle manufacturer.
" Financial circles and big enterprises in particular."
I worked at a large corp where some new manager joined and immediately decided to replace the C/C++ system with Java. His "vision" (or myopia in reality) took 3 years to create, ended up running at 1/4 the speed on the same hardware and used 10x more memory than the system it replaced. It was summarily dumped wasting almost a million quid in development costs and he left before he was kicked out on his arse.
Disabling Java on the web (in the browser), yes - that is a very, very good idea. Unfortunately some cretinous web application developers use Java instead of a genuine web application (hmmm: Oracle) which does cause security issues - as well as usability issues due to developers pretending that a website is a modal rich client application.
On the other hand, having Java installed on a system to run software written in Java... that is no less safe that any other execution of a local application. Often annoying juggling all the incompatibly Java versions, but that is different to security.
Even if you've disabled Java you are likely still using it every day.
Your sim card is almost certainly a JavaCard. Use the internet? You won't get far before hitting a site with Java on the back end somewhere. Most Android apps are written in Java. Blueray players use Java. It's embedded in all kinds of devices, it's everywhere.
Funny. Several of people jumped in to reply how uninformed was the comment, but nobody was able to point out the difference between a Java Applet and a Java Application. Furthermore nobody dares to notice that the much touted HMTL5 from a security point of view is worse than the various Java plugins for the browser. It may not be unsafe as Flash, but ditching the Applets in favour of Javascript made things worse, really worse.
This post has been deleted by its author
Because I honestly can't recall one since the module system that was introduced in Java 9, and thus doesn't count. Oracle had trouble shipping major Java features in the old release cycle, and it seems to me the new one did not improve on this at all. Maybe it's for the best though, since the last few major features had some significant problems.
One thing I'm moderately interested in watching evolve is the GraalVM, which hasn't been getting a lot of press. We were having issues (core dumps in fact, which are most un-Java) and switching to the GraalVM got rid of them with no impact on performance, and it's rock solid. So that's good.
But the ability to mix up code from different languages on the same VM is potentially quite interesting. Found a nice NodeJS implementation of something you need in Java? Don't port it, just call it directly.
". Found a nice NodeJS implementation of something you need in Java? Don't port it, just call it directly."
Wow, calling javascript from java, the efficiency must be just off the scale. I bet your stuff just flies!
/sarcasm
A week late. But given both languages are running on the same VM using the same bytecode and garbage collector, can you explain to me why a properly designed, properly written JS library cannot run as well as the same in Java?
Yes, I realise finding a properly written JS library is a bigger problem than in most languages, which is probably the point you're trying to make. But that's not really the fault of the language.
As long as the JDKs continue to support compiling and running to Java 8, I'm fine with release schedules. Java 9's Jigsaw is a nightmare that will stop uptake (by most significant legacy applications, at least) of any new features post that; until the powers that be admit it was a mistake and remove it again
Given how Oracles Java strategy seems to be in more than 1 place at a time its certainly plausible.
As an aside - IMO frequent core language updates do no one any favours. It helps to get people using the current revision and find any issues before chucking another update over the wall. Also constantly having to play catch-up gets old really fast especially when you have a full time job to do at the same time and the language already has all the functionality you need anyway. The C++ commitee have the right idea - once every 3 years gives the current iteration a chance to get out into the wild and be used properly and time for people to actually learn it! 6 months is too quick and every few weeks for web stuff is just absurd.
Slow or absent changes mean that your code will work for a long time. Any change in the language can mean that your code breaks resulting in more of a motive to replace it. That's why the slow development of COBOL caused it to be indispensible for many banks. If Java was changing every couple of years no bank would seriously consider it.
I mean Java didn't even include the really sensible feature ideas of J2K yet.
Some would say Spring is legacy too. It's an incredibly heavy and tightly integrated framework that never works the way anyone wants it to. Its annotations and conventions spread into your entire codebase, making a horrible mess and causing lock-in. Forget about debugging any of it.
Newer architectures are more utility based. You use what you want and only when you want it. You start off writing a bit more code but it is eventually much cleaner and easier to maintain. DropWizard would be the newer model, though it's just a collection of other things with a bit of integration code. You can remove DropWizard from a DropWizard app, and I like that.
I thought RedHat were now the stewards of Java, or did I misunderstand that?
(also enjoying the slew of comments that appear on all java related articles from people who try to show their expertise by saying that java should be binned with flash, but in fact demonstrate their complete ignorance of what java is really used for!)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
