A cow orker and I once tried to work out just how many different languages you had to know to understand all of a J2EE project. Between programming languages, markup and templating languages and a thousand different flavours of configuration files (each a language in its own right), the assumed knowledge for a pretty simple project was pretty daunting.
And we weren't even using Jelly or Groovy.
You don't see nearly so much of this with other languages. Not just the proliferation of different languages, but also the proliferation of configuration files. Everything that's optional or that needs to be easily changed (scripted) gets dragged out into something that isn't Java code, where in other languages it would much more likely be written in one language, and programatically configured.
A configuration/scripting file makes sense when it's one component and one config file. But when you start gathering components together, you end up with one or more configuration files per component, and things start to get brittle and fiddly: especially if you want to make regular switches from one configuration mode to another (for example testing and production), in a way that crosses a number of different files.
It's tempting to say that this is because of a flaw in Java: there's something wrong with the language that makes people want to get away from it. This could partially be true, certainly I'd love to switch regularly to a dynamically typed language with closures1, but it'd be lazy to say it's the real answer. For all Java's flaws, it's still a relatively clear and flexible language. A little verbose, perhaps, but not that much. And certainly not compared to, say, anything written in XML.
As far as I can tell, there's just a firm cultural belief amongst Java developers, perhaps influenced by its C ancestry, that anything written in Java code is inviolate: set in stone. If there's anything that could possibly ever change, it should be immediately externalised. If there's a process that might need to be configured, it will need to be done in its own scripting language outside the Java code. Programmatic configuration is bad, because it's putting something that might change inside the code.
This is rubbish. Java is a nice readable and writeable language. It's been designed to have small, independent compilation units so the compile cycle is short. It doesn't suffer from the "fragile base class" problem. Changing a Java class really isn't that big a deal most of the time.
But we feel the Java code must remain inviolate, and anything that might change must live outside, where it's safe to put volatile things.
Of course we don't expect end-users of an application to configure it by changing the code and recompiling. And anything you want to change during deployment needs to be external as well. But really, with the number of configuration files that a Java server-side app accumulates, maybe one tenth of it is actually stuff you'll eventually want exposed to the end-user. And rather than spread that tenth across a bunch of different configuration files, you're much better off if you're able to write some kind of code that centralises it in a way that makes sense for your application, rather than for the various libraries it's making use of.
Update: Daniel Sheppard contributed some nice tips on the subject.
1 ...because I know someone will at least be thinking this. Anonymous inner classes are not closures. They do a reasonable (if ridiculously verbose) job of faking it, but that's all.
Wheee, someone else who believes that java code is a great place to put stuff. I see your opinion, and I raise you 'death to groovy, jelly, and all those assholes who think that they're gaining anything with two bit scripting languages knocked up by some wanker for amusement value'.
Still, now that there's two of us who believe in java code written in old fashioned, compiled, strongly typed .java files, I feel like there's hope yet.
Beside me being a fanatic with Config-In-Java-Not-In-XML, counting each XML file like a new language sounds stupid.
[customer]
[name]Stephan[/name]
[/customer]
This is a new language but
class Customer {
String name;
....
is not? And that aside, you didn't tell us how many languages you found :-) I find three: HTML, XML and Java which probably is not much shorter than HTML, XML and Perl.
@Hani: Why did Groovy already make it to asshole-status? I want to bekome an asshole too. Can you tell me how to do VBA scripting for an application without a scripting language in your old fashioned, compiled, strongly typed .java file world? I don't know where you work, but in my world, most business people say "huh?" when I tell them something about "strongly typed".
bye
-stephan
ps: Is MT stupid or am I stupid? Why does MT remove all XML instead of quoting it?
Yeah, I kind of agree. I was actually looking at the differences between PicoContainer and the Spirng Framework (both IoC frameworks that Hani probably hates :-) ). Spring ties its components together using XML, Pico using Java. I found myself saying "Why doesn't Pico use a config file? Putting this in java code is silly!". I stopped and asked myself why it was silly, but couldn't find an answer. My current app has at least 6 config files - a hibernate one (autogenerated thank god), the aforementioned spring one, a webapp localised property file, the web xml file, and at least 3 files for JBoss. I'm starting to ask myself how many of these are necesary...
I guess having to conform to n different DTD's counts as having to know n languages.
A lot of configuration/customisations problems would go away if people just designed their classes a bit better. For example, why not just pass configurable objects around, setting their implementation only at the edge of your system, instead of going away to look at an XML file at the first available opportunity?
It's a painfully obvious way to do things that's been given a trendy new name, but the fact that it's been given a trendy new name (IoC) means it'll probably go the way of everything decent in the world of Java, i.e. 3 competing, XML/Jelly/Groovy-driven toolkits will Spring (sorry) up around the idea, and people will forget about the inherent simplicity of what's actually going on.
And then one of these toolkits (once it reaches version 0.6.0b12) will become a J2EE Best Practice. Ugh.
James
Mr fish. You are right. Not everything needs to be in a config file and not everything needs to be configurable.
yup, that's why the adding of attribute meta-data in Tiger is such good news!
btw Mr Glen, its not that its not configurable, nor that it doesn't need to be, its just that its where it is most appropriate to be configured from. A .java file IS a configuration, that ends up as a .class file.
For example, in Websphere at least, its actually easier and faster to patch a .class file than it is to change the deployment descriptor!!!
I should qualify that and to say "that in Websphere 4"
Umm... I guess you guys don't use live systems or live code. Or maybe you don't have Users, just coders. Where I live, we have to deal with configuration issues by non-coders, such as sysadmins, architects, dbas, and many other fauna. They should not have to go into a class, edit and re-compile. Instead, they can edit a file, in ascii, using any editor they want, and make things work.
So, yes, anything that will have to change that a programmer will not touch has to be externalized. Its taken us years to finally get to the point where things have configuration files. Don't you remember those wonderful days of yesteryear when configs were: "Edit the basic program, and in lines 10 through 50, change the conststants to whatever you need..."?
From a coding pov, yes, I hate having to keep track of so many little configs, but when I can release a system which the end-installer can maintain without touching my code... I am happier for it.
Thanks, Michael
Michael Wexler's point is extremely good. Another reason to put
configuration information into things like XML files is to
facilitate having tools that can read, interpret, and write
such files. Java source code is extremely powerful and can
do all kinds of things, but writing a tool that can read an
arbitrary Java program and make sense of it and display it
nicely for a user is hard.
You say "where in other languages it would much more likely be written in one language, and programatically configured." I don't
understand. The Apache web server is written in C++,
but its configuration files are not C++ programs, but textual
files in a simple format. (Maybe it's C and not C++, I don't
remember.) The concept of having configuration parameters
that are stored in a declarative rather than imperative format
is not in any way unique to Java.
So you say "Of course we don’t expect end-users of an application to configure it by changing the code and recompiling." Yes, exactly.
That's why the configuration stuff is in XML or property files
and not Java. You seem to have answered your own question.
"But really, with the number of configuration files that a Java server-side app accumulates, maybe one tenth of it is actually stuff you’ll eventually want exposed to the end-user." Well, that's
an entirely different question. If you're saying that 90% of
the configurable parameters that are exposed to an administrator
should not be exposed, well, which 90%? (Now, there is a fine
point here: not everything in a J2EE descriptor is actually
a configuration parameter.) But if you go into the administrative
console of an app server, do you think 90% of it ought not be
there? You might say "well, it should figure out all those
values by itself". That would be nice but it's easier said
than done. Or you might say "the configuration parameters are
often low-level, as compared to the high-level intent of the
administrator". I'd say that, and I think that making
configuration happen at the higher level of abstraction is
an important direction for all kinds of server products
(database systems have the same issue), but it's not as easy
as one might think.
Compilation is definetely an issue here: it's a pain to dynamically compile code in Java. javac's use of a filesystem classpath sucks. Cocoon has a customized eclipse compiler that compiles against the current context classloader. That would make .java as a dynamic configuration file format possible.
Aside from that, we use beanshell for (only some ;-) of our configuration. At least it looks like Java and people can configure directly against our API.