13 ms·

Java gets a bad rap from people that used it late 90's through early 2000's and got burned out by XML and design pattern heavy frameworks but its a lovely langu

Java gets a bad rap from people that used it late 90's through early 2000's and got burned out by XML and design pattern heavy frameworks but its a lovely language that with a little discipline can be used to create very lean looking code. Go is one of the HN darling languages and I work in Go everyday for work (and generally like it), but I really wish I could reach for Java most days.

laurent92 6y ago
“Java is a big DSL to transform XML into stacktraces” — so was the joke at the time when domain-specific languages were the hype. This, and the FizzBuzz, Enterprise Edition: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... More seriously, what are you missing in Go that is well-done in Java? I assume verbosity of the code is still the defining characteristic of Java?
- matsemann 6y ago
  The java ecosystem is very nice. Not necessarily the language itself, but everything else. The jvm, the tools, the libraries are all very mature and good. Skipping java and instead using Kotlin allows one to reuse all that knowledge in a great language as well.
  - bcrosby95 6y ago
    I guess it depends upon what you mean by ecosystem. Java the language is ok. The culture (which is part of the ecosystem) and how you're pushed to write code is the biggest problem with Java. The wide array of tooling, frameworks, and libraries within the ecosystem is nice. But the way you have to use them tends to be shit due to the culture surrounding the language. At least it seems to be shifting to something more sane.
    - avmich 6y ago
      Good language ought to discourage (enough) the bad practices. Culture forms slowly, and it's Java fault that the culture managed to produce such excessities as proverbial FactoryFactoryFactory. Edit: I still think Java is a good language, especially later versions, and both original goals and recent advances are quite noble.
      - meddlepal 6y ago
        I somewhat agree, but Java grew up in a different era when communication about these things wasn't as easy. It's hard to change the direction of something as large and widely deployed as Java. It's happening but it will take time and its always going to dealing with its legacy as there just so much of it out there.
        geodel 6y ago
        Huh, one needs to see first party Java libraries from earlier times. It is pretty clear engineers at Sun also believed that AbstractFactoryFactory everything will be the way world need to be rebuilt. Of course one can show empathy and understand justifications for things they like and simply laugh out "LOL Go No Generics' when they don't.
        LgWoodenBadger 6y ago
        I don’t find this to be true outside of the mostly awful, and now dead, JEE landscape. What first-party stuff are you referring to?
        kaba0 6y ago
        I’m not sure it is necessarily dead, Jakarta EE is alive, but definitely not as big as it was.
- tonyarkles 6y ago
  Now we've got Spring, which in my, admittedly limited, experience does a great job of transforming what could have been compile-time errors into run-time errors.
  - jacques_chester 6y ago
    The wheel of karma is ever-turning, though [0],[1]. Disclosure: I work for VMware, which sponsors Spring development. [0] https://spring.io/blog/2021/03/11/announcing-spring-native-beta https://spring.io/blog/2021/03/11/announcing-spring-native-b... [1] https://github.com/spring-projects-experimental/spring-fu https://github.com/spring-projects-experimental/spring-fu
    - The_rationalist 6y ago
      Those are nice advances but I hope that spring will one day support compile time validation of generated queries and of beans like Micronaut do.
      - jacques_chester 6y ago
        I'm confident it'll reach that point.
        noisem4ker 6y ago
        ...and probably well before Micronaut gets rid of its bugs, comes close to feature parity and generally matures as a framework.
    - victor106 6y ago
      Spring native is a game changer for so many organizations using containers for startup times. There are other spring related issues you still have to deal with
  - avmich 6y ago
    Well said :) . Spring looks so much as to show how useful ideas can be misapplied with catastrophic results. For example, liberate encouraging of dependency injections leads to multitude of interfaces which are only ever implemented once by a production code class, and maybe one more time by a test class, even though Java has all methods virtual and testing could be done without requiring the interface.
