4 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 You are going to ha

by 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).
  - sreque 10y ago
    You asked for examples and that proceeded to defend almost all of the ones I listed, which basically proves my point that this is how things work in the Java community. You can call things via reflection, therefore the language is dynamic? You have a strange definition of what makes a language dynamic. By that definition just about every language is dynamic. In C/C++ I can dynamically load symbols, call functions by string names, call C++ constructor functions, etc. I've never in practice seen anyone use compile-time annotation processors. In practice, annotations define runtime global variables that some frameworks make use of by doing expensive classpath scanning on startup to add or rewrite bytecode at runtime. These frameworks basically help cement java's reputation for having incredibly slow startup times while at the same time making it very difficult to understand how your code works. Even if you aren't doing classpath scanning to generate code, using annotations also introduces unnecessary coupling in your code in practice. The blog post will have some good examples I've seen in the wild. :)
locopati 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. The dominant build tool in Java (Ant) was an XML configuration file that drove complex dependency chains. Past me has done things with XML and Ant that would make present me weep.
xg15 10y ago
> 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. That's a point I never really understood. Code generation has it's downsides, but it seems vastly preferrable to the current mess of reflection: There seemed to have been a trend to move a lot of stuff that should logically occur at compile time to run time - therefore both adding a performance penalty and making debugging a royal pain - for what benefit? There are some recent projects (e.g. Immutables and Dagger2) which seem to favour code generation over reflection again and I really hope this trend picks up steam. > 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. Which sounds reasonable - until you see real-world use where all components of an application are wired together with XML - even though for most of it, there is only a single setting that wouldn't break the application.
hota_mazi 10y ago
> 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're equivocating on "dynamic". Java is not a dynamically typed language. It can be seen as "dynamic" in the sense that its behavior can be modified at runtime by external files. Then again, what languages can't?

by agentgt 10y ago

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).
- sreque 10y ago
  You asked for examples and that proceeded to defend almost all of the ones I listed, which basically proves my point that this is how things work in the Java community. You can call things via reflection, therefore the language is dynamic? You have a strange definition of what makes a language dynamic. By that definition just about every language is dynamic. In C/C++ I can dynamically load symbols, call functions by string names, call C++ constructor functions, etc. I've never in practice seen anyone use compile-time annotation processors. In practice, annotations define runtime global variables that some frameworks make use of by doing expensive classpath scanning on startup to add or rewrite bytecode at runtime. These frameworks basically help cement java's reputation for having incredibly slow startup times while at the same time making it very difficult to understand how your code works. Even if you aren't doing classpath scanning to generate code, using annotations also introduces unnecessary coupling in your code in practice. The blog post will have some good examples I've seen in the wild. :)

locopati 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. The dominant build tool in Java (Ant) was an XML configuration file that drove complex dependency chains. Past me has done things with XML and Ant that would make present me weep.

xg15 10y ago

> 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. That's a point I never really understood. Code generation has it's downsides, but it seems vastly preferrable to the current mess of reflection: There seemed to have been a trend to move a lot of stuff that should logically occur at compile time to run time - therefore both adding a performance penalty and making debugging a royal pain - for what benefit? There are some recent projects (e.g. Immutables and Dagger2) which seem to favour code generation over reflection again and I really hope this trend picks up steam. > 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. Which sounds reasonable - until you see real-world use where all components of an application are wired together with XML - even though for most of it, there is only a single setting that wouldn't break the application.

hota_mazi 10y ago

> 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're equivocating on "dynamic". Java is not a dynamically typed language. It can be seen as "dynamic" in the sense that its behavior can be modified at runtime by external files. Then again, what languages can't?