6 ms·

This is the start of the path to not using Java. And it's not so much about AWS quality of Java documentation. It's just about "why the heck does everything J

by hoodoof 11y ago

This is the start of the path to not using Java. And it's not so much about AWS quality of Java documentation. It's just about "why the heck does everything Java have to be so damn heavyweight and so damn hard". Everything in the Java ecosystem is hard. I generally don't care so much about what language something is built in but I do try really hard not to use major applications written in Java. Life is too short to spend my days fighting through thickets of XML tags to try to get something configured, or installing something that seems to be constructed from hundreds or thousands of files. Use a different language and some things aren't so hard any more. I will say that the exception is the JetBrains IDE that I use most of the day is built with Java and somehow they have managed to shield me from ever needing to even know that. Friends don't let friends use Java.

pvg 11y ago
This is precisely about the quality of the documentation and the provided example. A simple C# example is included and works in Java with minor modifications. It's at the end of the article.
- hoodoof 11y ago
  My point remains - "it's the Java way to make it hard".
  - Turing_Machine 11y ago
    Another way of looking at is is that many large Java shops do the kind of government/corporate contract work where you get paid by the line of code. Fill in the blanks.
    - hoodoof 11y ago
      Sorry I challenge this notion. I don't believe anyone gets paid by the line of code. Even Java programmers.
      - Turing_Machine 11y ago
        Individual programmers may not (although it's certainly used as a bogus "productivity" metric in many companies) but shops do. Most famously, IBM insisted on paying Microsoft by kLOC for their work on OS/2, and we all know how that turned out.
        hoodoof 11y ago
        I knew this is what you were referring to. That was a long time ago.
      - orbitingpluto 11y ago
        Well not anymore at least. Streams and lambdas wouldn't be implemented if that was the case.
      - myhf 11y ago
        It would be foolish to explicitly pay for lines of code, but there are lots of situations where that happens implicitly. Most programmers get paid by the hour, and consistently produce about the same number of lines of code per hour. Most large contracts are billed according to the perceived magnitude of the task. The value to the client is more important than the cost to the contractor, but the cost is still a factor. And for a contractor who has already decided which programmers will work with which tools, that cost is directly proportional to lines of code.
  - pvg 11y ago
    I'm not really seeing it. This example is egregious and that's what the author is upset about. If it had, I dunno, just a Maven pom of some sort it would be in the same ballpark of conceptual overhead as npm/grunt/gulp/grumble/glorkle/grlarlarlgh/rvr/gem/bundler/virtualenv/easy_install/pip/hip/hooray/etc.
  - peeters 11y ago
    You're affirming the consequent. The truth is that "it's the enterprisey way to use Java", which is what leads to examples like this. The converse is not true, which is that it's the Java way to be enterprisey.
deleted 11y ago
[deleted]
peeters 11y ago
> Everything in the Java ecosystem is hard. It really isn't. I request that you qualify your comments to the subset of the "Java ecosystem" that you actually have experience with. Because "thickets of XML tags" really has nothing to do with Java, though it might have to do with certain massive frameworks built on top of Java.
- geofft 11y ago
  I'm curious, what parts of the Java ecosystem (other than simple stuff, or old stuff, or non-Java languages on the JVM) don't involve thickets of XML tags? I have so little Java experience that it's fallen off my résumé, so I'm sure I'm uninformed and would like to be more informed. But everything I've seen of actual, production Java development today heavily uses XML somehow, from Ant or Maven build files, to web.xml, to Spring dependency injection, to Android, to even Java Web Start. Is there any serious part of the Java (Java, not Scala or Clojure) ecosystem that doesn't involve XML at every corner?
  - lbarrow 11y ago
    I've been using Dropwizard extensively at work for the last 8 months without touching XML.
    - RhodesianHunter 11y ago
      I'm really enjoying Dropwizard. It has helped pull me back in to the Java ecosystem.
    - einrealist 11y ago
      I do Java projects for more than 15 years. I know the times when XML-based configuration was the standard. Now, I am working on the MVP of my startup, with Dropwizard. The XML days feel like stories from a fairy tale. But I have to say that XML is often blamed by people who think that complexity would magically vanish. Complexity does not vanish. It can only be shifted around. And it often requires lots of iterations to find an approach that is good enough for everyone. Back in the days, if tooling was right, I did not care about the amount of XML.
jkot 11y ago
> Life is too short to spend my days fighting through thickets of XML tags to try to get something configured, or installing something that seems to be constructed from hundreds or thousands of files. > I will say that the exception is the JetBrains IDE As someone who wrote a few patches for Idea, I can say that its one of the most bloated and complex java applications in existence. I do not mean it in a negative way, it just solves complex problem. And yes it uses XML for configuration. Compare it with JEdit: http://www.jedit.org/ http://www.jedit.org/
benwilber0 11y ago
As someone who writes Android apps everyday and has no prior experience with the Java ecosystem, seems fine to me. I put my deps in gradle and let Android Studio sync, then I just.. code. The IDE does most of the work.

by hoodoof 11y ago

pvg 11y ago

This is precisely about the quality of the documentation and the provided example. A simple C# example is included and works in Java with minor modifications. It's at the end of the article.

hoodoof 11y ago
My point remains - "it's the Java way to make it hard".
- Turing_Machine 11y ago
  Another way of looking at is is that many large Java shops do the kind of government/corporate contract work where you get paid by the line of code. Fill in the blanks.
  - hoodoof 11y ago
    Sorry I challenge this notion. I don't believe anyone gets paid by the line of code. Even Java programmers.
    - Turing_Machine 11y ago
      Individual programmers may not (although it's certainly used as a bogus "productivity" metric in many companies) but shops do. Most famously, IBM insisted on paying Microsoft by kLOC for their work on OS/2, and we all know how that turned out.
      - hoodoof 11y ago
        I knew this is what you were referring to. That was a long time ago.
    - orbitingpluto 11y ago
      Well not anymore at least. Streams and lambdas wouldn't be implemented if that was the case.
    - myhf 11y ago
      It would be foolish to explicitly pay for lines of code, but there are lots of situations where that happens implicitly. Most programmers get paid by the hour, and consistently produce about the same number of lines of code per hour. Most large contracts are billed according to the perceived magnitude of the task. The value to the client is more important than the cost to the contractor, but the cost is still a factor. And for a contractor who has already decided which programmers will work with which tools, that cost is directly proportional to lines of code.
- pvg 11y ago
  I'm not really seeing it. This example is egregious and that's what the author is upset about. If it had, I dunno, just a Maven pom of some sort it would be in the same ballpark of conceptual overhead as npm/grunt/gulp/grumble/glorkle/grlarlarlgh/rvr/gem/bundler/virtualenv/easy_install/pip/hip/hooray/etc.
- peeters 11y ago
  You're affirming the consequent. The truth is that "it's the enterprisey way to use Java", which is what leads to examples like this. The converse is not true, which is that it's the Java way to be enterprisey.

deleted 11y ago

[deleted]

peeters 11y ago

> Everything in the Java ecosystem is hard. It really isn't. I request that you qualify your comments to the subset of the "Java ecosystem" that you actually have experience with. Because "thickets of XML tags" really has nothing to do with Java, though it might have to do with certain massive frameworks built on top of Java.

geofft 11y ago
I'm curious, what parts of the Java ecosystem (other than simple stuff, or old stuff, or non-Java languages on the JVM) don't involve thickets of XML tags? I have so little Java experience that it's fallen off my résumé, so I'm sure I'm uninformed and would like to be more informed. But everything I've seen of actual, production Java development today heavily uses XML somehow, from Ant or Maven build files, to web.xml, to Spring dependency injection, to Android, to even Java Web Start. Is there any serious part of the Java (Java, not Scala or Clojure) ecosystem that doesn't involve XML at every corner?
- lbarrow 11y ago
  I've been using Dropwizard extensively at work for the last 8 months without touching XML.
  - RhodesianHunter 11y ago
    I'm really enjoying Dropwizard. It has helped pull me back in to the Java ecosystem.
  - einrealist 11y ago
    I do Java projects for more than 15 years. I know the times when XML-based configuration was the standard. Now, I am working on the MVP of my startup, with Dropwizard. The XML days feel like stories from a fairy tale. But I have to say that XML is often blamed by people who think that complexity would magically vanish. Complexity does not vanish. It can only be shifted around. And it often requires lots of iterations to find an approach that is good enough for everyone. Back in the days, if tooling was right, I did not care about the amount of XML.

jkot 11y ago

> Life is too short to spend my days fighting through thickets of XML tags to try to get something configured, or installing something that seems to be constructed from hundreds or thousands of files. > I will say that the exception is the JetBrains IDE As someone who wrote a few patches for Idea, I can say that its one of the most bloated and complex java applications in existence. I do not mean it in a negative way, it just solves complex problem. And yes it uses XML for configuration. Compare it with JEdit: http://www.jedit.org/ http://www.jedit.org/

benwilber0 11y ago

As someone who writes Android apps everyday and has no prior experience with the Java ecosystem, seems fine to me. I put my deps in gradle and let Android Studio sync, then I just.. code. The IDE does most of the work.