9 ms·

The problem with Java+XML isn't XML itself, it's that the Java community for a long time was pushing more and more critical code into XML, because doing non-tri

by cle 10y ago

The problem with Java+XML isn't XML itself, it's that the Java community for a long time was pushing more and more critical code into XML, because doing non-trivial dynamic things in Java itself can be a huge pain. And so over time, enterprise Java apps became giant balls of XML+Java that would break at runtime if you missed an XML parameter or had a stray character somewhere. At that point, what benefit are you getting from Java's static typing? You lose much of the benefits of Java, and suffer twice as much from its drawbacks. This is slightly better with the push away from XML and toward annotations, but it's not much better. Your program's behavior still depends on tagging the right language constructs with the right magic tags, which is a horrible way to program IMO.

agentgt 10y ago
> The problem with Java+XML isn't XML itself, it's that the Java community for a long time was pushing more and more critical code into XML You are going to have to show some examples. > because doing non-trivial dynamic things in Java itself can be a huge pain Actually Java has always been a fairly dynamic language. If it wasn't you wouldn't have all the XML and annotation stuff but code generation like you do in C/C++ and to some extent Go. You have to remember one of the reasons why there was a shit load of declarative configuration in old Java for enterprise is because software was on premise software. Customers would have different databases, hardware, etc. And there was no way you could say to those customers: "hey how about you go recompile this and that" or "use this syntactically weird DSL". Really the only better enterprise option back in those days was Lisp we all know how that played out. > Your program's behavior still depends on tagging the right language constructs with the right magic tags, which is a horrible way to program IMO. I agree/disagree. It depends on context. Annotations are declarative and thus IMO easier to not screw up and even easier to understand in many cases. Particularly for serialization and code generation. Most languages now have some sort of annotations and this is for good reason. But yeah too much (annotations) is a bad thing. Java now has annotation overload (spring boot).... probably because people bitched about XML :) ... pretty soon will have convention overload as well (Spring Boot is heading down that path as well like Rails). You can always take the explicit programmatic option... you know like wiring up your own beans and writing manual SQL but people want "magic". There is probably an even ground somewhere.
- sreque 10y ago
  I agree with cle, and I care enough to give examples of painful XML coding in Java: * Spring startup config (this is basically coding in another XML-based language) * JSPs (again, programming in a new XML-based language) * Maven Config (IMO incredibly painful-to-use XML-based language) * Hibernate config, mapping files * Tomcat config (basically a pre-cursor to Spring in some sense) Java is not a dynamic language, sorry. The JVM bytecode is fairly dynamic, but the language certainly isn't. Also, I think Java would have been better off never introducing annotations. They have their uses, but they've been so over-abused that I would consider them a net negative on the language as a whole. I've been thinking about starting a blog, and one of my initial blog posts may be why annotations are bad for Java.
  - agentgt 10y ago
    > * Spring startup config (this is basically coding in another XML-based language) The alternative of manually wiring up beans or giving up and using shitty singleton patterns is pretty awful (remember this was preannotation days). A pretty sexy annotation DI these days is Dagger2 but alas you seem to hate annotations. > * JSPs (again, programming in a new XML-based language) That is not an XML language unless you are talking about JSPX or JSF. It is a crappy templating language. Lots of languages have those (like PHP had Smarty or Pear...). I totally agree JSP and the future JSF was a horrible addition to Java. > * Maven Config (IMO incredibly painful-to-use XML-based language) A config that your IDE instantly knows how to properly setup and allows for massively powerful inheritance (see super poms). If you import a Maven project with Eclipse or IntelliJ it just works. Now I admit Maven is verbose and has lots of baggage but it has some serious pros and a lot of those pros are actually because it uses XML (like Eclipse can automatically adjust your Maven file without changing formatting). I have scripts that I have written in many languages (bash, python, etc) that can read Maven POM files thanks to XML. You can't do this with Gradle. > * Hibernate config, mapping files Yep that sucked but you hate annotations... so I guess you propose programmatically doing the mappings? I despite hibernate anyway. > * Tomcat config (basically a pre-cursor to Spring in some sense) Oh like Apache config is any better. I mean seriously Apache has made up weird SGML config. > Java is not a dynamic language, sorry. The JVM bytecode is fairly dynamic, but the language certainly isn't. It is a dynamic language. You can instantiate classes by string names and manipulate their bytecode on the fly. You can call methods dynamically as well. Yeah it doesn't have the ease of metaprogramming like Ruby or Python but its its there through libraries (CGLIB). Honestly I'm not sure what you mean by dynamic (please cite something) but I guess you mean interpreted and even that is sort of wrong as well (bytecode is interpreted by the JVM). > Also, I think Java would have been better off never introducing annotations Annotations also allow for preprocessing aka light weight macros. A full macro system probably would have been better. I look forward to your blog post (in all honesty).

