More importantly, the JVM ecosystem is much bigger than Java itself. The JVM is a highly-optimized, cross-platform, garbage-collected environment on which people have built much more progressive languages that lack the syntactic baggage of Java: Scala, Groovy, Clojure, Kotlin. Clojure is one of the most popular and performant Lisps we currently have, and Scala is one of the closest things we'll get any time soon to a practical version of Haskell. Both of these projects got to avoid building their own garbage collectors, which is an enormous lowering of the effort barrier. And to top it all off, all of these languages' binaries are interoperable, which not only allows you to use different ones for different parts of the same system, but makes it much easier to gradually migrate your legacy codebase to a newer, better language.

I don't know if I'd start a new project in Java-the-language, but it's far from a Cobol situation.

Apache Groovy has inherited all of the syntax of Java. When Jeremy Rayner built the Antlr 2 based syntax for Groovy back in 2005, he began with the syntax for Java, then added the Groovy-specific grammar to it. The latest version of Groovy still uses that syntax, so if Java has syntactic baggage, then Groovy has it too.

I'm picking Groovy will still have that baggage-laden syntax for a while yet. 2 yrs ago, Daniel Sun built an Antlr 4 based replacement grammar, but the Groovy project managers at Apache are taking their sweet time in rolling it along. They even had its optional preview removed from the version 2.6 beta of Groovy.

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

Particularly though, the static compilation is just not comprehensive enough. It tries to do type inference but it's limited and invariably you end up having to add type casts in ugly places to convince it that expressions are valid. Occasionally it actually flat out refuses to compile something valid and you have to find a different way to do it. Sometimes it compiles with one version of groovy and then is broken in the next. It works great though to selectively add to hotspots of code and in other places to speed them up and define them better.

Having said that, we are essentially using Groovy as a java replacement and for our team I think the above costs are well worth it. This is partly because we have a heterogenous application that is partly dynamic in its nature and Groovy's dynamic scripting ability is amazing for this. The fact we can code our whole back end in the same language makes it super easy and well integrated.

That's a bit of a myth these days. Groovy may even be more performant than Kotlin when used with static compilation.

A lot of my reasoning was criticizing the JVM itself, not Java. VM languages add unnecessary complexity in the post container world where ephemerality and kernel APIs (containers) can give the same advantages, although I think Kotlin and Clojure and remarkably good languages.

And historically, nobody cared for that style of programming in its pure form (where "nobody" is in the casual sense: a few FP-lovers, but not the 95% of working programmers).

From 1960 to today it remains niche in its pure form, even the most popular language following it fully (e.g. Clojure or similar) is still a niche language.

We found out, on the other hand, that people care for mixing that style of programming with OO, imperative, reactive, and other styles.

And that's what modern JS, Java, C#, Rust, etc (even C++) give us.

And since FP is a style, it can be followed quite effectively in almost any language -- as long as it has some basic features, which, as you observed, Java has added.

It's not black and white. FP is more like a spectrum, with pure functional programming more towards the opposite end, just before total functional programming. Put another way, adding lambdas to Java does not make it like Haskell. Even Scala cannot effectively be used as Haskell substitute, as some in that community eventually realised.

It remains to be see how much of FPs benefits (composition, abstraction, reasoning) can be fully realised in languages with rampant side-effects and mutation.

> We found out, on the other hand, that people care for mixing that style of programming with OO, imperative, reactive, and other styles.

Which is why you forgot to mention Scala, which shows us how great such a promise land can be when we try to please everyone.

> JS, Java, C#, Rust, etc (even C++) give us.

Out of the languages you mentioned, only certain circles of Javascript (React) and Rust are arguably functional as I mentioned above. Javascript has been a real exception to the rule in how its lack of real class support left a vacuum for some FP. C++, C#, Java, and the majority of Javascript are object oriented and always will be.

No, I think they are using those terms correctly. In FP, “pure” means absolutely no side-effects. So if you add an FP-style library to an existing imperative language, that’s “impure”.

I categorically disagree. Nearly any program has pieces that benefit from OOP and pieces that benefit from FP and everything in-between. The most prevalent and useful languages support multiple paradigms (C++ is a mess for other reasons).

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

