How practical is to plan for a change in tech stack after spending 10+ years in one?

Are you used to writing Apex? Have you tried writing anything you’ve done in Apex in Java?

I am not an expert. I mentored some interns who were writing some localization fixes in Apex, and had to help debug a few things. There are for sure differences. I know off the top of my head multithreading (or lack thereof in Apex) is pretty significant. Especially in a lot of backend code, efficiently splitting work across threads to improve per request (or other work unit) latency is pretty critical.

You can’t just decide you’re going to learn multithreading in Java and do it. I will say Concurrent Programming in Java by Doug Lea is a good book, but I don’t know if it is good for beginners in concurrency. Maybe it is, I just haven’t approached it from that angle.

Otherwise I just don’t know what modern Java features are available in Apex. Streams, Optionals, lightweight threads (again, really concurrency-specific), and other features are in common use now, and I don’t know which you’d be exposed to in Apex.

I would say that while a lot of backend work is still Java, Kotlin is making significant moves to supplant it in most settings where Java has been used (as it’s “first class” execution environment is the JVM). I don’t know that investing in learning Kotlin now will be a faster route to achieving your goals, but might be “different-er” from Apex and avoid you spending too long thinking only in terms of what you are used to.

I think it is practical to make the move, but you may have to really break yourself of what you know. Most Java code isn’t directly accessing data, UI interactions will be very different from what you’re used to (and I guess isn’t very relevant to backend work), and so on. That’s not a language issue, it is I guess the “platform”, where Salesforce is very insular.

My plan would be to start writing Java. Potentially setting up a server on your machine, and solving simple problems. Writing arithmetic programs, doing simple crud with a data store, etc. Focus on APIs where there is a request (JSON is still popular, could do protobuf), you do some work, and return the result to your client. From there maybe some GitHub projects could be some code to read and see how modern Java constructs are used to build high-concurrency services.

Is it possible to pick up Java back-end work at your current company? That's the best way to transition, do it internally. It is very hard (especially now) to convince employers that you're capable of not just joining them and adapting to their culture, but picking up a new tech stack concurrently as well.

I wrote a sort of playbook on how to switch stacks here: "How to transition from back-end development to distributed systems?"

What I will say though is that Java back-end is a pretty good place to be as Java is sort of everywhere. Java's a good language (though a bit old maybe, Kotlin and other more modern languages are taking market share as Lee mentioned), and it's been the primary language for me (and my dad) across my career.