3 ms·

"""Over-complexity is common in the Java space.""" Yes, in a SPECIFIC area of the Java space. There is a huge group of people who believe that J2EE and its co

by st3fan 18y ago

"""Over-complexity is common in the Java space.""" Yes, in a SPECIFIC area of the Java space. There is a huge group of people who believe that J2EE and its complexities are a major pain the ass. That is why great frameworks like Spring, Guice or Stripes exist. Sun loves you when you use J2EE/JSF/EJB/JMS/JWHATEVER. But there are serious alternatives that are more lightweight, easier and less intrusive. Of course you will not add value (read: buy into) to the Sun Enterprise Ecosystem :-) Staying away from (most) 'Enterprise' Java standards has worked very well for me. I really enjoy working in Java.

jm4 18y ago
Have you seen Spring lately? I'm not sure it's much of an improvement. Stripes is nice as far as Java web frameworks go, but it's fairly simple and this is where the problem lies. Someone comes up with a tool that's great for a specific job. Later, someone else comes along with a slightly different problem and the tool changes a little to accomodate them. Then a few others. Before you know it every feature under the sun is added to handle every possible scenario. Now you're stuck with crappy middleware. It does a decent enough job after you configure it properly and strip it down to only the modules that apply to your specific problem. It's not so bad because you've been using it for a while and you know it inside and out. Plus, it can be used to solve everything. It can probably even cure cancer with the right module and proper configuration. But sooner or later someone else comes along, decides this nifty universal tool is a steaming pile of shit and sets out to invent something simpler and less bloated. And it will only be better because it doesn't have everything, including the kitchen sink, bolted onto it. It's focused and lean. But then someone comes along with a slightly different problem than what it was intended to solve and the hot new framework with all the buzz starts going bad just like the last one. Look at Stripes. It's just a better version of Struts2 which was based on Webwork which was intended to be a better Struts 1. Eventually, more and more cruft will be added to Stripes so it becomes as bad as what it was designed to replace and someone will come along and invent a better Stripes. In my opinion, this is the biggest problem with frameworks. Many developers prefer to have a universal tool instead of having several that are good for different jobs so we end up with this cycle of cruft.
- lallysingh 18y ago
  Just finished a Struts 2/Spring app. Hey, I had to cover tuition somehow. The biggest problem with the entire stack is that every piece would rather overengineer a solution to a small part of the problem, instead of giving us a simple solution for the whole thing. Look, just have a stock web.xml, and don't touch interceptors. Instead, put together a single, coherent system for dispatching a URL to the right object, and the same for security requirements. If you need more, abstract once, there for the URL. That's it. After months of reading through crap documentation (Hibernate, I'm looking at you), it's obvious that the frameworks are 90% of the problem, and your actual set of requirements are the last 10.

by st3fan 18y ago

jm4 18y ago

Have you seen Spring lately? I'm not sure it's much of an improvement. Stripes is nice as far as Java web frameworks go, but it's fairly simple and this is where the problem lies. Someone comes up with a tool that's great for a specific job. Later, someone else comes along with a slightly different problem and the tool changes a little to accomodate them. Then a few others. Before you know it every feature under the sun is added to handle every possible scenario. Now you're stuck with crappy middleware. It does a decent enough job after you configure it properly and strip it down to only the modules that apply to your specific problem. It's not so bad because you've been using it for a while and you know it inside and out. Plus, it can be used to solve everything. It can probably even cure cancer with the right module and proper configuration. But sooner or later someone else comes along, decides this nifty universal tool is a steaming pile of shit and sets out to invent something simpler and less bloated. And it will only be better because it doesn't have everything, including the kitchen sink, bolted onto it. It's focused and lean. But then someone comes along with a slightly different problem than what it was intended to solve and the hot new framework with all the buzz starts going bad just like the last one. Look at Stripes. It's just a better version of Struts2 which was based on Webwork which was intended to be a better Struts 1. Eventually, more and more cruft will be added to Stripes so it becomes as bad as what it was designed to replace and someone will come along and invent a better Stripes. In my opinion, this is the biggest problem with frameworks. Many developers prefer to have a universal tool instead of having several that are good for different jobs so we end up with this cycle of cruft.

lallysingh 18y ago
Just finished a Struts 2/Spring app. Hey, I had to cover tuition somehow. The biggest problem with the entire stack is that every piece would rather overengineer a solution to a small part of the problem, instead of giving us a simple solution for the whole thing. Look, just have a stock web.xml, and don't touch interceptors. Instead, put together a single, coherent system for dispatching a URL to the right object, and the same for security requirements. If you need more, abstract once, there for the URL. That's it. After months of reading through crap documentation (Hibernate, I'm looking at you), it's obvious that the frameworks are 90% of the problem, and your actual set of requirements are the last 10.