6 ms·

Only 1 in 10 Oracle Java users want to stay with Big Red

76 points by rntn 2y ago

rad_gruchalski 2y ago
What’s stopping 9 out of 10 from leaving?
- recursive 2y ago
  Maybe they don't want to leave either.
- taeric 2y ago
  I'm not clear what you are asking? The point seems to be that that is exactly what is happening?
- game_the0ry 2y ago
  From my experience working at a big bank -- non-technical decision makers love big O. Something about paying for licensing and the support that comes with it makes them feel warm and fuzzy.
  - tastyfreeze 2y ago
    Or government, or any early users of high demand databases. Quite a bit of vendor lock in once you have started using Oracle. There are a lot of choices for databases now but Oracle was the best RDBMS around in the 90s. But, you aren't wrong about management and licensing. I have been working to excise any Oracle software from use at work to eliminate the licensing cost. But, management wants to maintain some kind of external support for everything. They want somebody to call when internal staff can't handle it. Kind of an insurance policy for when shit hits the fan.
    - forinti 2y ago
      The irony is that Oracle makes sure that things are complicated and buggy enough to require support. I once had to use a patch to be able to run an installer. That should have been the low point of my Oracle career but no! I've also had a patch fail after it had passed all prerequisite tests and after it had been installed on an identical machine: support told me the patch could have been modified. I can't even rely on installing something in a dev environment first, because they might change the patch! I hate Oracle with a passion.
  - rad_gruchalski 2y ago
    But the article claims that only 1 of 10 wants to remain. That means 9 not necessarily. If they don’t want to, what’s the reason to stay?
  - stackskipton 2y ago
    >Something about paying for licensing and the support that comes with it makes them feel warm and fuzzy. SRE here, the warm and fuzzy is lets them dodge any accountability. Their teams push out bad code, blame it on Java Runtime, engage Oracle and in chaos of an outage, push out real fix and claim "Oracle fixed their mistakes". When I was Windows Ops type, I had a manager that wanted to call Microsoft for every outage just so management would think we are on it, even if the problem was not Microsoft at all. Backslaps all around for management, bonuses intact and everyone happy. "Wait, doesn't this impact revenue?" Most companies I know who use Java are type that get deeply embedded in their customers and it's not revenue impacting, just revenue delayed.
    - game_the0ry 2y ago
      > SRE here, the warm and fuzzy is lets them dodge any accountability. Exactly right.
- lowbloodsugar 2y ago
  The decision makers like the kickbacks.
- jdmg94 2y ago
  millions of dollars in shitty legacy Java systems
exabrial 2y ago
The JVM itself is incredible, all the advantages of a fully native language with nearly none of the downsides, while being basically "third place" in speed behind C/CPP, and maintaining a gap in performance between the next closest competitors. The JVM also can do party tricks that no other language can with instrumentation and runtime class definitions. I certainly appreciate the amount of R&D Oracle is investing into the Java Virtual Machine. While I use the open source version of the JVMs, I also wouldn't mind also kicking some cash into the back into the devpool. Business with Oracle does seem to be a bit of a poison pill unfortunately. Leaves us "small budget" firms in a pickle. We know the ecosystem needs funding, but the option to engage Big Red is not enticing.
- mrsilencedogood 2y ago
  I really wish Java had been like 5 years ahead on its modernizing push. That 10 year gap between 5 and 8 where the language __barely__ changed, while competitor languages were blasting, were just killer. Some might argue the reason the 8+ renaissance has been so successful is because it let other languages beta test, and Java took the winning ideas. Maybe so. But it gave Golang time to get big, which I like a lot less than Java. Especially when people try to use it as anything but a scripting language for grpc and a runtime for protobuf. But I think with virtual threads, esp when they work with synchronized right, will finally put Java back on top of Go. People complain about Java, but imo Java's problems are mostly accidental and acknowledged, and they do often get improved or fixed. Whereas Go seems to mostly be happy with how it is exactly right now, and are loathe to improve the many pain points. So much gocode is needlessly obtuse, and it's not like the obtuseness actually accomplishes their goal. I've still seen just god-awful Gocode, with layers and layers of interfaces in between you and getting anything done. Very java-esque, despite their OOP resistance being specifically targeting not falling prey to Java's propensity for towering class hierarchies.
  - bane 2y ago
    Well there was also like 10-15 year period where Java was taken over by enterprise factoryClassFactoryFactoryClassFizzBuzz architectural cancer that really made things suck as a want to be user of the language. If you just stuck to the core language and the JVM, it's kind of always been a nice place to code even if the language was changing glacially.