Yes there are.

...but the parent assertion that Java will one day be like cobol; no longer taught in intro to CS course (where now we see python), considered bloated and legacy, and not picked for new projects (where we see the rise of languages like kotlin eating into what was once the primary growth for the language with mobile apps) and encumbered by problematic licensing issues...

Seems quite valid.

You have to live in a bubble right now not to get the feeling Java is stumbling, and there’s no indication to me that the overall direction of the language is positive right now.

...I’m sure there are still years ahead for earning a good living as a java developer, don’t get me wrong, but that’s a different issue.

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.

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

Spring Initialzr (https://start.spring.io) is used millions of times per year.

Thanks, looking it ip

Fast is a poor word to talk about benchmarks between languages. Memory, throughput, latency are the things we should be talking about. There’s also trade offs where predictable scaling of latency under massive load is important (Erlang, Elxir), or spending less memory and starting up quickly in order to scale horizontally is important (Golang), or speed of development is important (PHP, Python), or correctness is important (Haskell, Rust). Java is rarely the winner in any area in favor of being well rounded, but as we should be using tools that meet at least the broad requirements it is always possible to make a better choice than Java.

> I’ve seen apps run for years straight.

This is why Java is dated. I am an Erlang developer, which is known for being hot reloadable and running forever. It turns out this model is actually juxitposed to Kubernetes and severless, which both presuppose letting processed crash at the host level and starting and stopping quickly. This also gets into the tooling argument because profiling in Java would rather the VM be long lived.

> The tooling.

I too have an operating system with great tooling, it’s called Linux. My knowledge of tooling is more broadly applicable, I can introspect any binary and attach probes to the kernel with bpf. Profiling for a VM is table stakes because you’re on your own. Not only do you have to figure out what’s going on in the JVM you also need to duplicate your effort to figure out how the JVM is running on the host.

> Java OO is fine.

OO in general is not fine.

Isn't that true for all other languages you mentioned? python, erlang, php, golang bundles a runtime, etc..

Go and Rust are interesting to follow. A highish and low level language both using lightweight runtimes

I smell a zealot or a troll.

Smalltalk is exactly like that - other objects' state is only mutable through explicit message passing. It's also widely considered the penultimate pure OO language.

> Pretty much all of the OO languages are walking back OO features

About the only feature I can think of for which this is somewhat true is inheritance, and that's because we realized that aggregation is often a better model, and can be easily supported by the language to be no more verbose. But it doesn't fundamentally change OO - it was never about inheritance first and foremost; I mean, prototype-based OO doesn't even have that conceptually.

> and trying to add type classes (contracts)

In most OO languages, these typically naturally evolve out of interfaces.

> functional pieces, mapping and filtering a la linear data transformations.

This is not contradictory to OO in any way. Again, Smalltalk has had "select" (filter) and "collect" (map) from the get go.

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

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’re not understanding what I’m talking about when I say restarting. I’m talking about the JVM process. I also just said hot reloading is counter to modern practices.

You’re not understanding what I told you.

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 don't drool over the raw horsepower of each of my individual boxes.[1] All I care about is that I can cost effectively create a cluster of them to serve the application's needs.

Because of this, even if Java could not handle as many concurrent connections, you might still chose it over this fabled 10M socket erlang server you keep talking about.

You might chose Java because:

* It is well understood and has a lot of mature libraries surrounding it.

* You can easily hire people to work on it.

* It is a stable language.

And so on...

I would summarize your original post like this: "I don't like Java, I prefer other things," which is fine as far as it goes, but then you basically say: "Therefore, everyone should also prefer the same things I do," which does not follow.

[1] I never particularly cared how many fps I can get on my machine, and I'm not that chuffed about my machine's geekbench score. IMHO this obsession with hardware metrics beyond diminishing returns is mostly a gamer thing.

- fast enough for most things without a lot of pitfalls/gotchas

- easy enough to read for most developers

- easy enough for most developers to pick up if they've never used it, even if they aren't exactly enthused by the idea of doing so

- supported enough that you'll never be the only person who is debugging something

- widely used enough to never be alone when you are trying to use it in unsupported ways

- has commercial support from multiple companies

Basically all the things that a lot of "enterprise" companies love.

Edit: formatting

Yes.

There is no need to engage the GP - let him rant about Go and JS. Java is still huge, for both legacy and new projects.

For context - I started as a C/Kernel dev. I also spent 2 years with Java on mission critical backend code. Both have their uses.

[0]: https://blog.codinghorror.com/the-magpie-developer/

So it isn't like just exchanging one for the other like that.

.NET Core 3.0 will fix some of the compatibility issues but not all of them, for example EF 6 will only be partially supported (VS DB tooling is not being updated for Core).

Telerik and the likes I'm not so fussed about personally. I suppose DevExpress is another one on that list. I think front end component libraries like Prime-ng/PrimeReact are probably the way to go for the future of UI development for Line of Business applications.

Overall I reckon in a couple of years there won't be much of those blockers left at all.

It's the ridiculously large JVM ecosystem that makes Java awesome, not the language.

I have love for Java, but I gotta say it mostly is because the ecosystem is pretty fantastic. So much open source stuff for so long means it's all just there and it all just works. There are some gaps though.

.NET ecosystem isn't bad. It's pretty good. There are some phenomenal libraries. But sometimes the gaps are painful. The lack of an open source (read FREE) integration framework is a big one for me. There is BizTalk but that's commercial and probably expensive. Same with scheduling libraries. HangFire looks great but it's paid. A lot of the really high quality stuff you have to shell out for which when you're just hacking in your own time is not feasible. That being said there are open source libraries and some of them aren't bad. Lots of great stuff in general.

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

They also have a perpetual license. If you cancel after the first year, you can keep using the version that was current 12 months ago.

But the one thing missing in Java is anything like LINQ. I don’t mean the syntax I am referring to the idea of LINQ -> expression trees -> third party providers that translate LINQ to another language (sql, Mongo Query, etc.).

I do miss LINQ though. The Java options are all clunkier because the type system isn't nearly as flexible

  Person.Get(p => (p.Age > 65 && p.Sex == "M") || (p.Age > 63 && p.Sex == "F"))

  public List<Person> Get(Expression<Func<Person,bool>> expression)

You get full compile time checking and IDE supported autocomplete.

The Java code "looks" like they do the same because they generate code to simulate method references instead. It's pretty clever and Javas code generation support for Annotation Processors is excellent and makes it possible to do this in a cross-ide cross-build-system way

LINQ and JOOQ/QueryDSL all work on plain data objects with fields. But with Java you do it on a pseudo object generated from your existing classes

All of these years I've been beating up on Java for lack of something akin to LINQ. I guess I'll have to find something else to complain about.....

Also, .net is more of a “pit of success” language — Java with all its legacy baggage requires a lot more knowledge to avoid mistakes.

Can you give some examples, that wouldn't be equally applicable to Java?

As Hejlsberg explained, the problem with virtual-by-default is that every time one of your public methods calls another public method on the same object, it makes it that much more complicated to reason about your invariants. If the called method is non-virtual, then you're in full control, and you know exactly what happens. But if it can be overridden, then you need to define a contract for overriders to follow, and you can't assume that it does anything other than what's expressed in that contract (in particular, you can no longer call that method without ensuring that all class invariants hold, even if it's expensive). Furthermore, the overriders often also need to know which other methods on the class do or do not call this method.

