3 ms·

I used to like Java when it was simpler. Generics I thought were great, but the new features just seem like attempts to shoehorn features of dynamic languages o

I used to like Java when it was simpler. Generics I thought were great, but the new features just seem like attempts to shoehorn features of dynamic languages onto a business language. And I still can't have multiline strings (on a language used for Web programming!).

_pmf_ 9y ago
> but the new features just seem like attempts to shoehorn features of dynamic languages onto a business language None of the new features has anything to do with dynamic languages[0]. Streams and lambdas are still statically typed. [0] Well, there is DynamicInvoke, but this is not a Java feature, but a JVM feature.
jitix 9y ago
The multi line issue pisses me off on a daily basis, esp when writing tests that deal with JSONs. It's so much readable with multi line strings in python and groovy. I usually use groovy for my fun/toy projects but at my day job writing enterprise code the tests have huge JSON building blocks before the actual assertion happens.
- vonmoltke 9y ago
  Why not embed the JSON as a file in the test resources and read it in during the test setup? Is there a particular reason it needs to be embedded in the source code of the test?
  - jitix 9y ago
    Its to maintain context. If a developer is looking at a large test code then it becomes difficult to switch back and forth between 10s of JSON files and the main test code. Having the input, output and the test data in the same file is much more convenient.
- creepydata 9y ago
  Um, you really should be loading that sort of text/data from an external resource rather than embedding it in source code. Those sort of text blocks really don't belong in source code.
  - jitl 9y ago
    Why not? Why should a developer need to go through hoops like saving a string to a file then performing IO to load the string into a test case? What's the advantage of moving a string literal into a non-source file? If I'm trying to test how my system will parse a specific JSON case into a domain object, isn't it easier to read if my test case is completely expressed on the screen?
    - piva00 9y ago
      The I/O will happen anyway, either at the start of the test when loading the compiled test program WITH the big chunk of a string or when reading it from disk, of course you'll add a bit of latency for opening the file itself but it's a very small price to be paid for maintainability. Even when I develop in Python with multiline strings I use fixture files to better organise my code. Edit: removed an "even" before maintainability that was part of a first draft.
      - xpaqui 9y ago
        This is just nonsense not everything will go into a file. Somethings are easier to read on the test itself. It's a case by case problem and choosing is a great asset.
specialist 9y ago
The caretakers of Java strayed. Adopting goofy dynamic and lambda features, trying to attract the cool kids was a mistake. They should have stuck to their original mission of reducing programming mistakes and boosting productivity. String processing, a la perl, Python, is something every single developer does every day. We need multilines, intrinsics, first class regexes, etc. every day. They should have made 'utf8', 'utf16', etc first class scalars, reducing the memory footprint of java.lang.String, and everything reliant on String, ages ago. They should have increased conciseness, a la Kotlin, Ceylon, Nice, Boo (minus the duck typing), ages ago. I'm also eager for lightweight objects (value types?), a la Kava, which I think has been pushed back to JDK 10.

_pmf_ 9y ago

> but the new features just seem like attempts to shoehorn features of dynamic languages onto a business language None of the new features has anything to do with dynamic languages[0]. Streams and lambdas are still statically typed. [0] Well, there is DynamicInvoke, but this is not a Java feature, but a JVM feature.

jitix 9y ago

The multi line issue pisses me off on a daily basis, esp when writing tests that deal with JSONs. It's so much readable with multi line strings in python and groovy. I usually use groovy for my fun/toy projects but at my day job writing enterprise code the tests have huge JSON building blocks before the actual assertion happens.

vonmoltke 9y ago
Why not embed the JSON as a file in the test resources and read it in during the test setup? Is there a particular reason it needs to be embedded in the source code of the test?
- jitix 9y ago
  Its to maintain context. If a developer is looking at a large test code then it becomes difficult to switch back and forth between 10s of JSON files and the main test code. Having the input, output and the test data in the same file is much more convenient.
creepydata 9y ago
Um, you really should be loading that sort of text/data from an external resource rather than embedding it in source code. Those sort of text blocks really don't belong in source code.
- jitl 9y ago
  Why not? Why should a developer need to go through hoops like saving a string to a file then performing IO to load the string into a test case? What's the advantage of moving a string literal into a non-source file? If I'm trying to test how my system will parse a specific JSON case into a domain object, isn't it easier to read if my test case is completely expressed on the screen?
  - piva00 9y ago
    The I/O will happen anyway, either at the start of the test when loading the compiled test program WITH the big chunk of a string or when reading it from disk, of course you'll add a bit of latency for opening the file itself but it's a very small price to be paid for maintainability. Even when I develop in Python with multiline strings I use fixture files to better organise my code. Edit: removed an "even" before maintainability that was part of a first draft.
    - xpaqui 9y ago
      This is just nonsense not everything will go into a file. Somethings are easier to read on the test itself. It's a case by case problem and choosing is a great asset.

specialist 9y ago

The caretakers of Java strayed. Adopting goofy dynamic and lambda features, trying to attract the cool kids was a mistake. They should have stuck to their original mission of reducing programming mistakes and boosting productivity. String processing, a la perl, Python, is something every single developer does every day. We need multilines, intrinsics, first class regexes, etc. every day. They should have made 'utf8', 'utf16', etc first class scalars, reducing the memory footprint of java.lang.String, and everything reliant on String, ages ago. They should have increased conciseness, a la Kotlin, Ceylon, Nice, Boo (minus the duck typing), ages ago. I'm also eager for lightweight objects (value types?), a la Kava, which I think has been pushed back to JDK 10.