« Processing XML with Java | Main | Code is not text »

Ara Abrahamian on edit/compile/debug/startup in J2EE

Memory Dump

Here we go-

Make the damn thing less complex! Cut off dependencies to containers. We shouldn't have to run the web app tests inside a container, and we shouldn't have to use mockobjects to run then out of the container. Look at webwork, with a clean servlet-independent approach you can run the test cases off the servlet container like normal code.

No we shouldn't. But that's the price you pay for container management in J2EE. The container takes care of everything and everything it doesn't is by definition, unimportant. There is zero facility for testing deployments into J2EE - indeed I don't think the J2EE specs have a tester role. Not that I like the idea of separating test from development but it would tell me at least that the J2EE architects were thinking about testing at all. Seriously, testing container based J2EE components is a nightmare - so much so that no-one seems to want to take it head on on the JOSS world, other than Cactus. This state of affairs is tolerable for Servlets, as you can factor the logic out to beans and test them standalone (use! beans! they tell me). But this strategy makes no sense in the back tiers - the whole point of the container model is have significant processing in the container and have the container manage the hard stuff, like transactions, pooling and resource access and thread safety. As soon as you take logic out of the container, you lose the benefits of containership. Damned if you do, damned if you don't. I wonder, is unit testing in Java of more value that anything a container can give? UT helps produce high quality code in very short timeframes. Container management in J2EE doesn't always seem to be on the right side of the cost/benefit curve. The answer seems to be to design an app server with unit and acceptance testing in mind or think hard on the rationales for the container paradigm, and that may involve thinking hard about how application code squares with relational databases- hte fact is muich of the realized value of something like EJB is in caching the database. Nor do things make sense with JSP, which are close to untestable (yes everything's testable, but JSPs are a stretch). Again the container is not designed with testing in mind - of what use is a stacktrace pointing to a line in the compiled servlet to me with a JSP, when I'm working with the JSP?

IDEs can provide efficient implementations of Maven goals

That's got to be Maven's job. Period. I'm not interested in moving to a build system that requires an IDE to optimize its execution.

Ant and Maven are a solution to a problem: treating software development like a factory line consisting of many steps which can be automated. The problem is with all these steps and complexity of each step we end up struggling with a giant slow build process.

Wholehearted agreement with the production line idiom, though to be honest, Ant doesn't really support it (unless you start using system entities to compose buildfiles). This shouldn't be a surprise - Ant at heart is a depedency resolver cum expert system cum graph walker, not a pipelining architecture. And in truth, speed is not the problem I see with building Java. The problem we have in work with the build/release process are versioning released jarfiles (our own and third party's), in particular keeping clients and server jarfiles in sync - aside from container testing, coupling clients and servers through jar libraries is IMO a serious design flaw with J2EE. Very soon now, Propylon will announce the release of a product for XML processing which supports versioning, managing and unit testing of processing components, yet we're in shtick when it comes to doing the same things for the Java code that actually implements the product. It's a surreal situation.

And just wait until we start having to manage web service deployments through Java where the server is continually being upgraded and you simply cannot guarantee that client jarfiles or even JDKs are synced with yours. Web services is a very, very different world to the RMI/J2EE barrio.
The CLASSPATH and the JAR file format are inadequate for managing dependencies versioning and product releases. JMX I reserve judgement on, but i don't see much support by way of versioning or deployment.

While the Java world agonizes about web service 'illities, XML v Binary, REST v RPC, J2EE v .NET, XML Schema vesus untyped XML, I fully expect that web services management, versioning and maintenance to be blissfully ignored. As an industry these are things we've always sucked at - but if we're anyway serious about a services paradigm, that means we're serious about things like quality, testing, maintanance, independent evolution of clients and services. There is no real support in J2EE, for any of this. It's the stuff of business models.


December 12, 2002 01:34 AM

Comments

Trackback Pings

TrackBack URL for this entry:
http://www.dehora.net/mt/mt-tb.cgi/837