In practice, this is so much hassle that not even the Java standard library does that. For example, given ArrayList, if you override add(), does that affect addAll()? The docs don't say. So in practice, the only things that are safe to override is what the docs say are safe to override... which is to say, exactly like "virtual", except it's not enforced by compiler. Overriding random methods often works, but is a hack not dissimilar to using Reflection to access non-public members - even if it works, you're relying on implementation details of the class.

Applets, JavaBeans, and CORBA. What a loss.

> Besides being owned by Oracle, which is enough of a reason to never use Java ever again,

That stopped being an issue years ago. OpenJDK is a thing, you know?

> Java on the web is dead,

I don't think you have any idea about the hundreds of millions of lines of Java that power the web as you know it today.

The rest of your post is filled with equally uninformed claims but I'm going to stop here.

>> I don't think you have any idea about the hundreds of millions of lines of Java that power the web as you know it today.

Presumably they meant Java in the client, not the server.

Android?

Which were absolutely everywhere at the turn of century.

http://teavm.org/

Well, that's seeing the glass half full.

OpenJDK was complete garbage in the java 6-7 era, less than 5 years ago. Pretty much every major java software was requiring to install the Oracle JDK. Nobody would accept a bug or a support issue if it happened with the OpenJDK, which was the first question to be asked. And that wasn't fear mongering, java applications that worked perfectly fine just didn't work on the OpenJDK.