- voidfunc 6y ago
  > More seriously, what are you missing in Go that is well-done in Java? 1. Generics. And yea, I know Go is getting generics "Real Soon Now" (tm), but it is incredibly annoying to write the same collection code over and over and there's some third-party libs that would really benefit from generics (looking at you Azure Go SDK). 2. Error handling... with the big caveat that I actually like Go's error handling mechanism at small scale but wish there was a good way to chain several operations together and return an error to the top if any failed... I find myself writing a lot of `err != nil` checks in sequence and I've found baking my own abstractions around this to be leaky or difficult to grow as the program requirements change. 3. Diverse collections API. 4. Iterators. 5. Not Java-the-language but the JVM has amazing monitoring tools. > I assume verbosity of the code is still the defining characteristic of Java? Pound for pound... I think Go and Java have about the same verbosity. I'm honestly never quite sure what people mean by "verbosity" in Java. Generally I interpret this as "frameworks" but I predicated my OP on the idea that legacy framework bloat is where most of people's frustration with Java lies... not the language itself.
  - avmich 6y ago
    > I'm honestly never quite sure what people mean by "verbosity" in Java. Java improved with "var" keyword (use with caution!) and introduction of records. These are not the only code-shortening features (there are e.g. interface methods, diamond operator, lambdas, convenience "of(...)" methods, even "fluid style"), but they, used well, can really reduce verbosity.
    - bobthepanda 6y ago
      Also, a lot of verbosity in Java came from people going off the rails with design patterns to hide crap multiple levels deep in a file with 5+ words in the class name. If you have a hammer everything’s a nail.
      - nitrogen 6y ago
        Frameworks like Spring/Spring Boot kind of force that as well with their runtime creation of proxy classes.
- pgwhalen 6y ago
  Not OP, but... > More seriously, what are you missing in Go that is well-done in Java? As cliche as it is to say, Go missing generics (for the time being) does hold it back in many ways relative to Java. I like and use both languages regularly, and as I thought about my answer to this question I realized that essentially all of my complaints stem from the lack of generics - things like streams, a rich collection framework, and non-channel concurrency features (java.util.concurrent among them) don't exist in go because you can build them as generically as needed for them to be useful. You might have said "well-done" as a way of excluding generics in Java since many people like to suggest they're not well done; of course most developers would like more, but they already enable an enormous amount of stuff not possible in Go.
- pron 6y ago
  I'd say the defining characteristic of Java is an unparalleled combination of performance, observability, and maintainability.
- srparish 6y ago
  Verbosity of code is more of a go thing these days: hasThing := false for _, v := range stuff { if checkForThing(v) { hasThing = true break } } if !hasThing { return false } Java: if !stuff.stream().anyMatch(v -> checkForThing(v)) { return false; } In the 2020s, loops are the new "goto", too much boiler-plate and ways to subtly be incorrect, much safer to use higher-level collection methods.
  - oftenwrong 6y ago
    return stuff.stream().anyMatch(this::checkForThing)
- rafaelvasco 6y ago
  I at the same time laughed and got nauseated just by looking at that FizzBuzzEnterprise code LOL. I'm a minimalistic programmer myself, so the thing I hate the most in coding is over engineered code. Yes , it's a joke, but a joke based on real life haha.
- mleonhard 6y ago
  Logging.
superyesh 6y ago
>got burned out by XML and design pattern heavy frameworks Most succinct summary I have heard lately :) I think a good bunch of blame is also on the developers who blindly adhere to said patterns. https://www.quora.com/What-are-the-most-ridiculous-Java-class-names-from-real-code https://www.quora.com/What-are-the-most-ridiculous-Java-clas... to rest the case.
ericbarrett 6y ago
I got burned out by endless JVM preening and devs configuring their runtime options to use 128MB in a 2GB container, or capitalizing their -Xm option wrong, or what have you. So now with cloud computing you have the JVM in a container on a virtual host, all of which have their own constraints to set—matryoshka dolls all the way down. Like, people always say, "Well that just means they didn't know what they were doing with the JVM"—yes, and it's been a problem for two decades and is about as likely to go away as buffer overflows in C. Honestly the thing I like about Go, Rust, C++ the most is the resultant binary just runs in userspace, and you can set the constraints there. Even Python scripts don't have to muck with the JVM. FactoryFactoryFactoryFactory code is the least of Java's issues.
- edp 6y ago
  Starting with OpenJDK 11 (and I think available in OpenJDK8 with an optional flag), the JVM will use the memory constraints of the container, so no more -Xmx flags and so on if you are running the JVM in a container environment.
  - oftenwrong 6y ago
    No flag necessary for latest versions of OpenJDK 8, either.
