I learned many of these things on just java. For example, I've been looking around casually for an all-in-code ant for years now (though as a purely practical matter, for FOSS projects sticking to requiring only git+java+ant to be installed, and that being enough to build just as well as the core developers, is just worth more than having a somewhat easier job writing build configs than pull gant into the mix. I am keeping an eye on gradle though, might be worth it).
Jetty's config is XML, but if you read between the lines of the documentation, its pretty obvious its all just XML versions of java basics (method calls, mostly), and, yup, you can do all that in plain old java too. However, having to recompile some code just to change a port number or some such can be a pain. I once built a really simplistic web framework on top of jetty where ALL config (notably also the routing of URLs to 'servlets') was done via annotations on the servlets themselves. This was particularly elegant to me, and quite useful on that particular project, but made it hard to integrate other projects provided for free by the java community. There's a point hidden in this walk down memory lane: Going against the grain of a community (i.e. java's community) because you feel your way is better, or, you've seen the light because another community (i.e. ruby's community) likes to do things differently and you feel that way is superior.... is not as productive as you might imagine. There are sometimes valid reasons for the seemingly inefficient way of doing things, such as why jetty offers XML config and even assumes you'll be using that in its out of the box install and its documentation (well, at least before the docs were rewritten when jetty became org.eclipse.jetty - haven't looked since): The compile step can be annoying. I guess in theory this too can be nixed (by having jetty run javac on a .java 'config' file, automatically picking up changes), but doing that runs afoul of established tool chains, i.e. might cause problems when you're using an IDE or JRebel. It's all connected; the inefficiency of writing config files in XML (which admittedly team jetty could have eased a bit by using JSON or some such instead) is necessary because java has a compilation step, but this compilation step is related to java's excellent introspection tooling, something ruby projects aren't nearly as good at. Which one is worth more? That's hard to say, but its hard to have the one (in-code config) with the other (good introspection). The second problem with going against the grain is, well, you're going against the grain. Doing so causes friction. I usually end up loving my technical improvements but in the end usually dump them anyway simply because the elegance is not worth the headaches of being incompatible with many other bits the community would have provided for you if only you hadn't gone off and done a cool but non-standard trick. There are of course times going against the grain is a good thing. When trailblazing a new kind of library, for example, or in cases where the inefficiency burden of the established way of doing things grows so large its worth changing. At these times you need someone capable of thinking of other ways of solving the problem; learning about other communities is one excellent way of getting there. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
