In the late 2010’s, Wall street java jobs were informally categorized into core-java vs J2EE. Nowadays “J2EE” is replaced by “full-stack” and “big-data”.
The typical core java interview requirements have remained unchanged — collections, threading, JVM tuning, compiler details (including keywords, generics, overriding, reflection, serialization ), …, but relatively few add-on packages.
(With the notable exception of java collections) Those add-on packages are, by definition, not part of the “core” java language. The full-stack and big-data java jobs use plenty of add-on packages. It’s no surprise that these jobs pay on par with core-java jobs. More than 5 years ago J2EE jobs, too, used to pay on par with core-java jobs, and sometimes higher.
My long-standing preference for core-java rests on one observation — churn. The add-on packages tend to have a relatively short shelf-life. They become outdated and lose relevance. I remember some of the add-on
- Hadoop, Spark
- functional java
- SOAP, REST
- Protobuf, json
- Gemfire, Coherence, …
- ajax integration
- Hibernate, iBatis
- JMS, Tibco EMS, Solace …
- XML-related packages (more than 10)
- Servlet, JSP
None of them is absolutely necessary. I have seen many enterprise java systems using only one or two of these add-on packages.