kukx 6y ago
It also gets a bad rep because of Oracle.
happyweasel 6y ago
Java isn't the worst C++ program I know.
Thaxll 6y ago
"Go is one of the HN darling languages" It's def not the case, I spend too much time here and on Reddit and people are always complaining about Go ( generics, errors, type system etc ... ), if you want the godly language it would be Rust, anything about Rust will be upvoted. As for Java, it's a good language / runtime that is overly complicated behind layers of abstraction. Take Spring for examnple, magic everywhere, add an anotation there and it does x.y.z, you can't see it in the code but it does something.
- kaba0 6y ago
  Java itself is most definitely not overly complicated. Many frameworks, and created programs are due to enterpriseTM software development, but it’s orthogonal. And spring is a really feature-packed framework which has a solution for almost every business problem that one can face. Of course it comes with a great deal of complexity, but it is a tradeoff. I rather tinker with how to use a given feature than implement it myself, often in an inferior way.
- ragnese 6y ago
  The hype around Rust is largely justified. There. I said it. Rust is nowhere near perfect. It's also supposed to be a systems language- it was probably not originally intended to replace languages like Java for general "app" development. But it's so much better of a language than most of the higher level languages you see in popular use: Java, PHP, JavaScript, Python, etc, that people are actually willing to deal with the lack of garbage collection just to get to use its excellent type system and well-designed standard library API. I think that says a lot about Rust and the programming language environment today.
  - DaiPlusPlus 6y ago
    It surprises me that we don’t yet have an applications language with an ultra-modern type-system. It’s so strange that the current leaders are a scripting-transpiler (TypeScript) and a systems language (Rust) - but not an apps language in-between. ...then again it’s understandable when you see how the traditional apps languages (C#, Java, etc) are severely hobbled by their VM/runtime, because that’s usually the source of constraints on their type-system. Kotlin and F# do some neat tricks to work-around the limitations they inherited from the JVM and the .NET CLR respectively, but I think we’ve reached the limits of what platforms originally designed ~25 years ago can reach. I just don’t see the JVM nor the CLR getting anything like first-class support for higher-kinded types or true algebraic types: there’s too much pressure from establishment banks and insurance companies not to break their decades-old codebases maintained by outsourcing companies. Languages like Swift and Go are free to break their own molds because they’re happy not leaving a legacy, but what will that mean for Rust? Systems code is the last place you need major breaking changes, but I don’t see Rust’s progress slowing down the way ISO C++ languished for almost 20 years. Hmmm.
ragnese 6y ago
I disagree that it's a lovely language. I think, as developers, we very quickly develop Stockholm syndrome. Once you "learn" a language, it's really easy to churn out code and apply idioms without even realizing that you're constantly writing workarounds and kludges for your language's deficiencies. As a polyglot dev, the following are my gripes with Java: * null - we all know, so I'm not going to bother expanding except to say that @NotNull is NOT a solution and it doesn't guarantee shit. * interfaces are extremely lacking compared to type classes and lead to verbose and cumbersome patterns such as "Adapter". * Type-erased generics. Why shouldn't I be able to implement a generic interface for multiple types? E.g., class MyNumber implements Comparable<Integer>, Comparable<Short>, Comparable<Long> {} * It only just got Records and sealed interfaces, so thank goodness for that. But prior versions of Java are extremely lacking in expressiveness without these. * I don't hate checked exceptions as a concept, but the fact that you can't be "generic" over the exceptions in a function signature is frustrating. This is why everyone says they're "incompatible" with Java's closure APIs. * No unsigned ints. * Silent integer overflow/wrap-around. It's not C- did it really have to copy this insanity? * Dates and timezones are still insane, even in Java 8+. * The fact that arrays got type variance wrong. * JDBC sucks. JPA also kind of sucks. * No concept of `const` or immutability. I'm not saying that Java is the worst language in the world or anything, but it's far from great, IMO. Most programming languages are pretty awful, IMO.
- MaxBarraclough 6y ago
  > No unsigned ints. I think that's a mixed blessing. I believe Java did this deliberately to avoid the trouble that C and C++ have with signed and unsigned integer types having to coexist. Personally I've never been inconvenienced by Java's lack of unsigned integer types, but I'm sure it can be annoying in some situations. I'm quite fond of Ada's approach to integer types, but I suspect I'm in a minority. > Silent integer overflow/wrap-around. It's not C- did it really have to copy this insanity? Curiously this cropped up 10 days ago. [0] You're not alone. The great John Regehr put it thus: [1] > Java-style wrapping integers should never be the default, this is arguably even worse than C and C++’s UB-on-overflow which at least permits an implementation to trap. > The fact that arrays got type variance wrong. At least Java has the defence that they didn't know how it would pan out. C# has no such excuse in copying Java. > No concept of `const` or immutability. I recall a Java wizard commenting that although a const system is the sort of feature that aligns with Java's philosophy, it's just too difficult to retrofit it. [0] https://news.ycombinator.com/item?id=26538842 https://news.ycombinator.com/item?id=26538842 [1] https://blog.regehr.org/archives/1401 https://blog.regehr.org/archives/1401

laurent92 6y ago

“Java is a big DSL to transform XML into stacktraces” — so was the joke at the time when domain-specific languages were the hype. This, and the FizzBuzz, Enterprise Edition: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... More seriously, what are you missing in Go that is well-done in Java? I assume verbosity of the code is still the defining characteristic of Java?

matsemann 6y ago
The java ecosystem is very nice. Not necessarily the language itself, but everything else. The jvm, the tools, the libraries are all very mature and good. Skipping java and instead using Kotlin allows one to reuse all that knowledge in a great language as well.
- bcrosby95 6y ago
  I guess it depends upon what you mean by ecosystem. Java the language is ok. The culture (which is part of the ecosystem) and how you're pushed to write code is the biggest problem with Java. The wide array of tooling, frameworks, and libraries within the ecosystem is nice. But the way you have to use them tends to be shit due to the culture surrounding the language. At least it seems to be shifting to something more sane.
  - avmich 6y ago
    Good language ought to discourage (enough) the bad practices. Culture forms slowly, and it's Java fault that the culture managed to produce such excessities as proverbial FactoryFactoryFactory. Edit: I still think Java is a good language, especially later versions, and both original goals and recent advances are quite noble.
    - meddlepal 6y ago
      I somewhat agree, but Java grew up in a different era when communication about these things wasn't as easy. It's hard to change the direction of something as large and widely deployed as Java. It's happening but it will take time and its always going to dealing with its legacy as there just so much of it out there.
      - geodel 6y ago
        Huh, one needs to see first party Java libraries from earlier times. It is pretty clear engineers at Sun also believed that AbstractFactoryFactory everything will be the way world need to be rebuilt. Of course one can show empathy and understand justifications for things they like and simply laugh out "LOL Go No Generics' when they don't.
        LgWoodenBadger 6y ago
        I don’t find this to be true outside of the mostly awful, and now dead, JEE landscape. What first-party stuff are you referring to?
        kaba0 6y ago
        I’m not sure it is necessarily dead, Jakarta EE is alive, but definitely not as big as it was.
tonyarkles 6y ago
Now we've got Spring, which in my, admittedly limited, experience does a great job of transforming what could have been compile-time errors into run-time errors.
- jacques_chester 6y ago
  The wheel of karma is ever-turning, though [0],[1]. Disclosure: I work for VMware, which sponsors Spring development. [0] https://spring.io/blog/2021/03/11/announcing-spring-native-beta https://spring.io/blog/2021/03/11/announcing-spring-native-b... [1] https://github.com/spring-projects-experimental/spring-fu https://github.com/spring-projects-experimental/spring-fu
  - The_rationalist 6y ago
    Those are nice advances but I hope that spring will one day support compile time validation of generated queries and of beans like Micronaut do.
    - jacques_chester 6y ago
      I'm confident it'll reach that point.
      - noisem4ker 6y ago
        ...and probably well before Micronaut gets rid of its bugs, comes close to feature parity and generally matures as a framework.
  - victor106 6y ago
    Spring native is a game changer for so many organizations using containers for startup times. There are other spring related issues you still have to deal with
- avmich 6y ago
  Well said :) . Spring looks so much as to show how useful ideas can be misapplied with catastrophic results. For example, liberate encouraging of dependency injections leads to multitude of interfaces which are only ever implemented once by a production code class, and maybe one more time by a test class, even though Java has all methods virtual and testing could be done without requiring the interface.
