3 ms·

> Looking back, the main problem was probably Spring, Glassfish, IOC, XML, Maven and numerous other "EE" things that java-people assumed were a must 10 years ag

• algesten 10y ago
  > One of the most popular frameworks - Spring Boot - includes many of these now. It's fairly light, contained, works well in Docker. Maven is pretty straightforward for simple things, IOC is optional. I haven't exercised it heavily though, but what's wrong with those things? It's hard to pinpoint one single thing that is the problem, but I suppose I can summarise it with that I don't think java is especially productive. The language is rather verbose in modern terms (compare it to something with type inference like swift or rust). The startup time of a spring-driven project used to take an age (used to be XML-parsing, then annotations), especially if housed in an app-server like jboss or glassfish, but also tomcat, jetty (compare it to how quickly an express-app in nodejs starts). This in turn affects development time. Dealing with (somewhat) modern dataformats like JSON is is incredibly verbose (GSON, built-in, etc nothing compares to languages with what swift calls "subscribe", i.e user defined obj.blaha accessors instead of obj.getJsonValue("blaha")). Dealing with older dataformats like XML is incredibly verbose (never mind the gazillion XML <-> Object mapping frameworks with source generation pre-compilation stages, insanely long namespaced method calls, etc). The static type system is actually just making the code very verbose without helping much because pretty much anything can still be null (again compare with rust/swift where static types + optionals means compilation actually provides some level of security). It had massive corporate backing (Sun/Oracle) to instill the idea that pretty much anyone can learn programming as a trade (I've worked extensively in India with outsourced java-programming, and the quality of code produced by some people labelled "senior" is absolutely shocking. This is not unique to India however). Things like ORMs (Hibernate and EJB) meant most people just forgot how RDBMs work and threw crazy hardware at the persistence layer to compensate for lousy performance (ORMs are typically fine, users not understanding how they work are the problem). It's owned by Oracle. I could probably go on, but it's bed time.
  • paulmd 10y ago
    > The language is rather verbose in modern terms (compare it to something with type inference like swift or rust). Maybe if you never have to work with anyone else, or maintain your code. Static typing is a plus, not a minus. Right now I'm working in a legacy codebase where everything is passed as Object or String within the main logic code, and let me tell you it's hell trying to figure out something as basic as what type of object you're working with. > The startup time of a spring-driven project used to take an age (used to be XML-parsing, then annotations), especially if housed in an app-server like jboss or glassfish, but also tomcat, jetty (compare it to how quickly an express-app in nodejs starts). This in turn affects development time. Startup time for thin servers like Jetty is virtually zero. The fatter servers definitely do take more time to start up, but they also tend to be used with complex applications that have more stuff to configure, so that goes hand in hand. For a point of reference here, I'm at about ten seconds from startup to page load with a 110 MB application that loads all kinds of redundant and useless code (which is why you let Maven do its thing instead of using fat jars everywhere). If you're properly configured, though, you can do "code hot-swapping" (call 1-800-TOMCAT for sexxxy singletons in your area!), which will just inject a new function body into the server, so you can avoid having to re-deploy the whole application over a single changed line. > Dealing with (somewhat) modern dataformats like JSON is is incredibly verbose (GSON, built-in, etc nothing compares to languages with what swift calls "subscribe", i.e user defined obj.blaha accessors instead of obj.getJsonValue("blaha")). You're looking for Jackson. See the first example, "Full Data Binding". http://wiki.fasterxml.com/JacksonInFiveMinutes http://wiki.fasterxml.com/JacksonInFiveMinutes If you need a little more flexibility than just "this object but serialized as JSON", you can control the binding with annotations or XML. > Dealing with older dataformats like XML is incredibly verbose (never mind the gazillion XML <-> Object mapping frameworks with source generation pre-compilation stages, insanely long namespaced method calls, etc). So you don't like writing it yourself (SAX parsers are verbose but fast and powerful), and you don't like the tradeoffs of letting tools do it for you, ok then... JAXB isn't really as bad as you're making it sound though. And the rule of thumb is that virtually any awkward block of code can be stuck behind a convenient helper method and only touched directly if there is a very compelling reason. > The static type system is actually just making the code very verbose without helping much because pretty much anything can still be null (again compare with rust/swift where static types + optionals means compilation actually provides some level of security). Sure, object references can be null. Get over it, that's like CS 101 stuff right there. What do you think happens if you use an undefined variable in Python or Javascript? If you really want to be sure that an object isn't null, just use "assert myObj != null;". Again, static typing actually is a huge plus when you're looking through unfamiliar code and trying to figure out what it does. "What type of objects am I working with" is a fundamental question that you always need to know. > It had massive corporate backing (Sun/Oracle) to instill the idea that pretty much anyone can learn programming as a trade (I've worked extensively in India with outsourced java-programming, and the quality of code produced by some people labelled "senior" is absolutely shocking. This is not unique to India however). > Things like ORMs (Hibernate and EJB) meant most people just forgot how RDBMs work and threw crazy hardware at the persistence layer to compensate for lousy performance (ORMs are typically fine, users not understanding how they work are the problem). These are personal problems (or actually, Personnel problems). No, Java doesn't somehow make chopshops able to magically turn out good code. No, it will not fix your co-worker who just doesn't understand how to write performant code. But he would be writing shitty code in Python or Ruby too, and you would have a whole set of extra problems on top of that. > It's owned by Oracle. Reminder: Google won their lawsuit. Oracle owns their Java implementation. They can't stop other people from reimplementing the Java API, however. OpenJDK seems to be fine. I run it on Linux environments because Oracle JDK isn't in the repos, and it's pretty much a drop-in replacement in most cases.