helsinkiandrew 2y ago
Presumably Oracle is playing the VMware playbook - less customers paying more for a suite of enterprise tools.
- mrweasel 2y ago
  The R&D cost on both VMware and Java has do be fairly high, so maybe there's some advantage to having fewer customers and just targeting R&D towards their needs. It just seems like a dead end, how are they going to bring in new customers? No new companies are going to base their solution on Oracles Java, or Oracle DB. So are they just hoping that some company grows really big and decides that they want to give a large chunk of profit to Oracle?
thomashabets2 2y ago
In my opinion Java was basically a mistake. It's not that the design choices were dumb with the information we had at the time by smart people, but with the benefit of hindsight they were almost all duds. https://blog.habets.se/2022/08/Java-a-fractal-of-bad-experiments.html https://blog.habets.se/2022/08/Java-a-fractal-of-bad-experim... Java has been an extremely successful technical failure. With Oracle, it's also gotten a tonne of bureaucratic/legal/CYA cost.
- kelseyfrog 2y ago
  Worse is better[1]. 1. https://cs.stanford.edu/people/eroberts/courses/cs181/projects/2010-11/WorseIsBetter/index.php/Worse-is-better.html https://cs.stanford.edu/people/eroberts/courses/cs181/projec...
- _gnad_ 2y ago
  [dead]
- invalidname 2y ago
  Actually that post is very much a mistake. Everything in it is wrong. OOP is great for big applications which is where Java is still a leader. If you have statics all over then you have a problem. Heap was the right decision when Java was made. Newer JVMs are fantastic at allocating and releasing it in a way that beats C performance for some cases. There are edge cases where it can't do that which is why we're getting Valhalla which will solve that edge case. The file API you're referring to is out of date. NIO access has been around for ages. I agree that generics have a lot of issues, but Java has some of the cleanest error messages around. You dug up a single problem there which plagues pretty much any language that has a complex type system. The alternative is untyped languages that have their own problems. Bytecode is fantastic. You're confusing historic VM implementation (the Pascal VM) which were inspirational but unrelated. The value Java provides there is amazing, first modern JVMs provide a level of performance that rivals native code. But the biggest benefit isn't in performance: it's observability and extensibility. Thanks to the stability of bytecode developers have built debugging and observability tools for Java that are both performant and powerful. Having worked in this industry I can tell you that no other language comes close to that power. This isn't even a contest, it's Java then everything else. It also opened the gate for many other languages that run on the JVM and interoperate with Java fantastically well. Modern Java uses UTF-8 for Strings and for internal representation of Strings when applicable. I suggest reading a bit about modern GCs. Xms/Xmx are important but modern heap allocation and the things done by the newer GCs is at a completely different level. Misuse of checked exceptions in some cases is a pain point for me too. I'd also add that when Lambdas were added the designers didn't do the work required to solve the issue with checked exceptions there. Which is indeed a shame. Having said that, this is a wide problem in pretty much every language. Exceptions make a lot of sense in terms of performance/flow. I disagree about finally though. It's a powerful control flow tool that allows us to remove code duplication. No, it doesn't look great. But the alternatives (e.g. Go) look worse.
jareds 2y ago
Has anyone ever noticed major differences between different JVM distributions? I've used multiple distributions including TEMURIN and Corretto and never noticed behavioral differences. I've never run Java at massive scale or performance critical code though.
- unscaled 2y ago
  The other JVM distributions are a drop-in replacement for Oracle. It seems like most big customers that aren't still running old versions of Java have already moved away from Oracle to different distributions. But Oracle is still exclusive on GraalVM. If you've got on the Native Image bandwagon (which is pushed heavily by new frameworks like Quarkus, Micronaut and Helidon), your lock-in to Oracle is stronger, at least as things currently stands. To make it worse, some features are only available in the paid Enterprise Edition. The pricing seems much better now (you no longer pay by core), but it's a far cry from open source. Unfortunately, some of these features are quite critical if you want native code that matches JVM performance.
- malfist 2y ago
  Usually the official JVM has access to newer and better versions of the garbage collectors more quickly as well as debugging tools. For example, the JDK 8 from oracle had the java flight recorder, a fantastic bit of tooling for debugging prod. I don't think the non-oracle versions got it until 10 or 12.
- invalidname 2y ago
  We test on all of them since we build observability solutions. We run a ridiculous amount of tests on every commit. There are minor differences, but not stuff you would notice when you build an app. If you do notice it then you have a bug in your code. IBM is probably the biggest difference since they do a lot of work on their JVM and have the most changes.
  - jareds 2y ago
    Good to know some things never change. I used to work on z/OS and it was 50/50 if IBM would release a new major Java version the same year as Oracle.
mullingitover 2y ago
“Only 1 in ten signatories in deals with the devil doesn’t regret decision in hindsight”
vardump 2y ago
90%+? It might make more sense to support the 90%+ case than the rest. I wonder if at some point this is going to hurt Oracle through lack of Oracle Java support for Open Source libraries and even ISV software. Certainly it feels a bit risky to use Oracle Java, not only because of Oracle (shudder), but also due to potential support risk.