voidfunc 6y ago
> More seriously, what are you missing in Go that is well-done in Java? 1. Generics. And yea, I know Go is getting generics "Real Soon Now" (tm), but it is incredibly annoying to write the same collection code over and over and there's some third-party libs that would really benefit from generics (looking at you Azure Go SDK). 2. Error handling... with the big caveat that I actually like Go's error handling mechanism at small scale but wish there was a good way to chain several operations together and return an error to the top if any failed... I find myself writing a lot of `err != nil` checks in sequence and I've found baking my own abstractions around this to be leaky or difficult to grow as the program requirements change. 3. Diverse collections API. 4. Iterators. 5. Not Java-the-language but the JVM has amazing monitoring tools. > I assume verbosity of the code is still the defining characteristic of Java? Pound for pound... I think Go and Java have about the same verbosity. I'm honestly never quite sure what people mean by "verbosity" in Java. Generally I interpret this as "frameworks" but I predicated my OP on the idea that legacy framework bloat is where most of people's frustration with Java lies... not the language itself.
- avmich 6y ago
  > I'm honestly never quite sure what people mean by "verbosity" in Java. Java improved with "var" keyword (use with caution!) and introduction of records. These are not the only code-shortening features (there are e.g. interface methods, diamond operator, lambdas, convenience "of(...)" methods, even "fluid style"), but they, used well, can really reduce verbosity.
  - bobthepanda 6y ago
    Also, a lot of verbosity in Java came from people going off the rails with design patterns to hide crap multiple levels deep in a file with 5+ words in the class name. If you have a hammer everything’s a nail.
    - nitrogen 6y ago
      Frameworks like Spring/Spring Boot kind of force that as well with their runtime creation of proxy classes.
