3 ms·

y’all seem to be missing the fact that Java is a mature product. it has left the “move fast and break things” era of it’s development. code is a liability, and

by mcdow 2mo ago

y’all seem to be missing the fact that Java is a mature product. it has left the “move fast and break things” era of it’s development. code is a liability, and they likely have more to lose than gain by allowing AI contribution.

dan_q 2mo ago
It's a clear admission that AI generated/assisted code is inadequate. It's shocking given Oracle's AI spending spree over the last couple of years.
- asdfman123 2mo ago
  I think it's more a matter of "taking power tools away from toddlers." If you know how to work with it it's great, but if you use it indiscriminately it does more harm than good.
- dgellow 2mo ago
  yeah, oracle is literally betting the future of the company on OpenAI owning the majority of the AI market, so it's pretty strange to see such a ban. Their debt is already pretty much junk (and I'm not exaggerating, it is rated BBB- by s&p)
theandrewbailey 2mo ago
Java was never "move fast and break things".
ActorNightly 2mo ago
Oracle Java is also basically effectively in KTLO mode. The biggest use of Java currently is Android, and Google is on a path to migrate to Fuchsia eventually. The second biggest use is Apache Spark/Kafka, but with LLMs now, you can pretty much re implement all of that functionality in pure C. They just want a legal angle, since this is how they make most of their money.
- ternaryoperator 2mo ago
  Not sure where u get your information. Oracle Java is OpenJDK with a support license from Oracle. It is widely used in enterprises, and it is updated regularly.
- xxs 2mo ago
  like the sibling tells, a massive amounts of the enterprice software does runs on java
- vovavili 2mo ago
  >The second biggest use is Apache Spark/Kafka, but with LLMs now, you can pretty much re implement all of that functionality in pure C. Spark is written in Scala, precisely because distributed systems are best modelled as a set of pure functions with minimal references to state. This is also why part of the reason why it's ascending successor, Polars Cloud, is written in a functional language, Rust, rather than C. Android development is also increasingly being monopolized by Kotlin, not Java.
  - tsimionescu 2mo ago
    The post is about the OpenJDK, not Java the language per se. Which applies to Scala, Kotlin, JPython, and others.
    - vovavili 2mo ago
      This particular comment was about "Oracle Java".
- adl 2mo ago
  Impressive. Every word in that paragraph was wrong. well, except the last line.
  - ActorNightly 2mo ago
    Its not wrong, its just that people don't see the writing on the wall. It was the same conversations about Haskell, how functional programming with no side effects was the future, e.t.c and so on. There is literally ZERO reason to use Java outside of Android these days. If you are still developing applications in Java, you are behind.
xxs 2mo ago
>it has left the “move fast and break things java never had that phase. If anything it had a full binary class (not even source, e.g. long and int are not compatible on binary level) compatibility. Generally you can take an application from '98 and run it nowadays. It's only recent changes (jigsaw in java9 mostly) that were made them to drop some of that part.
- inigyou 2mo ago
  > (not even source, e.g. long and int are not compatible on binary level) What did you mean by this?
  - xxs 2mo ago
    if you have a method "void x(int i)", and change it to "void x(long i)", it will cause NoSuchMethodError if the code is not recompiled, i.e. if it's a dependency on a jar file. Likewise when there were methods in URLConnection that returned (or take) int for content-length, it would not be possible to convert them to long by just changing the existing signatures. The same applies to having a method "void x(String s)", it cannot be changed to "void x(Object s)" (even though all the code would compile with auto downcast) but both methods have to co-exist being overloaded. There is more to the binary compatibility but I'd leave it here. The way to do it is keeping the existing public (and protected) methods (&fields), possibly deprecating them, along with introducing new ones. Effectively any removal of anything that has been made accessible, public mostly, is forbidden. Personally, whenever I had to maintain library code I stuck to the same principle, so folks could grab a new version w/o worrying or doing any changes on their own.

by mcdow 2mo ago

dan_q 2mo ago

It's a clear admission that AI generated/assisted code is inadequate. It's shocking given Oracle's AI spending spree over the last couple of years.

asdfman123 2mo ago
I think it's more a matter of "taking power tools away from toddlers." If you know how to work with it it's great, but if you use it indiscriminately it does more harm than good.
dgellow 2mo ago
yeah, oracle is literally betting the future of the company on OpenAI owning the majority of the AI market, so it's pretty strange to see such a ban. Their debt is already pretty much junk (and I'm not exaggerating, it is rated BBB- by s&p)

theandrewbailey 2mo ago

Java was never "move fast and break things".

ActorNightly 2mo ago

Oracle Java is also basically effectively in KTLO mode. The biggest use of Java currently is Android, and Google is on a path to migrate to Fuchsia eventually. The second biggest use is Apache Spark/Kafka, but with LLMs now, you can pretty much re implement all of that functionality in pure C. They just want a legal angle, since this is how they make most of their money.

ternaryoperator 2mo ago
Not sure where u get your information. Oracle Java is OpenJDK with a support license from Oracle. It is widely used in enterprises, and it is updated regularly.
xxs 2mo ago
like the sibling tells, a massive amounts of the enterprice software does runs on java
vovavili 2mo ago
>The second biggest use is Apache Spark/Kafka, but with LLMs now, you can pretty much re implement all of that functionality in pure C. Spark is written in Scala, precisely because distributed systems are best modelled as a set of pure functions with minimal references to state. This is also why part of the reason why it's ascending successor, Polars Cloud, is written in a functional language, Rust, rather than C. Android development is also increasingly being monopolized by Kotlin, not Java.
- tsimionescu 2mo ago
  The post is about the OpenJDK, not Java the language per se. Which applies to Scala, Kotlin, JPython, and others.
  - vovavili 2mo ago
    This particular comment was about "Oracle Java".
adl 2mo ago
Impressive. Every word in that paragraph was wrong. well, except the last line.
- ActorNightly 2mo ago
  Its not wrong, its just that people don't see the writing on the wall. It was the same conversations about Haskell, how functional programming with no side effects was the future, e.t.c and so on. There is literally ZERO reason to use Java outside of Android these days. If you are still developing applications in Java, you are behind.

xxs 2mo ago

>it has left the “move fast and break things java never had that phase. If anything it had a full binary class (not even source, e.g. long and int are not compatible on binary level) compatibility. Generally you can take an application from '98 and run it nowadays. It's only recent changes (jigsaw in java9 mostly) that were made them to drop some of that part.

inigyou 2mo ago
> (not even source, e.g. long and int are not compatible on binary level) What did you mean by this?
- xxs 2mo ago
  if you have a method "void x(int i)", and change it to "void x(long i)", it will cause NoSuchMethodError if the code is not recompiled, i.e. if it's a dependency on a jar file. Likewise when there were methods in URLConnection that returned (or take) int for content-length, it would not be possible to convert them to long by just changing the existing signatures. The same applies to having a method "void x(String s)", it cannot be changed to "void x(Object s)" (even though all the code would compile with auto downcast) but both methods have to co-exist being overloaded. There is more to the binary compatibility but I'd leave it here. The way to do it is keeping the existing public (and protected) methods (&fields), possibly deprecating them, along with introducing new ones. Effectively any removal of anything that has been made accessible, public mostly, is forbidden. Personally, whenever I had to maintain library code I stuck to the same principle, so folks could grab a new version w/o worrying or doing any changes on their own.