It is better now. I personally haven't seen an OpenJDK JVM crash in a while.

If Oracle's ridiculous interpretation of API copyrights holds up, they have a kill switch for OpenJDK.

https://www.youtube.com/watch?v=ZYw3X4RZv6Y&feature=youtu.be...

Yes, Oracle, the company that sues people for breathing the same air owning Java is an issue.

Maybe I am uninformed, but you haven't made a good case that there's any truth to that.

I think my question is, do most Java developers really know what goes outside of their window? Every language has a good story for web apps these days. The web is ubiquitous. You can write in Phoenix, Cowboy, Rails, Sinatra, Express, "net/http", Django, Laravel, Flask, Rocket... Java is literally middle of the pack at best. So that's not a compelling reason to use Java. So then we have to look at the rest of Java. Is there anything else in there that would make it better for web dev than a simple Go/Ruby/Python/Javascript/Rust/Elixir app? No? Ok, then let's not use Java. Java excels at being mediocre at everything, but the best at nothing.

Ask Twitter how their Rails apps is holding on.

A warm JVM is faster than a greased millenium falcon.

There is a lot of software running in this world. Some of it is very long lived.

Other open implementations exist from Amazon, IBM, Microsoft, Zuul etc. And they are all using the JDK name which isn't owned by Oracle.

If Oracle were to die or become aggressive the Java ecosystem would just move on and not skip a beat.

For people actually working with JVM and the languages on top of it, nobody really is worried about Oracle. The way the licensing is set up, they just don't have enough power to coerce people to use their version. It would kind of be like the SCO case if they came after it. I think they went after Google for Android simply to protect their IP, and that one they even "lost" (which detracts also from their possible future lawsuit on enforcing Java licensing)

The only reasonable alternative is C#. But it has to go a long way to reach Java's level of stability and trust on non-Windows servers.

In a high-skill rockstar team, dev time is by far the most expensive resource. In a startup environment, using your dev time wisely is the difference between a unicorn and a failed business. Nobody gives a fuck if your route handler executes in 1ms or 20ms. I'll gladly pay the 20x hosting costs if that will get my feature out to customers a week earlier.

i don't know why this comment was downvoted so much. i fully agree with every point that LASR makes. if you disagree, i'd like to see your counterpoints please.

For browser or Node.js, TypeScript is the way to go IMHO. Node.js and it's ecosystem have it's issues, but TypeScript is quite nice and a considerable improvement over JavaScript, while being close enough to JS where it fits nicely into the ecosystem. Only downside is that it adds a compile step that can potentially grow to be time-consuming.