pgwhalen 6y ago
Not OP, but... > More seriously, what are you missing in Go that is well-done in Java? As cliche as it is to say, Go missing generics (for the time being) does hold it back in many ways relative to Java. I like and use both languages regularly, and as I thought about my answer to this question I realized that essentially all of my complaints stem from the lack of generics - things like streams, a rich collection framework, and non-channel concurrency features (java.util.concurrent among them) don't exist in go because you can build them as generically as needed for them to be useful. You might have said "well-done" as a way of excluding generics in Java since many people like to suggest they're not well done; of course most developers would like more, but they already enable an enormous amount of stuff not possible in Go.
pron 6y ago
I'd say the defining characteristic of Java is an unparalleled combination of performance, observability, and maintainability.
srparish 6y ago
Verbosity of code is more of a go thing these days: hasThing := false for _, v := range stuff { if checkForThing(v) { hasThing = true break } } if !hasThing { return false } Java: if !stuff.stream().anyMatch(v -> checkForThing(v)) { return false; } In the 2020s, loops are the new "goto", too much boiler-plate and ways to subtly be incorrect, much safer to use higher-level collection methods.
- oftenwrong 6y ago
  return stuff.stream().anyMatch(this::checkForThing)
rafaelvasco 6y ago
I at the same time laughed and got nauseated just by looking at that FizzBuzzEnterprise code LOL. I'm a minimalistic programmer myself, so the thing I hate the most in coding is over engineered code. Yes , it's a joke, but a joke based on real life haha.
mleonhard 6y ago
Logging.

superyesh 6y ago

>got burned out by XML and design pattern heavy frameworks Most succinct summary I have heard lately :) I think a good bunch of blame is also on the developers who blindly adhere to said patterns. https://www.quora.com/What-are-the-most-ridiculous-Java-class-names-from-real-code https://www.quora.com/What-are-the-most-ridiculous-Java-clas... to rest the case.

ericbarrett 6y ago

I got burned out by endless JVM preening and devs configuring their runtime options to use 128MB in a 2GB container, or capitalizing their -Xm option wrong, or what have you. So now with cloud computing you have the JVM in a container on a virtual host, all of which have their own constraints to set—matryoshka dolls all the way down. Like, people always say, "Well that just means they didn't know what they were doing with the JVM"—yes, and it's been a problem for two decades and is about as likely to go away as buffer overflows in C. Honestly the thing I like about Go, Rust, C++ the most is the resultant binary just runs in userspace, and you can set the constraints there. Even Python scripts don't have to muck with the JVM. FactoryFactoryFactoryFactory code is the least of Java's issues.

edp 6y ago
Starting with OpenJDK 11 (and I think available in OpenJDK8 with an optional flag), the JVM will use the memory constraints of the container, so no more -Xmx flags and so on if you are running the JVM in a container environment.
- oftenwrong 6y ago
  No flag necessary for latest versions of OpenJDK 8, either.

kukx 6y ago

It also gets a bad rep because of Oracle.

happyweasel 6y ago

Java isn't the worst C++ program I know.

Thaxll 6y ago

"Go is one of the HN darling languages" It's def not the case, I spend too much time here and on Reddit and people are always complaining about Go ( generics, errors, type system etc ... ), if you want the godly language it would be Rust, anything about Rust will be upvoted. As for Java, it's a good language / runtime that is overly complicated behind layers of abstraction. Take Spring for examnple, magic everywhere, add an anotation there and it does x.y.z, you can't see it in the code but it does something.

