If you want to make it easy for high schoolers, just don't use java in the first place...
(We've now switched to Lua, integrated with the official C++, but it's a lot more work behind the scenes.)
If you're using Java (or C++ or LabVIEW, to a lesser extent), you at least have a hope of posting to a forum and going "Hey, we think our robot should be doing X and it's doing Y, here's our code, any insights?"
If you use <bespoke language X> and your own custom bindings, you're on your own.
I've been making a living coding in Java for 10+ years
I'm a strong believer in types etc etc
I still don't think Java is a great language to teach programming lol
too much pointless boilerplate and abstraction to achieve the simplest things
lots of footguns and objectively bad standard practices built into the language and the native libraries
to me Python and Kotlin seem like probably better choices (though they too have massive flaws)
But idiomatic Kotlin is still too close to Java, they call it "direct programming style" and it's basically already obsolete
Null safety is great but the way they've implemented it with weird syntax like ? and ?.let is not great, it would have been a lot better to just have a regular Maybe type in the native library from the start. Like sure the nullable type is in some ways functionally equivalent, but it doesn't implement map, flatMap, applicative etc like a Maybe does, and when it behaves like it does, it's mostly kind of by accident, not by any real understanding of those operations (and, fatally, it's completely disconnected from map, flatMap etc on lists etc - those should be interfaces that everything that can be mapped, flatmapped etc on implements, not methods that get hurr durr added here and there, sometimes as a regular method called map, sometimes built into the compiler called let)
They've completely dropped the ball on error handling - they don't even know themselves whether the language or people using it should use sealed classes, exceptions or their shitty Result class (which, again, this is a solved problem, they could have just included Maybe, Either, Try etc in the native library from the start)
Coroutines and structured concurrency are powerful but their API is so extremely confusing and full of footguns that virtually no codebase using them ever uses them correctly to reap the benefits
I could go on - don't get me wrong, I love a lot about Kotlin and it's a massive massive improvement on Java but it's not a great language unless you run it with Arrow and learn to completely sidestep large parts of the language (just like you had to do with Java)
You can write code in it, but in industry almost everything I see is basically a DSL built out of annotations that tries as hard as it can to not involve writing actual Java.
When more of your application is annotations than lines of Java code, the language is probably a bad fit for the problem domain.
Java is "fine" in the sense that NBASIC was "fine." There's definite room for improvement in matching the abstraction to the problem domain.
Borland Pascal already had reasonable static types, classes, pointers, modules with a public API, and blinding compilation speed in the early 90s. All the basic building blocks to grok. Golang seems to be the closest modern-day approximation.
For me, it boils down to a choice between typed and "non-typed" languages, where the best typed option is Java and the best "non-typed" are Python or maybe JavaScript (NodeJS). Everything else is some combination of not mainstream enough, not powerful enough out of the box or requires too much knowledge to get started. Java and Python read like English, have most of what you'll need included and are very useful languages for students to get their first internships/summer jobs working with.