Havard Havard Havard Havard-Havard von Havard (![[info]](http://p-stat.livejournal.com/img/userinfo.gif){kind=small} wisedonkey) wrote,@ 2007-11-07 18:53:00 |
|
Attention Java webapp developers
The whole point of .war files is so that you have a simple deployable file that will work on any servlet container that implements the spec (i.e. all of them). The whole point of the servlet spec is so that an application written to the spec will work on any servlet container. One should not be required to track down weird dependencies nor should it be impossible to run a given servlet on an unbundled install of the same version of the servlet container included with the app tarball without hours of headaches. Sure, it's one thing to require a little minor configuration for a database, and it's certainly not outside of reason to require the person deploying the app to have the database pre-loaded with the schema and a base set of data. Something is completely broken if the poor sap that's deploying the application has to manually pre-configure the database, track down the jdbc driver for the database, oh and don't forget grab the persistence layer .jar files from elsewhere, downgrade from Java 6 to Java 5 or 1.3 (but not 1.4) simply because the author wrote the app The Wrong Way, and other horrors that shall remain unspoken.
Most apps are completely broken. Pretty much every single turnkey Java CMS blows goats if it even runs at all outside of the developer's highly mangled setup. Every other Java "CMS" is a framework. In other words, the authors are incapable of producing even a broken turnkey app.
The entire Java world is stuck on frameworks. There are actually frameworks that run on top of frameworks that run on top of frameworks. From what I've seen, apps built on frameworks, which are supposed to make writing apps simpler and faster, have more lines of code than those that were written directly on top of the HttpServlet class. When some application proudly proclaims, "AppFoo is designed using the DesignPattern paradigm on top of the Broken framework with persistence provided by SomethingDefective and implements SomeJavaStandard" it's best to run away. It's a clear sign the author concentrated on buzzword compliance rather than implementing Useful Features (read: something that works).
One of the few webapps I've touched that actually works without any pain is CentricCRM. It is a perfect example of how the Java Servlet platform should work. Even building and deploying from source was painless! Any minor misconfiguration during the build process would result in an error that explicitly stated what needs to be changed. The .war file Just Plain Worked.
My theory is that the broken "turnkey" software and frameworks are created to give Java developers and consultants jobs.
The whole point of .war files is so that you have a simple deployable file that will work on any servlet container that implements the spec (i.e. all of them). The whole point of the servlet spec is so that an application written to the spec will work on any servlet container. One should not be required to track down weird dependencies nor should it be impossible to run a given servlet on an unbundled install of the same version of the servlet container included with the app tarball without hours of headaches. Sure, it's one thing to require a little minor configuration for a database, and it's certainly not outside of reason to require the person deploying the app to have the database pre-loaded with the schema and a base set of data. Something is completely broken if the poor sap that's deploying the application has to manually pre-configure the database, track down the jdbc driver for the database, oh and don't forget grab the persistence layer .jar files from elsewhere, downgrade from Java 6 to Java 5 or 1.3 (but not 1.4) simply because the author wrote the app The Wrong Way, and other horrors that shall remain unspoken.
Most apps are completely broken. Pretty much every single turnkey Java CMS blows goats if it even runs at all outside of the developer's highly mangled setup. Every other Java "CMS" is a framework. In other words, the authors are incapable of producing even a broken turnkey app.
The entire Java world is stuck on frameworks. There are actually frameworks that run on top of frameworks that run on top of frameworks. From what I've seen, apps built on frameworks, which are supposed to make writing apps simpler and faster, have more lines of code than those that were written directly on top of the HttpServlet class. When some application proudly proclaims, "AppFoo is designed using the DesignPattern paradigm on top of the Broken framework with persistence provided by SomethingDefective and implements SomeJavaStandard" it's best to run away. It's a clear sign the author concentrated on buzzword compliance rather than implementing Useful Features (read: something that works).
One of the few webapps I've touched that actually works without any pain is CentricCRM. It is a perfect example of how the Java Servlet platform should work. Even building and deploying from source was painless! Any minor misconfiguration during the build process would result in an error that explicitly stated what needs to be changed. The .war file Just Plain Worked.
My theory is that the broken "turnkey" software and frameworks are created to give Java developers and consultants jobs.
