[austincheney]

I have worked in Java shops my entire career (Travelocity, Orbitz, Expedia, Southwest, Bank of America) and have lots of pain points. In these cases Java is used to prop up a web server and typically with Spring.

Pain points:

* Stack traces seem to run to 500+ lines and nobody reads them.

* The processes, release management, and integration of code in a Java environment is glacial slow and obtuse featuring very low automation and many large teams of dev ops. The very idea continuous deployment is absent. Code releases occur at regular intervals quarterly or monthly if you are super fast and it feels like moving a continent. All of that slowness and super man power also applies to everything else not written in Java like riding on the back of a retardant elephant.

* Java applications running enterprise web servers are monolith beasts like the Great Wall of China wrapping the Pacific. Refactoring in those applications feels like inventing a new language while sinking in quicksand. Writing a JavaScript application in a massive MVC framework feels like that too but Java is orders of magnitude worse.

* What I really don’t understand is that Java is such a fast language but large enterprise web server applications written in Java always feel so slow in user experience in production. It just feels like something from the late 90s. That slow becomes the baseline experience to internal development by which all user experience ultimately suffers. There is no reason pages from these servers should take 5-20 seconds to fully load in the browser even though the page is a light smattering of static text with sprinkles of CSS and JS. I have an application in TypeScript that emulates the front half of an operating system and it fully loads in the browser in 0.3-0.8 seconds (averaging around 0.65 seconds).

[js8]

> What I really don’t understand is that Java is such a fast language but large enterprise web server applications written in Java always feel so slow in user experience in production. It just feels like something from the late 90s.

My personal suspicion is that the programming style used in Java (OOP and patterns) together with the fact that everything is a reference, and everything is implemented in Java itself way down, kills the cache locality, which is the thing that makes modern computers fast.

Yes, you can write fast Java programs, if you keep abstractions to a minimum, use arrays rather than objects when allocating, and take advantage of the JIT compiler. But these are more lab conditions (which are great for benchmarks) rather than the real world conditions. I think finally having a proper record type in Java will help to fix this.

[twic]

Shitty, poorly-run corporate behemoths (a) are shitty and poorly-run and (b) use Java, because it's an industry standard. You are making the error of thinking that the latter consequence causes the former.

[js8]

Interestingly, the old COBOL/CICS/DB2 stacks do not seem to have this problem (and they are run pretty much only by corporate behemoths). Why is that?

[ajuc]

less hardware to throw around = better (simpler) codebase

[q-big]

> Shitty, poorly-run corporate behemoths (a) are shitty and poorly-run and (b) use Java, because it's an industry standard. You are making the error of thinking that the latter consequence causes the former.

Other programming languages make it "more inconvenient" to apply such managament/programming practices.

[ajuc]

> Stack traces seem to run to 500+ lines and nobody reads them

ok, you have a point here :) when you have libraries for filtering stacktraces you know something is wrong

> the processes, release management, and integration of code in a Java environment is glacial slow and obtuse featuring very low automation and many large teams of dev ops. The very idea continuous deployment is absent

that is the exact opposite of my experience - maven infrastructure beats anything C++ or Python have, and in every Java project I worked on we had CI (mostly BitBucket+Jenkins but I've also seen Apache Continuum and Team City and we had CI even back in svn/cvs era).

> large enterprise web server applications written in Java always feel so slow in user experience in production

Also not my experience, I've worked on an intranet app for warehouses that used jboss 4, jbpm 3 and plsql at the backend and a very small custom c# client running on remote Windows CE terminals. We had transactional and persistent business processes drawn as graphs invoking PL/SQL on the server, it was pretty nice. And the full roundtrip between pressing a key on a remote terminal and rendering the received response was under 150 ms. That's for all the layers: - c# client -> intranet -> SOAP on jboss -> EJB3 -> jbpm -> hibernate -> JDBC -> PL/SQL and back

And it was around 2008 - in the age of spinning disks :) Certainly it was good enough for us and actually faster than previous simple code that we were replacing (remotes telnetted to a C++ text-only server that connected to the same business logic in PL/SQL). ORM cache wins covered all the performance loses caused by additional abstraction layers.

We didn't use html/js/front-end templating engines tho, at the time most people used JSF or similar and it sucked. We had a custom XML protocol that was rendered by the C# client and it was very fast.

Of course it wasn't that demanding - under 500 users all on the same local network. But without any thought spent on optimization (other than enabling 2nd level cache in hibernate) it was a pretty good result.

> There is no reason pages from these servers should take 5-20 seconds to fully load in the browser even though the page is a light smattering of static text with sprinkles of CSS and JS.

well yeah, something's wrong. I bet on data layer or passing each request through 20 microservices on different continents (this is the most recent fashion in server-side programming and it sucks).