[HN Gopher] Only 1 in 10 Oracle Java users want to stay with Big...
___________________________________________________________________
Only 1 in 10 Oracle Java users want to stay with Big Red
Author : rntn
Score : 64 points
Date : 2025-01-29 14:56 UTC (8 hours ago)
(HTM) web link (www.theregister.com)
(TXT) w3m dump (www.theregister.com)
| rad_gruchalski wrote:
| What's stopping 9 out of 10 from leaving?
| recursive wrote:
| Maybe they don't want to leave either.
| taeric wrote:
| I'm not clear what you are asking? The point seems to be that
| that is exactly what is happening?
| game_the0ry wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| >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.
| lowbloodsugar wrote:
| The decision makers like the kickbacks.
| jdmg94 wrote:
| millions of dollars in shitty legacy Java systems
| exabrial wrote:
| 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 wrote:
| 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 wrote:
| 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.
| ok_dad wrote:
| Where can I learn about modern Java like you describe? I
| only remember Java from the days of "enterprise
| factoryClassFactoryFactoryClassFizzBuzz architectural
| cancer" and I hate the language due to that old memory, but
| I'm willing to try again. A lot of companies are using it
| in the industry I'm in, and it would be worthwhile to
| learn, but searching Google for Java resources is as much
| cancer as the enterprise stuff is.
| stickfigure wrote:
| Your question seems odd to me. You had to _learn_ to
| write AbstractFactoryFactoryService. Just forget it? You
| don 't need a book.
|
| If you're used to writing nice concise code in other
| languages, just keep doing that, but in Java.
| renewedrebecca wrote:
| Exactly. I've been using Java since 2000, and I haven't
| once written an AbstractFactoryFactoryService. To be
| fair, I skipped over early versions of Spring.
| superjan wrote:
| The JVM does not have 'all the advantages of a fully native
| language': fully native code does not need a runtime, or a
| garbage collector.
| malfist wrote:
| Some would say a garbage collector is an advantage a fully
| native language doesn't have.
| jmartin2683 wrote:
| ??? There are lots of examples of this.
| Jtsummers wrote:
| D, Common Lisp, Go. All natively compiled (or can be in the
| CL case) with garbage collection.
| pfdietz wrote:
| You can bolt a conservative GC onto things compiled by an
| ordinary C compiler.
|
| https://en.wikipedia.org/wiki/Boehm_garbage_collector
| caspper69 wrote:
| I know HN is not the place for this (because Microsoft), but
| I really like C#.
|
| The ecosystem has been MIT since 2016, and the last few
| releases have been solidifying the AOT proposition.
|
| It just has so many features that allow it to compete with
| C/C++ on the low level, but it also provides exceptional high
| level niceties (which admittedly _can_ be slow, some LINQ for
| example).
|
| I know it's not fashionable, especially in a Linux-centric
| world, but I have used it extensively for many years (on
| essentially every platform), and it's lightweight (in most
| instances) and has the features and tooling to make
| development less stressful.
|
| Every time I use Java, it just feels overwhelming and slow.
| jeroenhd wrote:
| I like C# too, but both languages seem to perform pretty
| similarly in my experience. The biggest difference seems to
| come from third party libraries being more optimized in one
| framework than the other.
|
| Once Project Loom receives some more love (I believe that's
| scheduled for the next LTS, Java 25) I'll be very
| interested to see how Java's green threads will compare to
| C#'s async/await. I think Java's model may help programmers
| write more optimal code easier, but only if they can pull
| off their scheduling improvements.
|
| C# does have massive advantages when calling native code,
| though. Java FFI is always just kind of a pain and C# FFI
| is pretty much trivial.
| Jtsummers wrote:
| Garbage collection is orthogonal to "native", by which I take
| you to mean compiled to native machine code as opposed to
| something like Java's bytecode compilation or an interpreted
| language.
|
| Go, D, Common Lisp (implementation dependent), and others
| offer GC and native compilation.
|
| If you count automatic reference counting like Objective-C's
| ARC, you can add it and Swift to the list of natively
| compiled languages with GC.
| superjan wrote:
| I don't disagree, but I was responding to a claim that the
| JVM has _all_ the advantages of fully native languages.
| Fully native allows you to choose to have no runtime, or a
| garbage collector, and in some environments (realtime, OS
| kernel, AAA games) that is overwhelmingly the preferred
| option.
| blibble wrote:
| in Java you can turn off the GC completely
|
| and you can also compile to native code
| invalidname wrote:
| About the GC we can agree to disagree. But about the runtime
| check out GraalVM which compiles Java to fully native
| standalone executables.
| jeroenhd wrote:
| The funny thing about GraalVM is that some workloads are
| actually slower because of some of the dynamic
| optimisations the JVM applies. Picking the right garbage
| collector can make a Java program execute faster than when
| precompiled to native instructions.
|
| I'm sure the same would happen when writing C for the JVM.
| Tricks like dynamically rearranging/compressing pointers
| and altering structs to better suit the cache lines and
| data locality properties of the system code is running on
| can probably boost any major C program, but that's an
| incredibly complex change to a C program that the JVM just
| gives you for free.
| snovymgodym wrote:
| Lots of languages that compile to fully native code still
| have a runtime and a garbage collector as a part of that.
| cbm-vic-20 wrote:
| I haven't used it, but does GraalVM Native Image take care of
| that?
|
| https://www.graalvm.org/latest/reference-manual/native-
| image...
| helsinkiandrew wrote:
| Presumably Oracle is playing the VMware playbook - less customers
| paying more for a suite of enterprise tools.
| mrweasel wrote:
| 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 wrote:
| 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-experim...
|
| Java has been an extremely successful technical failure. With
| Oracle, it's also gotten a tonne of bureaucratic/legal/CYA cost.
| kelseyfrog wrote:
| Worse is better[1].
|
| 1.
| https://cs.stanford.edu/people/eroberts/courses/cs181/projec...
| invalidname wrote:
| 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.
| thomashabets2 wrote:
| > Newer JVMs are fantastic at allocating and releasing it in
| a way that beats C performance for some cases.
|
| And yet the care and feeding (tuning) of the GC consumes
| countless millennia of human time per year.
|
| This, as my post says, is not even an inherent problem with
| GC, but with Java assuming an eventually sufficiently smart
| GC.
|
| But also yes, successive Java GC implementations have done
| huge heroics. They've gotten better and better. A million
| PhDs have been minted inventing amazing technology in this
| space. But we've been promised the ultimate compacting
| pauseless GC for decades, and yet I see outage after outage
| of huge systems root caused to "look, we found a brand new
| way that the GC can explode (or just thrash) on us".
|
| And (for all its many flaws), Go chose a different strategy,
| and avoided a class of problems. They learned from Java's
| mistake in this case. There's still GC issues (though Go is
| also getting better and better), but nowhere close.
|
| > Java has some of the cleanest error messages around
|
| One can make the case for which is better (well, least bad)
| of Java or C++ error messages, but neither can come close to
| Rust error message quality and cleanliness.
|
| And Rust does have a developed type system.
|
| But fair enough, let's call it opinion. Which is a disclaimer
| I have at the top of the post. Like I said I'm impressed that
| Java managed to make error messages _worse_ than C++, but you
| can disagree.
|
| > Modern Java uses UTF-8 for Strings and for internal
| representation of Strings when applicable.
|
| Ok, that sounds like I'm not up to date (probably nowhere
| near). It's not an issue I've fought in years. But glad to
| hear they fixed that... "when applicable". I'll read up on
| that. Thanks.
|
| > finally
|
| Go is not my favorite language, but here I think it's better
| than Java. RAII beats defer, but at least defer makes the
| programmer add the cleanup at resource acquisition, not four
| pages further down, possibly behind a null pointer check in
| case the finally clause triggers _before_ the resource
| acquisition.
|
| I respect your opinion about aesthetics, but I don't accept
| that my opinion on finally/defer/RAII is "wrong".
|
| I appreciate the feedback. Thanks.
| jcranmer wrote:
| I can pinpoint several mistakes in that blog post:
|
| * Java has had escape analysis for decades. What it doesn't
| have is value objects. But there are plans for that in the
| works.
|
| * The rant against bytecode is... I mean, there's a reason why
| you've had projects like LLVM whose (original) goal was to
| bring something like JVM bytecode to native code. And it's not
| for portability reasons, it's for the ability to do things like
| install-time optimizations. Also note that, for example, iOS
| distribution also relies on the ability to deliver bytecode
| instead of native code for those kinds of late optimization
| opportunities.
|
| * The C++ standard library _absolutely_ uses exceptions for all
| sorts of silly errors. std::vector::at, for example, throws an
| exception on a range error. The reason why this isn 't obvious
| is that the more common methods just go for undefined behavior
| on errors instead of using exceptions, which is hardly a design
| to be emulated.
|
| * I'm confused as to why the author hates try/finally so much,
| given that it's morally equivalent to RAII and defer. And
| there's no mention of the try-with-resources, which brings an
| interface much like RAII to Java.
| thomashabets2 wrote:
| Thanks for feedback. I wonder what you would classify as a
| "mistake", though. I don't want to say anything that's
| incorrect, and definitely invite corrections.
|
| > Java has had escape analysis for decades. What it doesn't
| have is value objects. But there are plans for that in the
| works.
|
| I'm not sure what you mean this contradicts. Let's say it
| lands. Which of my points does it invalidate? (also, you
| know, Java has had ~30 years to land this)
|
| Edit: ah, I see what you mean. Basically you're saying that
| because of escape analysis, Java can avoid stuffing literally
| all objects onto the heap for the GC to collect. Sure, that's
| one of the millions of heroics that Java has added to manage
| the mistake. The GC has also added more genius algorithms
| than maybe any other code in history. And yet, a very large
| percentage of all that work is just to work around a mistake
| in the language. And it'll never be fully mitigated.
|
| > The rant against bytecode is[...]
|
| Reasonable people can disagree on the values, but what's the
| mistake?
|
| > iOS distribution also relies on the ability to deliver
| bytecode instead of native code for those kinds of late
| optimization opportunities.
|
| So did (does?) android. I remember those "optimizing apps"
| loading screens on every update. This is actually _exactly_
| my point: None of this requires that the IR / bytecode is,
| itself, "executable".
|
| > The C++ standard library absolutely uses exceptions for all
| sorts of silly errors
|
| Nowhere near Java. It's a difference is philosophy, don't you
| agree? Comparing C++ and Java, you'd agree that Java doubled
| down on exceptions, right?
|
| And that's what I'm saying the mistake is.
|
| I'm not saying that std _never_ throws errors. But that 's
| also not the case in Rust or Go. But I'm sure you agree that
| panic in Rust or Go is worlds apart from exception use in
| Java?
|
| C++ (standard library API, at least) is much much closer to
| Rust and Go, than to Java. Like, no contest.
|
| > I'm confused as to why the author hates try/finally so much
|
| Not "try" so much as "finally". Compared to RAII or Go's
| "defer", it's a very convoluted and (in my experience from
| various codebases) very error prone way to hopefully remember
| to undo everything (and if a resource acquisition is added,
| to remember to release it way down there in different code).
|
| It's morally equivalent to defer, yes, but unlike RAII it's
| not automatic. Even compared to Go's defer and (not
| guaranteed to be called) finalizer, it's easier to get wrong.
|
| Defer is better than finally, but RAII is better than both.
|
| > try-with-resources, which brings an interface much like
| RAII to Java.
|
| True. I have no criticism of that pattern, which is why I
| didn't criticize it. :-)
| sureglymop wrote:
| Didn't read the post but I highly disagree with your comment. I
| use mainly rust and I don't think it would be where it is today
| without being able to stand on the shoulders of giants like
| java.
|
| There are a lot of things that oop languages pioneered that are
| now in other languages. In rust specifically, there is a
| mixture of features taken from functional and oop languages
| that are a pleasure to use.
| jareds wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| "Only 1 in ten signatories in deals with the devil doesn't regret
| decision in hindsight"
___________________________________________________________________
(page generated 2025-01-29 23:01 UTC)