76 points by rntn 2y ago

rad_gruchalski 2y ago

What’s stopping 9 out of 10 from leaving?

recursive 2y ago
Maybe they don't want to leave either.
taeric 2y ago
I'm not clear what you are asking? The point seems to be that that is exactly what is happening?
game_the0ry 2y ago
From my experience working at a big bank -- non-technical decision makers love big O. Something about paying for licensing and the support that comes with it makes them feel warm and fuzzy.
- tastyfreeze 2y ago
  Or government, or any early users of high demand databases. Quite a bit of vendor lock in once you have started using Oracle. There are a lot of choices for databases now but Oracle was the best RDBMS around in the 90s. But, you aren't wrong about management and licensing. I have been working to excise any Oracle software from use at work to eliminate the licensing cost. But, management wants to maintain some kind of external support for everything. They want somebody to call when internal staff can't handle it. Kind of an insurance policy for when shit hits the fan.
  - forinti 2y ago
    The irony is that Oracle makes sure that things are complicated and buggy enough to require support. I once had to use a patch to be able to run an installer. That should have been the low point of my Oracle career but no! I've also had a patch fail after it had passed all prerequisite tests and after it had been installed on an identical machine: support told me the patch could have been modified. I can't even rely on installing something in a dev environment first, because they might change the patch! I hate Oracle with a passion.
- rad_gruchalski 2y ago
  But the article claims that only 1 of 10 wants to remain. That means 9 not necessarily. If they don’t want to, what’s the reason to stay?
- stackskipton 2y ago
  >Something about paying for licensing and the support that comes with it makes them feel warm and fuzzy. SRE here, the warm and fuzzy is lets them dodge any accountability. Their teams push out bad code, blame it on Java Runtime, engage Oracle and in chaos of an outage, push out real fix and claim "Oracle fixed their mistakes". When I was Windows Ops type, I had a manager that wanted to call Microsoft for every outage just so management would think we are on it, even if the problem was not Microsoft at all. Backslaps all around for management, bonuses intact and everyone happy. "Wait, doesn't this impact revenue?" Most companies I know who use Java are type that get deeply embedded in their customers and it's not revenue impacting, just revenue delayed.
  - game_the0ry 2y ago
    > SRE here, the warm and fuzzy is lets them dodge any accountability. Exactly right.
lowbloodsugar 2y ago
The decision makers like the kickbacks.
jdmg94 2y ago
millions of dollars in shitty legacy Java systems

exabrial 2y ago

The JVM itself is incredible, all the advantages of a fully native language with nearly none of the downsides, while being basically "third place" in speed behind C/CPP, and maintaining a gap in performance between the next closest competitors. The JVM also can do party tricks that no other language can with instrumentation and runtime class definitions. I certainly appreciate the amount of R&D Oracle is investing into the Java Virtual Machine. While I use the open source version of the JVMs, I also wouldn't mind also kicking some cash into the back into the devpool. Business with Oracle does seem to be a bit of a poison pill unfortunately. Leaves us "small budget" firms in a pickle. We know the ecosystem needs funding, but the option to engage Big Red is not enticing.

mrsilencedogood 2y ago
I really wish Java had been like 5 years ahead on its modernizing push. That 10 year gap between 5 and 8 where the language __barely__ changed, while competitor languages were blasting, were just killer. Some might argue the reason the 8+ renaissance has been so successful is because it let other languages beta test, and Java took the winning ideas. Maybe so. But it gave Golang time to get big, which I like a lot less than Java. Especially when people try to use it as anything but a scripting language for grpc and a runtime for protobuf. But I think with virtual threads, esp when they work with synchronized right, will finally put Java back on top of Go. People complain about Java, but imo Java's problems are mostly accidental and acknowledged, and they do often get improved or fixed. Whereas Go seems to mostly be happy with how it is exactly right now, and are loathe to improve the many pain points. So much gocode is needlessly obtuse, and it's not like the obtuseness actually accomplishes their goal. I've still seen just god-awful Gocode, with layers and layers of interfaces in between you and getting anything done. Very java-esque, despite their OOP resistance being specifically targeting not falling prey to Java's propensity for towering class hierarchies.
- bane 2y ago
  Well there was also like 10-15 year period where Java was taken over by enterprise factoryClassFactoryFactoryClassFizzBuzz architectural cancer that really made things suck as a want to be user of the language. If you just stuck to the core language and the JVM, it's kind of always been a nice place to code even if the language was changing glacially.

helsinkiandrew 2y ago

Presumably Oracle is playing the VMware playbook - less customers paying more for a suite of enterprise tools.