I feel bad for people trying to write in other languages and manually re-inventing dozens of features the JVM ecosystem just gives you for free. In many ways, the whole container-push has been essentially people trying to achieve what the JVM already gave you (isolation, cross platform, etc etc). I still don't see anything equivalent that doesn't impose huge burdens of complexity (which java does have but it's a known quantity with two decades of maturity).

Google did containers in Borg many years ago, and many of its servers are written in Java.

When I stopped caring about POSIX.

or, they are more concerned with shiny new tech rather than using a mature and well-tooled out stack that doesn't sound sexy. I for one, don't need sexy tech - i want my app's domain to be the shining star, not the tech stack.

It is true that for smaller, less demanding software, there are many alternatives, but except for a very short period (~2000-2005) Java never dominated that kind of software. Early on people used VB, FoxPro and Delphi for that stuff, and later PHP, Python and Node.

Even with Rust, Go, and .Net core out there it's really hard to beat Java's battletested libraries/frameworks and excellent tooling. Java is still very relevent today and will probably still be for a very long time.

Also, funcitonal programming is a style of programming, not a collection of features. Just because you have a map and sort method and a hacked in lambda syntax doesn't make Java anything less than OO. Multi-Paradigm usually means one paradigm with a bunch of extra crap in there to make bike shedding easier.

Go can't even get it's packaging story straight and once again doesn't have generics which makes 'functional' programming a no Go;)

I actually really like Clojure (really I just love Lisp).

Go also has modules now.

Maybe not fully functional programming, but something that's quite pleasant to work with to be sure.

And it requires acres and acres of generated code, a custom runtime dynamic type system, whacky module names for compatibility instead of a reliable build system like maven, to make the thing work at all. Kubernets is a multi-megaSLOC advertisement for the virtues of Java as an ergonomic experience.

If it had remained in Java it could be incrementally ported to Kotlin. God, what I wouldn't give for that.

Part of the reason big businesses were able to abuse enterprises with their abominable Java server stacks is because corporations were slow to trust open source. But developers persisted and open source became too compelling to ignore, creating the upward pressure to embrace it and break the bloated and overpriced enterprise app server's stranglehold. This likely prevented the demise of Java that you suggest has happened.

In fact, when it comes to enterprise these days, you're pretty much either a Java or a .NET shop.

You'd rather use wasm to write c to talk to javascript apis? Your case against Java might be more compelling if it wasn't so gross itself.

I use all those languages too. Use the right tool for the job. Don't be dogmatic. And don't disparage others.

Would I start a new project in Java? Probably not. But I might reach for other jvm languages that were mentioned elsewhere. I'm definitely not too cool to work on an existing Java project. It's fine.

I still use Java a lot for application servers[1] and enjoy it.

I've also used Go, but I wouldn't want to try and implement, say a non trivial REST server with it.

I don't have the time to code everything from scratch, or to use an immature Go library or framework for example, when there are perfectly good ones in the Java world.[2]

Perhaps it might be best to just see languages as tools, and that each language has a purpose.

Java is old, so what? Lots of people derive value from it, and it's very stable.

You might be glad that banks use it, instead of immediately jumping on whatever languages you mentioned above. At least it manages to do boring things like keep you accounts relatively safe from hackers.

[1] https://www.dropwizard.io/1.3.9/docs/

[2] And yes, for that kind of application, unchecked exceptions are way more convenient than thousands of lines of if err != nil all over the place. And annotations in Go are an afterthought and it shows.

I'd suggest updating your misconceptions regarding Java before posting Yet Another Tirade about it.

E.g. the Javascript module/npm ecosystem is an absolute mess compared to any sane package/project description system, yet few people would disqualify JS for it.

Yeah, those poor devs with a rock solid, best of class, platform to write code on, with tons of libraries and tooling.

>Java no longer runs everywhere

It still runs everywhere where it matters. Nobody really cared if it could run on crappy smart tvs and other such BS SUN tried to push it. 99% of Java use has been for server work and enterprise development, and it remains there.

And on mobile, well, Android uses basically Java with a name-change.

>Java on the web is dead

Java on the web (Applets) was DOA, and has been dead for over 15 years. It's not gonna make any difference now.

>and you can now write ubiquitous apps in basically every language

Which again is neither here, nor there. People have been using Java as a very strong language for backend systems, application server side work, and enterprise stuff. And those deploy on at most one OS 99% of the time.

They don't use Java like e.g. Electron or QT. The only Java apps that are like that and are mainstream are basically IDEs.

>There's no reason to deal with the JVM and it's domain knowledge when you can write a nimble Go app for your backend and a Javascript app that will run on mobile, web, or desktop

Whatever.

>A VM language? You mean v8 sandboxing and web workers; WASM which lets me write C, C++, and Rust all of which can talk to Javascript APIs

How hipster. Meanwhile others do real work on Java, with finetuned GCs, mature libraries, and so on. I'm not sure where you've seen all this "WASM and Rust", as both are not even blips in production compared to Java adoption -- and wont be for a while, if ever.

>All of my services are stateless and ephemeral

Mine don't care much for the latest fads, so there's that.

>On the cloud it gets even worse for Java. Why use a meaty framework like Swing when I want to just spin up a bunch of micro services, or have an API gateway kickoff a bunch of lambda jobs.

I'm not ever sure what Swing has to do with a Cloud java deployment. Perhaps you meant Spring, but even so, it doesn't make sense.

And of course with Java you can always use something like Vert.x, which tops the performance charts for microservice work -- so much so, that the others are not even on the radar.

>Java also took OO in so many terrible directions.

2010 called, they want their arguments back.

Also, not sure if you've noticed, but Java is still in the top 3 of most in demand languages (along with JS and Python).

Perhaps your ideas about its death are premature, if not deluded?

You have me convinced.

(And of course you skipped all the non-whatever points where you didn't have anything to respond).

And from this it seems to me you are somehow biased against the java ecosystem without hands-on experience to base your opinions on.

Java basically copied (and cleaned up a bit) C++ OOP of the time. Don't blame Java for any bad direction, it was following rather than leading.

There are also thousands of companies which are focused on Java, Java, and more Java. Many schools are also geared towards churning out more Java engineers, and people who don't yet know Java want to learn it because there are still so many Java jobs around.

That's a lot of inertia to overcome.

It's still true, though, but it's a compliment. Most languages have no hope of ever becoming the next COBOL. For Java, it is practically a certainty, even if Oracle were to pull the plug on it this very moment. It's too big and too important to die.

However I really dont see what benefits Spring brings. Spring Boot is great for prototyping and trivial apps, but for big systems you really want to break it apart. DI is better done with ServiceLocators. Some of the smaller libraries like Spring Shell, Spring Mobile are junk. And I still see lots of XML config that you dont know if they'll fail until you try to run them.

What does that mean? What does Spring Boot give me that Tomcat doesn't?

Tomcat is a servlet container that implements various Java EE specifications, such as the servlet spec, jsp spec, etc.

Spring encompasses many different libraries. The most widely used is probably Spring MVC, which builds on top of the servlet spec to make building web applications easier. After that Spring Security is probably most widely used, which adds things like auth, CSRF tokens, etc. Spring Data and Spring Cloud are also somewhat popular. There are many more Spring libraries, but I have little to no experience with them.

You can really give or take what you want here. You can use Spring MVC with Spring Data, or Hibernate, or JPA, JDBC, or whatever you want really. One place I worked used Spring MVC with home grown security and ORM layer.

Spring Boot brings "convention over configuration" to Spring. Because Spring is so configurable it can take a lot of boilerplate. Spring Boot removes much of that boilerplate for certain use cases and has, generally speaking, more user friendly defaults.

Spring Boot also runs off a server embedded in the jar. That's why you can "just run" it. You create a "Main" method. You can choose from several embedded servers, including Tomcat. But this isn't exactly special for Spring Boot because you could do this even if you didn't use Spring Boot.

Most of my apps just code against the servlet spec with a JDBC connection to a MYSQL database, sometimes with JSP. Perhaps because most of my business logic lives on the client I've usually found that plain servlets + plain JDBC calls were sufficient

Although I've found it pretty straightforward to configure servlets in Tomcat I can see that Spring MVC makes it a little easier. Maybe the introduction of a framework 'Model' is also an advantage - I'll investigate further.

Regarding Spring security - would I use this package if I was implementing a "Login with Email/Password or Facebook or Google" feature to a website?

Not forgetting that dependency injection -- the original core feature -- is just the bee's knees.

I work for Pivotal, but not on Spring. But I've definitely grown to appreciate it more and more over the years. I deeply miss it when mucking about in Golang.

Any practical advice for making this happen? I have a Spring Boot system I wrote and am responsible for, but now I just want the pain to stop.

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