Have you seen FizzBuzz: Enterprise Edition ?
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
One can write a Java application and never touch XML, use AbstractFactoryWhateverTheFuck, and write sane, clean code. I've done so for years, worked on green and brown-field projects. I've also written, maintained, and modified monstrosities in Java... as well as C#, Javascript (front and back-end), PHP, Python, and plenty more.
Java is not the Hot New Thing™ and never will be. It's also not always the answer, but for a run of the mill application running on a web-server you're going to have a hard time finding a better language and ecosystem that will keep on trucking and be reasonable to work with.
case class Person(name: String, age: Int, likes: List[CustomObject]) //simple data object
implicit val personFormat: Format[Person] = format[Person] //this creates a "Format[Person]" with serialize/deserialize methods
Because of implicits, most of the time I write that one line above, and an HTTP handler as a simple function from (Person => HttpResponse) and dont even think about the serialization/deserialization. And that one line is not an opaque abstraction, it is very customizable if you need it to be, and all via code not config.
Using Jackson in Java can get much more complex because annotations and XML files creep across the whole code if you want compile time generation. I think this is directly because Java's inspect/generate code at compile-time is not as powerful as macros.
What, in your mind, is a good language that needs no framework?
If you find yourself doing this, it is a clear indication that the software design is failing to abstract properly or at all.
(I'd argue that the industry in general has a terrible ratio of "coders" to people who can design programs, thus you're much more likey to come across poor designs than good ones. Beware of this when judging programming languages.)
I believe, it is an indication that people tried to fix all the leaks in the abstractions, which turns the abstraction into an ugly twin of the stuff it tried to simplify.
ORMs are a good example. They start easy and simple, but lack various features of full SQL. If you start a new project, the ORM is fine. At some point, you are forced to use plain SQL, which clashes horribly with the ORM concepts. Thus the desire to extend the ORM. Over time more and more features are bolted on and the complexity grows.
There's a really bad trend in the industry of choosing libraries or tools based on trying to improve your resume, rather than trying to find the best solution to a problem.
I've yet to see a good one.
Often ORMs fail to implement JOINs efficiently.
Every ORM fails to give you a powerful query language: if they had a powerful query language, someone would write an ORM for the ORM, because the reason ORMs exist is that "SQL is hard", as the doll says, and any powerful query language will get the same treatment. But SQL is not really hard, and not having SQL eventually means you pay a huge price.
And then there's things like LDAP, which are absolutely awful. LDAP's object naming scheme has no canonical text representation. Let that sink in. And that's not even the main problem -- forcing your database to be hierarchical and a collection of objects, with no standard relation/pointer type, is. (Yes, Active Directory has an Object DN type, I'm aware.)
Just say NO to ORMs.
It's not true that people who know SQL always prefer using it to using an ORM. In one of my prior jobs we had strict controls on the queries that ran in production for performance reasons. We screened all of the query plans the planner generated, but we also used an ORM. Sometimes we needed to work around or even reimplement the queries that used to be in SQL due to niche features like index hinting or the HAVING clause. And yet usually we used the ORM because it was more concise and reduced manual mapping of columns to fields.
[1]: https://en.wikipedia.org/wiki/Object-relational_impedance_mi...
Java 8 and the current ecosystem can be incredibly lean and devoid of high levels of abstraction. Like today how I took the lovely Sinatra inspired http://sparkjava.com/ out for a spin. I think if Java can shed the memory of it's horrible past (and the enterprise space was truly bad) then it has a lot to offer developers these days.
Also, i think new grads tend to only know how to make things dry via abstraction (not considering the trade offs) and b/c of javas popularity and oop as a buzzword, always did it via inheritance.