mrweasel 2y ago
The R&D cost on both VMware and Java has do be fairly high, so maybe there's some advantage to having fewer customers and just targeting R&D towards their needs. It just seems like a dead end, how are they going to bring in new customers? No new companies are going to base their solution on Oracles Java, or Oracle DB. So are they just hoping that some company grows really big and decides that they want to give a large chunk of profit to Oracle?

thomashabets2 2y ago

In my opinion Java was basically a mistake. It's not that the design choices were dumb with the information we had at the time by smart people, but with the benefit of hindsight they were almost all duds. https://blog.habets.se/2022/08/Java-a-fractal-of-bad-experiments.html https://blog.habets.se/2022/08/Java-a-fractal-of-bad-experim... Java has been an extremely successful technical failure. With Oracle, it's also gotten a tonne of bureaucratic/legal/CYA cost.

kelseyfrog 2y ago
Worse is better[1]. 1. https://cs.stanford.edu/people/eroberts/courses/cs181/projects/2010-11/WorseIsBetter/index.php/Worse-is-better.html https://cs.stanford.edu/people/eroberts/courses/cs181/projec...
_gnad_ 2y ago
[dead]
invalidname 2y ago
Actually that post is very much a mistake. Everything in it is wrong. OOP is great for big applications which is where Java is still a leader. If you have statics all over then you have a problem. Heap was the right decision when Java was made. Newer JVMs are fantastic at allocating and releasing it in a way that beats C performance for some cases. There are edge cases where it can't do that which is why we're getting Valhalla which will solve that edge case. The file API you're referring to is out of date. NIO access has been around for ages. I agree that generics have a lot of issues, but Java has some of the cleanest error messages around. You dug up a single problem there which plagues pretty much any language that has a complex type system. The alternative is untyped languages that have their own problems. Bytecode is fantastic. You're confusing historic VM implementation (the Pascal VM) which were inspirational but unrelated. The value Java provides there is amazing, first modern JVMs provide a level of performance that rivals native code. But the biggest benefit isn't in performance: it's observability and extensibility. Thanks to the stability of bytecode developers have built debugging and observability tools for Java that are both performant and powerful. Having worked in this industry I can tell you that no other language comes close to that power. This isn't even a contest, it's Java then everything else. It also opened the gate for many other languages that run on the JVM and interoperate with Java fantastically well. Modern Java uses UTF-8 for Strings and for internal representation of Strings when applicable. I suggest reading a bit about modern GCs. Xms/Xmx are important but modern heap allocation and the things done by the newer GCs is at a completely different level. Misuse of checked exceptions in some cases is a pain point for me too. I'd also add that when Lambdas were added the designers didn't do the work required to solve the issue with checked exceptions there. Which is indeed a shame. Having said that, this is a wide problem in pretty much every language. Exceptions make a lot of sense in terms of performance/flow. I disagree about finally though. It's a powerful control flow tool that allows us to remove code duplication. No, it doesn't look great. But the alternatives (e.g. Go) look worse.

jareds 2y ago

Has anyone ever noticed major differences between different JVM distributions? I've used multiple distributions including TEMURIN and Corretto and never noticed behavioral differences. I've never run Java at massive scale or performance critical code though.

unscaled 2y ago
The other JVM distributions are a drop-in replacement for Oracle. It seems like most big customers that aren't still running old versions of Java have already moved away from Oracle to different distributions. But Oracle is still exclusive on GraalVM. If you've got on the Native Image bandwagon (which is pushed heavily by new frameworks like Quarkus, Micronaut and Helidon), your lock-in to Oracle is stronger, at least as things currently stands. To make it worse, some features are only available in the paid Enterprise Edition. The pricing seems much better now (you no longer pay by core), but it's a far cry from open source. Unfortunately, some of these features are quite critical if you want native code that matches JVM performance.
malfist 2y ago
Usually the official JVM has access to newer and better versions of the garbage collectors more quickly as well as debugging tools. For example, the JDK 8 from oracle had the java flight recorder, a fantastic bit of tooling for debugging prod. I don't think the non-oracle versions got it until 10 or 12.
invalidname 2y ago
We test on all of them since we build observability solutions. We run a ridiculous amount of tests on every commit. There are minor differences, but not stuff you would notice when you build an app. If you do notice it then you have a bug in your code. IBM is probably the biggest difference since they do a lot of work on their JVM and have the most changes.
- jareds 2y ago
  Good to know some things never change. I used to work on z/OS and it was 50/50 if IBM would release a new major Java version the same year as Oracle.

mullingitover 2y ago

“Only 1 in ten signatories in deals with the devil doesn’t regret decision in hindsight”

vardump 2y ago

90%+? It might make more sense to support the 90%+ case than the rest. I wonder if at some point this is going to hurt Oracle through lack of Oracle Java support for Open Source libraries and even ISV software. Certainly it feels a bit risky to use Oracle Java, not only because of Oracle (shudder), but also due to potential support risk.