by cle 10y ago

agentgt 10y ago

> The problem with Java+XML isn't XML itself, it's that the Java community for a long time was pushing more and more critical code into XML You are going to have to show some examples. > because doing non-trivial dynamic things in Java itself can be a huge pain Actually Java has always been a fairly dynamic language. If it wasn't you wouldn't have all the XML and annotation stuff but code generation like you do in C/C++ and to some extent Go. You have to remember one of the reasons why there was a shit load of declarative configuration in old Java for enterprise is because software was on premise software. Customers would have different databases, hardware, etc. And there was no way you could say to those customers: "hey how about you go recompile this and that" or "use this syntactically weird DSL". Really the only better enterprise option back in those days was Lisp we all know how that played out. > Your program's behavior still depends on tagging the right language constructs with the right magic tags, which is a horrible way to program IMO. I agree/disagree. It depends on context. Annotations are declarative and thus IMO easier to not screw up and even easier to understand in many cases. Particularly for serialization and code generation. Most languages now have some sort of annotations and this is for good reason. But yeah too much (annotations) is a bad thing. Java now has annotation overload (spring boot).... probably because people bitched about XML :) ... pretty soon will have convention overload as well (Spring Boot is heading down that path as well like Rails). You can always take the explicit programmatic option... you know like wiring up your own beans and writing manual SQL but people want "magic". There is probably an even ground somewhere.

sreque 10y ago
I agree with cle, and I care enough to give examples of painful XML coding in Java: * Spring startup config (this is basically coding in another XML-based language) * JSPs (again, programming in a new XML-based language) * Maven Config (IMO incredibly painful-to-use XML-based language) * Hibernate config, mapping files * Tomcat config (basically a pre-cursor to Spring in some sense) Java is not a dynamic language, sorry. The JVM bytecode is fairly dynamic, but the language certainly isn't. Also, I think Java would have been better off never introducing annotations. They have their uses, but they've been so over-abused that I would consider them a net negative on the language as a whole. I've been thinking about starting a blog, and one of my initial blog posts may be why annotations are bad for Java.
- agentgt 10y ago
  > * Spring startup config (this is basically coding in another XML-based language) The alternative of manually wiring up beans or giving up and using shitty singleton patterns is pretty awful (remember this was preannotation days). A pretty sexy annotation DI these days is Dagger2 but alas you seem to hate annotations. > * JSPs (again, programming in a new XML-based language) That is not an XML language unless you are talking about JSPX or JSF. It is a crappy templating language. Lots of languages have those (like PHP had Smarty or Pear...). I totally agree JSP and the future JSF was a horrible addition to Java. > * Maven Config (IMO incredibly painful-to-use XML-based language) A config that your IDE instantly knows how to properly setup and allows for massively powerful inheritance (see super poms). If you import a Maven project with Eclipse or IntelliJ it just works. Now I admit Maven is verbose and has lots of baggage but it has some serious pros and a lot of those pros are actually because it uses XML (like Eclipse can automatically adjust your Maven file without changing formatting). I have scripts that I have written in many languages (bash, python, etc) that can read Maven POM files thanks to XML. You can't do this with Gradle. > * Hibernate config, mapping files Yep that sucked but you hate annotations... so I guess you propose programmatically doing the mappings? I despite hibernate anyway. > * Tomcat config (basically a pre-cursor to Spring in some sense) Oh like Apache config is any better. I mean seriously Apache has made up weird SGML config. > Java is not a dynamic language, sorry. The JVM bytecode is fairly dynamic, but the language certainly isn't. It is a dynamic language. You can instantiate classes by string names and manipulate their bytecode on the fly. You can call methods dynamically as well. Yeah it doesn't have the ease of metaprogramming like Ruby or Python but its its there through libraries (CGLIB). Honestly I'm not sure what you mean by dynamic (please cite something) but I guess you mean interpreted and even that is sort of wrong as well (bytecode is interpreted by the JVM). > Also, I think Java would have been better off never introducing annotations Annotations also allow for preprocessing aka light weight macros. A full macro system probably would have been better. I look forward to your blog post (in all honesty).