So what do you think about the path oracle is going with Java now?

The good side is new versions get usable much earlier. lts versions, open variants and many JDKs customized for any need you might have.

But there is also the darkside with their hey lets support Java 8 for ever, as long as their is someone willing to give us much money.
I mean that could be a reason many old-school company will pay instead of making their shit work with newer versions.

The gap between C# and Java is getting closer from faster releases, towards modern features and many more. Maming it more attractive.

But Oracle is making the thing a bit shitty in my opinion.

Oracle will be irrelevant in the near future. The pay for patching model is broken profiteering. It won't last, it only exists to bleed enterprise customers.

Amazon is leading the pack in alt distributions with Coretto, and it won't be long until Google joins the game and the direction of java hard forks leaving Oracle out of the discussion entirely.

@SortOfTested Yeah i mean everyone is doing his own flavoured jdk and thats awesome.
I personally have always used the openjdk and not the one from shitty oracle.

But cooperates, like the one i am currently working for, are still jump on the golden oracle train even if it would be on fire.

@R3ym4nn
The real difference in the strategy between Amazon and the other OpenJDK efforts is that Amazon isn't just a build with slight optimizations: they're getting ready for a clean break. They'll still offer API supportability with mainline, but the end goal is to produce an entirely new Java development path.

Enterprises will always be garbage and embrace the legacy Java mindset. Gotta get out of that if you want to work on bleeding edge.

@R3ym4nn Well.

JDK 11 and plus is OpenJDK, as u said.

I think the better question would be: Is the cost of a migration to 11 plus worth it's cost....

And I think no. When you leave new APIs aside (high migration cost)… there are performance fixes (some of them backported to JDK 8) and internal optimizations (can be relevant, but benchmarks are tricky).

I think the most important part in JDK 11 is the G1GC... And utilizing the Java Options… Finetuning the kernel... And so on.

Fully utilizing JDK 11 or later, regarding new APIs, requires full rewrite of a software stack, which costs alot...

And some software stacks are monolithic monsters which you can't tear apart unless you are an vulcan.

And I think OpenJDK will support JDK 8 a long time...

Imo ora made a wise move with jdk8 support. Supporting legacy gets more and more expensive over time and if companies rule pricey legacy support as the least expensive option - it's a win-win. I mean noone's saying ysers not to upgrade java.

Part two.

I still think that an programming language shouldn't be attractive.

Many additions in many languages made the language severely complex, or attractive for things that shouldn't be done in this language...

Looking at C++... It's mind boggling what you can do just for the sake of higher abstraction... Lasagne code? More like the "Malcolm in the middle casserole".

Looking at PHP... People trying to do threads / semlocks and other stuff and wondering why it doesn't work as expected...

Looking at Python... How many times was Async reimplemented?

...

I could go on, but you'll get the idea.

New doesn't make a language necessarily attractive. Sometimes it leads to a clusterfuck.

@netikras
I'd be more apt to agree if they were communicating anything to that effect. Any time they talk about a controversial strategy they always try to put the blame back onto "the community", while ignoring the community as a matter of course.

It's ridiculous, the Java team openly mocks the community during their tech talks; they use the term "asking for it" in the same way a rapist does.

@IntrusionCM
I don't disagree. Though this almost seems like an argument that Java shouldn't be used for FAAS/massively distributed programming.

@SortOfTested frankly I see it this way: either we have ora support for legacy j8 or we don't have any support at all, like j7,6,5,4,etc. Having a paid support option is much better than no support at all, like for beforementioned versions.

It's not like ora is to put a fee on legacy support. Firstly ora is to start providing legacy support, and then - ask for some money for it.

@IntrusionCM Jup, 14 e. g. brought usefull nullpointers, records, multiline strings and so on.

Its a big deal at least for me to update.

@netikras
I just don't find that valuable honestly, it may make sense from an oracle standpoint, but it's also the exact model that drags down Microsoft products. I'm more in favor of legacy deprecation for the sake of forward progress.

Empirical; We had a lot of complaints about the "upgrade effort" bogeyman at a few clients. They fell onto two camps: EE reliant users, and lazy people. The largest codebase (500k lines) took a grand total of two weeks to move from 8 to 11.

As for rapid versioning -- I'm not a fan. Too much motion in the field. Now I have no clue what differences do the 3 latest versions have...

Yes, it's a good thing, considering amount of technologies J has to cover. But it's also annoying :) also it'll be easier for ora to collect $ for legacy support: the more different legacy versions a company uses - the more support to charge for 😁

@netikras
This I totally agree with. It's just a side effect of Oracle trying to desperately compete on features.

@SortOfTested oh, but ora thrives on legacy support! All big fat enterprise companies know that legacy support done right is a profitable cow to milk :) ora, hp, ibm -- they like legacy! I don't imagine a non-legacy engineer paying an on-site visit for $500/hour 😁 that's what one of my employers was paying hp for an old solaris box hdd replacement.

@netikras
Stupid motherfuckers. This is definitely Brian Goetz kvetch-worthy.

@IntrusionCM I honestly never thought about languages that way, but it really makes a lot of sense to me.

@SortOfTested Also I see it profitable for ora clients subscribing for that support. Say you are a corporation having hundreds of java apps running in your departments: internal and external. Some of them have poor docs, some don't have them at all. Some of them don't even their original devs around any more and the newbies are barely handling them.

Now the company always wants to keep the show on the road. So they have to choose: either go with what they have now (i.e. by subscribing ora support) or risk potentially higher expenses by upgrading app to be new-java-compliant to have latest security, stability and feature patches. Well there's always a third option -- commando mode: outdated, legacy, no support :D

If a company only has a few apps to maintain it might be less of a loss trying to upgrade. But with hundreds of apps -- it's just easier to get the same patch for all of them from ora w/o any additional effort - just for an expense of ora support fee.

Also if you choose to upgrade -- you'll be stuck in upgrade-every-5-years-or-so loop. Because J release cycle is more rapid and your used J version will sooner become legacy. You'll always have to be chasing for the newset one..

Once agian, compare costs for a company having ~10 Java apps to a company having hundreds of them :)

@netikras
That really just boils down to, "do we pay it today, or do we assume the technical debt of a full rewrite at some point in the future." Future technical debt is always higher, and legacy systems will always be more attuned to tribal knowledge which exacerbates over time. That's how you end up with $300M IT budgets.

Nearly all of the excitement in the Java ecosystem (in recent years) has been in third party libraries rather than the core stuff. Spring, Lombok, reactor etc. have all made *way* more real world impact than the module system, record types, and GC improvements. Releases in between LTS are nearly irrelevant - no-one I know has moved to them.

I think that's pretty conclusive imho. I also don't think it'll be long until AWS start making some potentially incompatible changes to corretto, make it the dist of choice, and then get everyone to migrate.

There are some exceptions. I like that Oracle has been relaxing the backwards compatibility standpoint somewhat (though in some cases that really is a pain, and is why so many legacy projects will never move past 8.) I like graal - that's really interesting. And some of the minor new features have been nice.

On the whole though, I'd say they're increasingly irrelevant, and increasingly missing the mark.

C# guy says - learn Java 😅

Kiddin'