kaba0 6y ago
Java itself is most definitely not overly complicated. Many frameworks, and created programs are due to enterpriseTM software development, but it’s orthogonal. And spring is a really feature-packed framework which has a solution for almost every business problem that one can face. Of course it comes with a great deal of complexity, but it is a tradeoff. I rather tinker with how to use a given feature than implement it myself, often in an inferior way.
ragnese 6y ago
The hype around Rust is largely justified. There. I said it. Rust is nowhere near perfect. It's also supposed to be a systems language- it was probably not originally intended to replace languages like Java for general "app" development. But it's so much better of a language than most of the higher level languages you see in popular use: Java, PHP, JavaScript, Python, etc, that people are actually willing to deal with the lack of garbage collection just to get to use its excellent type system and well-designed standard library API. I think that says a lot about Rust and the programming language environment today.
- DaiPlusPlus 6y ago
  It surprises me that we don’t yet have an applications language with an ultra-modern type-system. It’s so strange that the current leaders are a scripting-transpiler (TypeScript) and a systems language (Rust) - but not an apps language in-between. ...then again it’s understandable when you see how the traditional apps languages (C#, Java, etc) are severely hobbled by their VM/runtime, because that’s usually the source of constraints on their type-system. Kotlin and F# do some neat tricks to work-around the limitations they inherited from the JVM and the .NET CLR respectively, but I think we’ve reached the limits of what platforms originally designed ~25 years ago can reach. I just don’t see the JVM nor the CLR getting anything like first-class support for higher-kinded types or true algebraic types: there’s too much pressure from establishment banks and insurance companies not to break their decades-old codebases maintained by outsourcing companies. Languages like Swift and Go are free to break their own molds because they’re happy not leaving a legacy, but what will that mean for Rust? Systems code is the last place you need major breaking changes, but I don’t see Rust’s progress slowing down the way ISO C++ languished for almost 20 years. Hmmm.

ragnese 6y ago

I disagree that it's a lovely language. I think, as developers, we very quickly develop Stockholm syndrome. Once you "learn" a language, it's really easy to churn out code and apply idioms without even realizing that you're constantly writing workarounds and kludges for your language's deficiencies. As a polyglot dev, the following are my gripes with Java: * null - we all know, so I'm not going to bother expanding except to say that @NotNull is NOT a solution and it doesn't guarantee shit. * interfaces are extremely lacking compared to type classes and lead to verbose and cumbersome patterns such as "Adapter". * Type-erased generics. Why shouldn't I be able to implement a generic interface for multiple types? E.g., class MyNumber implements Comparable<Integer>, Comparable<Short>, Comparable<Long> {} * It only just got Records and sealed interfaces, so thank goodness for that. But prior versions of Java are extremely lacking in expressiveness without these. * I don't hate checked exceptions as a concept, but the fact that you can't be "generic" over the exceptions in a function signature is frustrating. This is why everyone says they're "incompatible" with Java's closure APIs. * No unsigned ints. * Silent integer overflow/wrap-around. It's not C- did it really have to copy this insanity? * Dates and timezones are still insane, even in Java 8+. * The fact that arrays got type variance wrong. * JDBC sucks. JPA also kind of sucks. * No concept of `const` or immutability. I'm not saying that Java is the worst language in the world or anything, but it's far from great, IMO. Most programming languages are pretty awful, IMO.

MaxBarraclough 6y ago
> No unsigned ints. I think that's a mixed blessing. I believe Java did this deliberately to avoid the trouble that C and C++ have with signed and unsigned integer types having to coexist. Personally I've never been inconvenienced by Java's lack of unsigned integer types, but I'm sure it can be annoying in some situations. I'm quite fond of Ada's approach to integer types, but I suspect I'm in a minority. > Silent integer overflow/wrap-around. It's not C- did it really have to copy this insanity? Curiously this cropped up 10 days ago. [0] You're not alone. The great John Regehr put it thus: [1] > Java-style wrapping integers should never be the default, this is arguably even worse than C and C++’s UB-on-overflow which at least permits an implementation to trap. > The fact that arrays got type variance wrong. At least Java has the defence that they didn't know how it would pan out. C# has no such excuse in copying Java. > No concept of `const` or immutability. I recall a Java wizard commenting that although a const system is the sort of feature that aligns with Java's philosophy, it's just too difficult to retrofit it. [0] https://news.ycombinator.com/item?id=26538842 https://news.ycombinator.com/item?id=26538842 [1] https://blog.regehr.org/archives/1401 https://blog.regehr.org/archives/1401