spricket

Fair enough. The Java ecosystem is huge and I try to keep up but many things slip through the cracks, you'll find many in my furious comment history on the thread.

Thanks, looking it ip

Completely agree, except that MS was so crazy hostile to OSS that they scared off all the serious guys a decade ago. I wish them the best. The CLR has some compelling features that make it objectively better than JVM on so many levels.

But the lack of ecosystem is killing them. And has been forever. The new MS CEO is great in my mind but it will take many years to turn the ship around. Devs don't forget.

Best example I can think of (was a C# guy for years). Resharper has been around forever. But it costs a lot. This is par the course for C#. I can get the same thing in Java by pulling in a few linters with Maven, and it's all free. Because MS scared away everyone that was afraid of licensing fees (ie most academics, the sharpest devs out there), there's nothing comparable.

Same with C# port of Quartz and so many others. They killed off the real rockstars among us that create the majority of libraries that everyone else uses.

Can it be fixed? I hope so. The CLR is great and Oracle sucks. But for now there's a good reason Java is dominant

Agree, and yeah Java is peaking "uncool". But I don't care. Call me old fashioned but the damn thing works so good I can forgive a multitude of sins

I've done this a few times. Most are due to reflection limitations with the newodule system.

They can be worked around by adding exceptions to removal of reflection metadata largely. Kinda a PITA but not too hard.

Active libraries have pretty good Java 11 support these days though. It's really improved a lot on the past year or two

You need to take the library approach. It's much like react vs angular. With angular, and spring, you get a ton out of the box but much is mediocre.

Like React, you can out together your own "best of breed" java stack. It just takes a lot more work.

Look to replace one component at a time. For DI Guice or Dagger2. For REST Vert.X or Jersey. Logging Logback. Metrics, DropWizard Metrics. OAuth ScribeJava. Hibernate for Spring Data.

Take a look at the "awesome java" repos and choose your poison.

I'll warn you now that while you can end up with something far better you lose the coherency of Spring. Of your organization doesn't have a good "apprentice" setup all the new devs will be utterly and hopelessly lost. And good luck finding a Dev that knows 20+ libraries vs "Spring".

Rolling the libs was worth it for us but probably not a lot of eng orgs

If you're just looking for a drop-in Spring replacement you can't go wrong with DropWizard. It's a solid combo of best-of-breed libraries and has quiet support/adoption by many huge companies

This is excellent thank you

Yeah seriously Java's threading support is good but the boilerplate was horrific.

One thing you should know is that parallel streams use default thread pool unless you specify otherwise. Had that choke up some REST handler threads a few times. If you think it might be an issue make sure to specify a different pool

No idea that Groovy was designed by the guy of Antlr fame... Pretty humbling TBH.

Check out Kotlin though. It's seriously great and doesn't share lost of the performance penalties of Groovy

Not in base java, but some libraries essentially fix this. Vavr https://www.baeldung.com/exceptions-using-vavr

But my favorite is abusing the language using Lombok SneakyThrows. It just feels dirty using it. In a good way.

I share your frustration but this new GC should drastically reduce the issues with creating tons of garbage. There's still the infamous "allocation wall" but value types wouldn't solve that either. But they would make it a lot better

Notably, Graal has been used extensively by TruffleRuby for a while now. It's not oficially ready for prime time but definitely promising.

Ah yes, parallel stream(), for when you need to filter a list of 13000 entries for.... Reasons. Bad reasons.

Use it all the time :)

One of my Java guilty pleasures is pulling in some 14 year old library and it just works. Absolute gold for a company with a lotta old code sitting around.

I also do a good bit of frontend and holy crap it's exhausting. That's the main reason I push hard for Java backend. Backends tend to stick around about a decade longer than you would like, while front end code is due for a rewrite every 3 years

As another poster mentioned, the new type inference is great. So is lambda support. Another is Lombok.... Yeah it's not official but we use it literally everywhere and it helps a ton with data classes especially.

Nullaway and a bunch of other linters will also save you from accidentally falling in one of the dusty corners.

RxJava and Java Streams are also very nice.

