I don't see how Java is more complicated than any other programming language. It certainly is not one of the more difficult ones. Assembly is complicated. C is arguably complicated. Java being complicated? I disagree.
Assembly isn't complicated. The instruction list for most processors is small and easy to remember, because it's mostly variations on the same few operations.
It gets unwieldy if you try to build complex data structures, because you literally have to do everything the compiler would usually do. So if you're trying to build an incredibly complex machine with lots of objects and interfaces, it will take you a very long time.
Java is complicated because the culture is complicated. It's not just a language - it's a set of architectural practices and expectations, some of which are questionable, combined with a unfeasibly large ecosystem of libraries and add-ons.
So it's easy to learn the basics, but it's not so easy to get to the point where you can start producing high-quality maintainable code within a typical working context.
Assembly and C are dead simple compared to Java. The C reference manual is about 200 pages, if I dropped the Java reference manual(s) from a building it would create a sizeable crater.
Assembler is simple like lego is simple: the basics are tremendously easy to understand but the distance between the basic elements and the problems you're trying to solve is very large.
The more 'batteries included' something is the more time you'll spend learning about the eco-system and less about the language per-se.
> Assembly and C are dead simple compared to Java. The C reference manual is about 200 pages, if I dropped the Java reference manual(s) from a building it would create a sizeable crater.
I don't think that's a fair assessment of Java.
The full specification for version 8 is actually 788 pages, so 500 more than C, but you could reasonably argue that of those at least 100 are dedicated to specify what in C is simply undefined behavior and probably another 100 are dedicated to the memory model. The other 300 hundred would be a reasonable overhead for specifying classes and class loading.
You can say a lot of bad things about Java, but it could very well be the best specified language around; the spec is actually very readable, leaves no room for doubt and actually treats that thing called multithreading that still has no citizenship in the C language. You can't say that of a lot of languages.
EDIT:
I took the time of checking the C11 standard PDF (actually the latest available draft, as the ISO asserts copyright on the standard and you can't get it for free). It's 701 pages.
But at least C11 has <threads.h>.
I just picked up my fairly dog eared K&R for that reference it's 226 pages (first edition). Yes, the C spec grew over the years, but the Java docs were huge right when it started out. I remember buying the full set and it weighed more than I could easily lift up the stairs to my office. All in all it amounted to a few thousand pages. This included the docs on the VM and a bunch of other stuff that you might not need (but which I did need).
The C standard library was a relatively small affair reflective of the way UNIX was built, a couple of well thought out interfaces combined with a lot of freedom (and enough rope to hang yourself several times over).
The Java standard library was absolutely huge and extremely hard to make headway in because each and every part of it seemed to be designed by a committee rather than by an individual (or two).
It's interesting that you try to compare simplicity via manual length and say in the same breath that assembly is simple. Assembly language manuals easily dwarf most programming languages: x86-64 is a whopping 3439 pages (of which ~1500 pages is the instruction set reference). And before you say that's just because x86 is unnecessarily complex, ARM is 1138 pages, PowerPC 640 pages. By comparison, the JLS is only about 800 pages, C11 sans library about 450, and C++14 sans library about 500.
The bricks are simple but there are many of them. When I say that assembly language is simple I mean exactly that. The language is simple. If you know what one mnemonic does you'll be able to infer the existence and function of a whole bunch of others since they're usually organized around a matrix of operations and locations to be operated on. Of course a manufacturer would document each and every instruction separately but if you understand the logic behind an instruction set then you have a much easier time of it.
The x86 set, well, let's not go there, it's just too painful.
Assembly may not be simple, as in 'very little language'. Assembly can be thousands of different language elements. But assembly is simple as in 'very little variation'. There are maybe a dozen addressing modes. There may be 100 or more instructions. When you multiply them, you get large manuals.
And assembly is simple as in 'primitive'. The atoms of assembler are instructions, and even they may be clustered into only a few groups i.e. arithmetic, branch.
I find the resistance to learning assembler is mostly fear. When debugging I very often resort to assembler display, even for machines that I'm not familiar with. I can learn the gist of it in a few minutes just by looking at a little generated code. And there's nothing like the actual machine instructions to find what really caused an exception.
General problem of Java: It lacks decent onboarding.
I disliked java after school and was convinced I was hopeless so I didn't even bother to apply for Java jobs. Then I was recruited into a Java position and picked up the necessary skills to work during my first 4 days and improved steadily from there, but it only worked for me because I was on a good team.
Now it is me who helps people using Java more efficiently : )
It gets unwieldy if you try to build complex data structures, because you literally have to do everything the compiler would usually do. So if you're trying to build an incredibly complex machine with lots of objects and interfaces, it will take you a very long time.
Java is complicated because the culture is complicated. It's not just a language - it's a set of architectural practices and expectations, some of which are questionable, combined with a unfeasibly large ecosystem of libraries and add-ons.
So it's easy to learn the basics, but it's not so easy to get to the point where you can start producing high-quality maintainable code within a typical working context.