Anonymous classes are nice too I guess (although they're fairly limited).

Overall the java experience has improved massively in the last 5 years, but you need to know where to look. Highly recommend the two popular "awesome java" repos on GitHub for an overview

Wow great link. I live pretty deep in Javaland and had no idea it was that good!

Lack of value types sucks so yes I agree. On the other hand this new GC might be fast enough that it just doesn't matter if you create garbage for most purposes

Totally agree. C# and kin are far better designed. It's the lively Java ecosystem that keeps me around as well

I actually agree with you here that OO is overused. Java has added quite a bit of FP in recent years though.

Lombok makes immutable data classes trivial. Improved interface support for default methods make it possible to largely ignore OO if you don't want it.

FP is mostly a community effort at this point, but solid. Java Streams are decent for basic stuff like map/filter but RXJava is extremely powerful if you want the complexity it comes with. Vavr is nice for adding more FP types too

Newer versions of Java cache compiled classes. The startup time is maybe 10 seconds for something big running Java 11.

You can also compile AOT for some performance loss at runtime but zero startup time. Android has been doing this forever but you can also do it on a PC using Graal.

And yes Java will destroy Erlang at concurrent connections if you use an async framework like Vert.X or fibers using Quasar/Comsat. It has lower per thread overhead than Erlang and runs code faster in general.

Both Java and Erlang will max out Linux TCP connections before running out of steam so this is kinda academic though

I agree that the future looks bright for Kotlin and C# .Net Core especially. I'm also a big fan of Typescript but JS derivatives are missing many nice things like threading.

But I disagree that Java is like Cobol. The syntax and general situation is extremely similar to C++. There's still tons of work being done on it, but it's a mature language that will be around for decades. IMO it's still the best language to run on the server for a multitude of reasons.

Java would take the cake in almost anything speed measure you mentioned. Golang is the only one comparable in memory throughput and latency. Java with async IO like Vert.X can do higher concurrency than Erlang. As can Go.

IMO Java is the most well rounded language, but I'm not trying to convince you of that.

Also there's nothing with java that stops threads from being restarted. In a modern web framework it's virtually impossible to crash the JVM. You just crash a thread, at most (usually the framework catches the exception and it doesn't even do that). Java is also hot reloadable if you use the right framework.

Your tooling argument doesn't make much sense IMO. You can attach to a Go binary but that's about it. Attaching to a VM or interpreter will tell you almost nothing. I would wager you haven't used a Java profile if you're making these arguments. It's vastly superior to anything but maybe C#

You may be right about connectivity checks although I thought they recently removed Google from those.

Lineage has built on top of Android permission system to prevent most apps from stealing data (Android location permission is probably the most notorious). If you have a rooted device with lineage you can also run XPeivacyLua which fakes out any data that apps "require" to install

I'm not sure if you're trolling so I'll try to keep this short.

Java is old, it's crufty. Yes.

But it's extremely fast compared to anything but Go, C#, and "low level" languages nobody wants to touch for web stuff.

The JVM is also extremely reliable. I've seen apps run for years straight.

And the tooling is better than basically anything. Profiling, debugging, realtime code generation and modification. Libraries for anything you can imagine. ~4 solid IDE's.

Java's OO is fine, and all the nightmare patterns died years ago. You only see them because Java has been around for so long. Modern frameworks like Vert.X or DropWizard are fairly nice to work with. Even Spring Boot isn't too bad.

But Spring is dated and not often used for new projects.

The JVM has extremely powerful built in monitoring API's that put any other language I know of to shame.

WebWorkers are trash compared to Java's nice threading model. It even supports CPU optimized Atomics.

There's nothing unusual about writing microservices in Java. V8/Node is just as "big" a virtual machine as the JVM except JS runs ~5x slower and takes 5x more ram.

You can also write Lamda in Java.

There's many valid critisicms of Java but yours are largely invalid

It should help performance on almost any JVM app, but much more on large heaps.

The GC time is lower and multi-threaded but most importantly the "pause time" is low and nearly constant (based on root set size)

The old GC's all scaled pause time roughly linearly with heap size. Apps that created a lot of garbage would have all their threads yielded for large amounts of time.

Now, essentially, it doesn't matter how much garbage you create. This is awesome because you used to carefully watch how many allocations you made to avoid bad GC times. Now it doesn't matter. Make as much trash as you want and the GC will deal with it

This has already happened in a way. Unity uses a ton of C# for scripting. While C# is somewhat nicer to work with, this low pause GC makes java a compelling option for moving much more logic into the VM language

10 ms isn't all that much. When games load in assets they'll do various things like malloc huge chunks and you lose a few frames.

If GC only causes occasional (maybe every 2 minutes) loss of a frame or two it should be no problem. If you watch benchmark FPS traces that count every frame delay you'll see that occasional stutters happen in basically every game.

Loss of a single frame just isn't noticeable

From the tests I've seen on beta versions, no difference.

The performance increase is from a different algorithm + full multithreading. Not from collecting garbage less often as is a common tactic to reduce time spent in GC

If you care about privacy and have about $100 + 4 hours you can get a Galaxy S5 running LineageOs without GApps (use F-Droid store) .

Almost completely OSS besides a few manufacturer blobs you can't really work around.

I have a "normal" Android phone I use for work but my S5 is my daily driver for everything else. Works great, hardest part is setting up stuff to replace FAANG.

I use ProtonMail, Open Camera, Matrix/Riot for family chat.

Haven't found a good calendar yet but overall way more usable than a dumbphone and privacy concious

There's some "nicer" options like One plus for LineageOs but you will probably find the S5 fairly snappy since its based on Android 8.0 . IMO the last few versions of Android make a much larger performance difference than a few CPU generations

There's two main approaches to handling "events". Using event sourcing vs direct RPC. After our disaster I highly recommend Google's approach, A structured gRPC layer between services with blocking calls. You might think you don't have much data, we didn't either, but when Kafka is firehosing updates to LoginStatus 24/7 data cost gets out of control fast.

I'm going against the Martin Fowler grain hard here, but Event Sourcing in practice is largely a failure. It's bad tooling mostly as I mentioned, but please stay away. It's so bad.

They use cathodic protection which makes the underwater hull basically immune to corrosion. But this doesn't stop water that gets on top or inside.

Ships rust like hell. I've known some guys in the Navy and they said it was common for everything unarmored to have holes all over.