[HN Gopher] Which Version of JDK Should I Use?
___________________________________________________________________
Which Version of JDK Should I Use?
Author : aiobe
Score : 186 points
Date : 2021-10-10 18:06 UTC (4 hours ago)
(HTM) web link (whichjdk.com)
(TXT) w3m dump (whichjdk.com)
| dudul wrote:
| Minor typo in the FAQ: "The JRE is a stripped down version of the
| JRE, and is smaller in terms of Megabytes."
| thayne wrote:
| How do the versions in linux package repositories fit into this?
| It mentions Red Hat, but what about the packages for
| Debian/Ubuntu, OpenSUSE, etc.
| 094459 wrote:
| Thanks for crafting this document, it's a great start and good to
| get the discussions started. For me, when I look at which
| distribution to use I would probably consider other factors that
| this post doesn't touch upon completely. What sort of upstream
| contributions and activity, support across both cloud and on
| premise and multi architecture support are just a few that come
| to mind.
| agilob wrote:
| Highlights column only includes syntax sugar or syntactical
| functionality, but nothing about ZGC, shenandoah, compact
| metaspace? Very unfair.
| chadrs wrote:
| Yeah I agree we should be using 17 except Gradle still does not
| support it, despite having been out for an entire month...
|
| https://docs.gradle.org/current/userguide/compatibility.html
| isbvhodnvemrwvn wrote:
| Isn't that kind of thing you'd expect using Gradle? It's not
| the first time it happened, they have been late to the party
| for a lot of the recent releases.
| geodel wrote:
| I guess it serves right to folks who endlessly hated Maven
| and liked this "new", "next generation" , "modern" build
| system with no XML. Turns out as long as JDK-8 is supported
| version of Java a lot of tools like this look modern.
| krzyk wrote:
| Which is funny because EA builds were out there much longer,
| just RC was out there for another month.
| derefr wrote:
| Technically it's the _Groovy runtime_ that doesn 't support 17
| (or specifically, JVM bytecode v62+) yet. And then only because
| it seems to do an explicit whitelisted-version check during
| some buildscript static-analysis bootstrap phase.
|
| If you switch your Gradle buildscript files over to being
| written in Kotlin, the problem goes away, as Kotlin's runtime
| doesn't seem to use any similar explicit checks.
|
| (Doing so also allows you to go further and test out EA JVM
| builds, e.g. Project Loom, which Groovy-based buildscripts have
| never been, and will never be, happy with.)
| vitus wrote:
| It should also work with the latest versions of Gradle (7.2
| or so), as the Groovy runtime used by Gradle has since been
| upgraded.
|
| https://github.com/gradle/gradle/issues/16857
| derefr wrote:
| Yes, it does _now_ ; but the Groovy runtime still has the
| general problem of not working with each new JVM version
| for months after it comes out. Whereas, with the Kotlin
| runtime, you can just forget about this problem and upgrade
| as soon as you like.
| hawk_ wrote:
| even if the gradle script is written in kotlin, wouldn't
| you face the issue with gradle regardless?
| derefr wrote:
| No, because Gradle isn't checking the JVM version, the
| Groovy runtime is. (Specifically, the Groovy _compiler_
| seems to run fine on the buildscript, producing a
| buildscript bytecode file; but then, upon load, the
| Groovy runtime seems to check that buildscript bytecode
| file 's JVM bytecode version metadata before doing
| whatever-it-does when loading it.)
|
| Gradle itself isn't written in Groovy; it's 5% Java, 95%
| Kotlin. The Groovy runtime is only spun up to compile and
| run Groovy buildscripts (i.e. the default kind of Gradle
| buildscript with a ".gradle" file extension.) If none of
| your buildscripts are written in Groovy, then you're not
| compiling or running any Groovy code, so that runtime
| check never executes.
| ptx wrote:
| If I understand that page correctly, you can use Java 17 to
| compile and run your program, as long as you also have Java 16
| or older installed to run Gradle itself.
| hiram112 wrote:
| Thank you for this.
|
| I've seen, over the past few years, at least a dozen large
| threads on HN, Reddit, Slashdot, and elsewhere arguing over the
| JDK.
|
| Usually they're a passionate mix of developers and PMs claiming
| they're still very confused by the licensing and update /
| security fix terms since JDK 8, while various Oracle engineers
| then shout back that the licensing issues are straight forward.
|
| Personally, I've developed with Java for over a decade, and I
| have never really understood when I should use one version or the
| other. Oracle, Eclipse Foundation, IBM, and the other big players
| have not done a good job of marketing the various offerings, nor
| have they done a good job of clarifying for engineers what they
| should be installing on their local machines, development and
| test servers, production, etc.
|
| This is probably the clearest fact sheet I've seen yet, and the
| links to different distributions with a concise "Use / Don't
| Use..." rating is indispensable.
| miked85 wrote:
| The problem is that this page is a very poor resource, with
| little to nothing backing reasons why one JDK is a better over
| another.
| twic wrote:
| I'd like to see more of a rationale for not using Corretto on
| non-AWS servers. What's wrong with it?
| miked85 wrote:
| There isn't any rationale. The author doesn't even attempt to
| explain the reason behind most recommendations.
| distances wrote:
| I'd also like to know. Even some large Android projects use
| Corretto.
| exabrial wrote:
| Not sure. The JDK works pretty well, but for whatever reason, I
| had issues with Corretto crypto provider and running it with
| Metabase. Switched to Adopt and didn't look back
| bombcar wrote:
| Nothing - but any of the "vendor JDK" they recommend on that
| vendor's platform only - see RedHat for another example.
| verst wrote:
| And a similar question for the Microsoft build. This isn't
| Azure or Windows specific at all.
| weissed wrote:
| I had the same thought, what's the reason this is not
| recommended outside AWS?
| topspin wrote:
| I had no idea anyone thought Corretto should be isolated to
| AWS. I've found nothing wrong with it.
| 8organicbits wrote:
| The author doesn't justify it but I suspect the thinking is
| related to how fixes are prioritized.
|
| If there is a bug/performance issue that only happens in the
| context of AWS, then Corretto would be the most likely to
| rapidly patch the issue as it impacts their customer base.
| Potentially patches for those sorts of issues would be
| discovered by AWS through their own use and testing.
|
| Likewise for the other vendors and their own platforms.
| pron wrote:
| Here's my recommendation (I work on OpenJDK at Oracle):
|
| If you're using the current JDK version (recommended for
| regularly maintained applications), it doesn't matter which
| distribution you choose, as they're all pretty much identical. If
| you're using an old version (LTS, intended for legacy
| applications, which might benefit from it), pick a vendor you
| trust for OpenJDK support, as the builds are _not_ the same, and
| neither is the support. After Oracle, which contributes about 90%
| of the work on OpenJDK, the companies distributing builds that
| contribute to the project and have experience with it are (in
| rough order of experience and /or contribution): Red Hat, SAP,
| Azul, Bellsoft, and, more recently, Amazon, and Microsoft.
|
| There are, however, a couple of standouts: Alibaba's Dragonwell,
| which, last I looked, did not meet the Java specification, and
| Eclipse Adoptium, built by IBM, which is the only distribution
| built by a team that isn't involved with the OpenJDK project,
| isn't very familiar with it, and isn't a member of the OpenJDK
| Vulnerability team, and so get security patches only after the
| other vendors have delivered their builds.
| easton wrote:
| > Eclipse Adoptium, built by IBM, which is the only
| distribution built by a team that isn't involved with the
| OpenJDK project
|
| Wasn't AdoptOpenJDK the "legit" recommendation a couple years
| ago? I only heard about all of these other versions sometime
| later. (Looking again, it looks like the Oracle OpenJDK is
| shipped in Ubuntu's repos, so maybe I was mistaken).
| dtech wrote:
| It was, it recently transferred to Eclipse
| ed25519FUUU wrote:
| Interesting about a Adoptium, since that's the recommended JVM
| in the article.
| mayli wrote:
| I was using adopt jdk since that's much easier to download
| the jdk (especially jre) for Windows and Linux. The new
| Adoptium didn't git a jre build, which is sad :(
| Erlangen wrote:
| SAP provides a friendly interface for both JDK and JRE for
| Windows and Linux.
|
| https://sap.github.io/SapMachine/
| flatiron wrote:
| Honestly if you are using Linux you should be using the
| distros Java.
| krzyk wrote:
| Why? Distros javas are usually way too old to use.
| Seirdy wrote:
| Almost all distros ship at least openjdk-11, and many
| including Debian have openjdk-17 now.
| zylepe wrote:
| The jre is deprecated in favor of jlink, they have an
| explanation here: https://blog.adoptium.net/2021/10/jlink-
| to-produce-own-runti...
| mayli wrote:
| > Recommendation: Do not use Oracle Java SE Development Kit
| (JDK), unless you know what you are doing.
| WalterSobchak wrote:
| I wonder why this site doesn't enforce HTTPS, which it clearly
| supports.
|
| https://whichjdk.com/
| shartacct wrote:
| What reason is there to force https on a stateless static page?
| The content is always the same. You're just ruining caching and
| wasting CPU cycles.
| eropple wrote:
| It protects visitors on compromised networks--and that
| includes things like ad injectors at coffee shops that might
| push nasty code to them, not just people dealing with
| oppressive regimes and so on. It also provides some benefit
| around "well, _that page_ is HTTPS, so it 's more
| interesting"--if every page is HTTPS, the signaling value of
| switching to HTTPS is destroyed, and that is a good thing.
|
| HTTPS everywhere is a positive, and it is a good thing to do.
| shartacct wrote:
| Ad injectors on public wifi is a marginal 'risk'
| considering this page is targeted to professionals and
| informed hobbyists anyway, who will predominantly just be
| browsing from home, work or with a VPN that tunnels traffic
| through either a server they control or a service
| provider's server whom they trust anyway.
| eropple wrote:
| All risks are marginal when you handwave hard enough.
|
| TLS is basically-free in 2021. It's fine and it is good
| to do.
| ogurechny wrote:
| "Specialists" drinking the Kool-Aid look most depressing.
| Don't you find it strange that each time each proponent
| believes it's important to mention a stereotypical script
| kiddie on a public WiFi, something that doesn't bother a
| lot of people at all because of they way they connect to
| internet, and hasn't been a common occurrence even in the
| days of completely broken wireless security protocols?
|
| What is/was common is internet providers' interest in
| making money on personal behavioral data in the traffic
| they transfer. DPI boxes to passively gather statistics or
| actively inject ads (and even rewrite existing ads) have
| been offered and tested since the 2000s across the world.
| Scale of big ISPs would make them Google's (&Co)
| competitors on personal behavioral data market, and mobile
| ISPs would combine it with location data, too. Moreover,
| they would be able to use Google's own tracking cookies to
| track individual users instead of inventing the
| classification systems (either by observing them in clear
| text, or by injecting scripts). The security and income of
| web services is the real reason for the global "HTTP is
| deprecated, switch to HTTPS" campaign, not you and your
| "privacy".
| WalterSobchak wrote:
| That's a very old fashioned way to think about it.
|
| Here are some pages that list some of the reasons:
|
| - https://whynohttps.com/
|
| - https://www.cloudflare.com/learning/ssl/why-use-https/
| armchairhacker wrote:
| I was literally just looking at JDK comparisons out of interest
| (I already have my app running under a JDK). But I'm still not
| convinced which is the "best" one.
|
| What are some difference between OpenJDK, Adoptium, Azul,
| BellSoft, etc. besides company dependencies and lifecycle? Which
| JDK is the fastest, or do certain JDKs perform faster under
| certain scenarios? Do any of these JDKs have any special
| features, or can they not do certain advanced reflection (e.g.
| for efficiency?)
|
| I use IntelliJ so switching JDK is very easy, and most apps work
| on any JDK. Plus I doubt anything I release would be relevant in
| the long term (at least without the ability to upgrade JDK). So I
| really don't have to depend on any JDK, and seems like I don't
| have to worry about my JDK getting obsolete. Is there still a
| reason why I would prefer to use one JDK over another?
| iamcreasy wrote:
| Why its recommends against using OpenJDK builds by Oracle? Does
| it come with the same licensing restriction as Oracle JDK?
| aiobe wrote:
| OpenJDK builds by Oracle are updated only for 6 months, even
| for LTS versions. Plus these builds are provided for limited
| platforms only and have no official ready-to-use Docker images.
| miked85 wrote:
| What do Docker images have to do with a JDK decision? Build
| your own image if you want.
| krzyk wrote:
| Well, I use those, because I uprade every 6 months. And my
| company forces me to use theirs docker image and I put java
| on top of it.
|
| BTW. Limited platforms, but covers most of the cases (64 bit
| linux, windows, mac plus aarch64 for linux and mac)
| tyilo wrote:
| Maybe if you read the page, you'll find out!
| miked85 wrote:
| The rationale on the page is that the latest LTS version lags
| the latest release, which is expected and not a good reason
| to recommend against it.
| [deleted]
| modeless wrote:
| What a great site! I have often wondered about these things but
| I'm not a Java guy so I never investigated for myself. I've never
| heard of Adoptium before but it sounds like the right choice.
| PaulKeeble wrote:
| It really is quite incredible what a mess has made of the clear
| stability of Java and what to get since Oracle took over.
| ternaryoperator wrote:
| When Oracle acquired Sun in 2010-11, Sun had not shipped a new
| release of Java in more than four years.[0] That's hardly a
| "stability" worth treasuring.
|
| Since then, Oracle completely open-sourced the JDK and the
| associated tools and gave the the compatibility kits to the
| community to use. The result is that there are now several
| different distributions of the JDK. This is undeniably a good
| thing.
|
| As to the 6-month release cycle, it allows the community to get
| new features on a much faster cadence than any of the other
| major languages. If it's too fast for your preferred way of
| doing things, stick with the LTS releases, which come out on a
| three-year cycle and include all the features from the prior
| releases.
|
| There might be reasons not to like Oracle, but their
| stewardship of Java has been pretty good.
|
| [0] https://en.wikipedia.org/wiki/Java_version_history
| yjftsjthsd-h wrote:
| > When Oracle acquired Sun in 2010-11, Sun had not shipped a
| new release of Java in more than four years.[0] That's hardly
| a "stability" worth treasuring.
|
| Sun went several years without releasing a new _major_
| version, but that same page lists frequent minor updates. So
| yes, I would call that exactly a stability to treasure.
| krzyk wrote:
| More like stagnation.
| yjftsjthsd-h wrote:
| I mean, yes, there were fewer major features, but there
| were feature releases in those minor updates; there's
| nothing wrong with having stable software. Are you also
| one of those people who complain that stable Debian and
| RHEL releases include old software? Not everyone wants to
| live on the bleeding edge, and Java was a heavily
| enterprise ecosystem (for better and worse:]).
| sneeeeeed wrote:
| Since Oracle took over we've had a release every few months.
| That's terrible. It should be a few weeks, at most.
| Traubenfuchs wrote:
| This is not an issue in reality where devs just use whatever
| chocolately, brew or apt-get pull for them to develop and use
| whatever is the latest docker image for prod usage.
| twic wrote:
| Agreed, with the caveat that what has been messed up is the
| clarity rather than the stability. AFAIK, there are plenty of
| options for freely-available, unencumbered, high-quality,
| reliable runtimes, and have been since Oracle got involved.
| It's just that it's been a headache to work out that this is
| true, and what you should use.
|
| I think the situation is much better now than it was. The daft
| renaming of AdoptOpenJDK is the only recent low point.
| spiralpolitik wrote:
| The general guidance is always use the last LTS release unless
| there is a specific feature in the non LTS releases that you
| can't wait for. So any new development should target 17 at this
| point.
|
| Unless you want serious long term pain then you shouldn't be more
| than one LTS release behind. So if you are not running on JDK 11
| or later you should be strongly thinking about upgrading.
| krzyk wrote:
| Why should I stick to LTS? All other versions aren't in any way
| less tested, you should always stick to the newest released JDK
| version, be it LTS or not, this way you get all the benefits
| (language features, performance gains) and security ones
| (security fixes always first land in the newest version, and
| are backported to the older ones).
|
| Upgrades now are pretty straightforward if you are past JKD 9 -
| with JDK 16-17 being a bit tricky, but less than JDK 9.
| throw63738 wrote:
| >> All other versions aren't in any way less tested
|
| Source?
| evercast wrote:
| OpenJDK serves as the upstream for many Java distributions
| (maybe all?) and it has no notion of LTS. LTS is just
| something to which vendors commit as outlined at
| https://openjdk.java.net/projects/jdk/17/ : "JDK 17 will be
| a long-term support (LTS) release from most vendors.".
|
| In other words, OpenJDK does not follow any LTS/non-LTS
| release cycle. Hence there is nothing special about Java 17
| vs 16 when it comes to stability.
| fwip wrote:
| Some people who want to run your software may have a policy
| of only running LTS versions.
|
| In some cases, this may be your ops team.
| klodolph wrote:
| The JDK itself may receive a similar amount of testing
| upstream, but libraries downstream tend to receive more
| testing on LTS JDKs.
| Zababa wrote:
| > All other versions aren't in any way less tested
|
| That depends. If most people follow the advice of "sticking
| to LTS", these versions will have way more users, and thus
| will be more "battle-tested", as in tested in production.
| colechristensen wrote:
| In large installations I have almost always had problems,
| some little, some big with major version upgrades of Java.
| shartacct wrote:
| > (language features, performance gains)
|
| There haven't been any notable language features added since
| java 9 besides some basic syntax sugar (which is already
| covered by stuff like lombok anyway).
|
| For features and performance you might as well just target
| .NET 6. It has things that have been perpetually 'too hard to
| implement' (read: oracle doesn't want to pay their engineers
| to impl it and will sue you if you do it yourself) like value
| types, generics without type erasure, no checked exceptions,
| etc. and with .NET 6 performance is better than OpenJDK
| across the board.
| vips7L wrote:
| > read: oracle doesn't want to pay their engineers to impl
| it and will sue you if you do it yourself) like value
| types, generics without type erasure, no checked
| exceptions, etc.
|
| All of this is currently being implemented in project
| Valhalla...
| shartacct wrote:
| Valhalla isn't anywhere near complete and has been in
| development for 8+ years, C# had these features before
| valhalla was even planned.
| throw868788 wrote:
| I never buy into the tech stack argument that things are
| being worked on (e.g you mention Project Vahalla but I
| see this across many languages and tools). Seen this
| argument used on a number of different technologies. It
| compares a future state to a current state to put the
| favored tech (the future state) in an equal or better
| position. It usually punishes innovative platforms as
| well; because it dismisses any reason to take them up.
|
| It's comparing apples to oranges - in this case .NET is
| also being actively worked on so may have other things by
| then. Compare current state only.
|
| The truth is each platform has prioritized features
| relevant to its context. For what its worth in my
| experience while the JVM has many more JIT optimisations
| and the like it tends to need them more of them given the
| lack of some of those features you mention (e.g. value
| types). Whereas .NET code allows value types, better
| management of memory (i.e. Span), reified generics etc so
| the focus has been to allow the user to optimise
| themselves where required where still allowing for a
| decent performance default. Many of the optimisations in
| the JVM wouldn't have the same bang for buck in .NET and
| vice versa.
|
| On a personal note I'm more of a fan of the .NET
| philosophy because the code is usually fast enough, and
| when I need to tune memory, avoid allocations, and do
| fast code it seems to offer more tools not in an unsafe
| context to do so. It allows a better "upper bound" of
| performance for core things IMO while keeping to
| bytecode/IL. Many benchmarks where the same level of
| application optimisation has occured from what I seen
| have confirmed this bias for me. YMMV
| krzyk wrote:
| Records, switch expressions, multi line strings and that is
| only language changes.
|
| You could call `+` syntatic sugar, just like anything past
| assembler being that.
| shartacct wrote:
| > Records, switch expressions, multi line strings and
| that is only language changes.
|
| None of those are features, they were desperately needed
| shorthands for common java idioms. This is like calling
| braceless if/for/while statements 'features', when
| they're purely syntax sugar that has fallen out of favor
| completely because there's been several major security
| vulns found in major projects due to their use and
| development oversight/code review failure
| (https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-
| a-got...), to the point where most companies ban writing
| them.
|
| Just off the top of my head:
|
| * LINQ. Added to C# in 2007, Java didn't get streams
| until 2014.
|
| * structs/value types, implemented in net framework and
| net core for 15+ years, but not present in java 17. Some
| oracle engineers have been working to implement them
| under project valhalla but it seems to be vaporware at
| this point after 8+ years of work.
|
| * unsigned types, no plans to implement in java (though
| IIRC it was originally planned as part of valhalla)
|
| * async/await
|
| At the feature level Java is stuck in the mid 2000s.
| Nobody wants to do the actual work on keeping it
| competitive.
| KronisLV wrote:
| These discussions inevitably end up as a flame war sooner
| or later.
|
| Regardless, i actually compared Java with .NET and their
| web frameworks as a part of my bachelors', everything from
| synthetic benchmarks for encryption and data processing and
| transformations, to things like shuffling JSON around. Now,
| it's all in Latvian and was a number of years ago, so it's
| not entirely relevant at this point, but i did have some
| tangible findings.
|
| In short: - both Java and .NET (then Core)
| are inconsistent in their performance - there are certain
| things which are slower in one technology than other by not
| using external optimized libraries. For example, Java had
| problems with writing deeply nested dynamically generated
| JSON with JavaEE libraries (now Jakarta), whereas .NET Core
| had problems with handling large amounts of text -
| their performance was largely comparable in most other
| tests, neither was faster by a factor of 10, like you'd see
| with Python and Ruby compared to either - thus, it's
| largely a matter of choosing the actual frameworks that
| you'll want to utilize properly and consider both the job
| market and business factors (familiarity with the tech
| stack, job market etc.) - in summary, they're close
| enough for it to not be a technical decision most of the
| time in real world circumstances (save for a few
| exceptions), but rather is a decision that depends on
| social elements
|
| Since then: - i don't believe that the
| observation of them being "close enough" has changed much,
| both in legacy code and otherwise - .NET Core and now
| .NET 6 has improved bunches with its runtime; Core was so
| successful it's essentially the future of the platform (i
| feel bad for developers who'll be tricked into working on
| legacy code with the old .NET and IIS, versus the new one
| and Kestrel) - JDK has improved bunches with its
| runtime and GC; the runtime situation is a bit complicated
| and cumbersome, considering the OP's article, but overall
| it's pretty usable, especially with frameworks like Quarkus
|
| If you care about benchmarks and vaguely realistic
| performance comparisons in the current year, simply have a
| look at the TechEmpower benchmarks: https://www.techempower
| .com/benchmarks/#section=data-r20&hw=...
|
| If you jump around the different tabs that compare which
| frameworks do what better, on average: -
| .NET is better for plain text - .NET is noticeably
| better for data updates - Java is noticeably better
| for JSON serialization - Java is noticeably better
| for single DB queries - Java is noticeably better for
| multiple DB queries - as for cached queries and other
| use cases, there's more variance - neither is better
| than the other for it to matter a lot
|
| These are probably better than me linking the bachelors'
| because it's done in a better controlled environment, with
| more resources, and a lot of people contributing to the
| source code of the benchmarks: https://github.com/TechEmpow
| er/FrameworkBenchmarks/tree/mast...
|
| In short, you're not necessarily wrong - there have indeed
| been great improvements to the .NET platform and it's good
| to see it finally being a capable and performant tech stack
| that you can use on *nix. But you're also not right: Java
| is getting similar attention, even though it's still
| lagging behind a few years in regards to "having its stuff
| together" (e.g. going from Oracle JDK to a more stable
| model + the JDK 8 to newer version shift, which is
| similarly painful with old .NET versions).
|
| To lighten the mood, i'd consider suggesting that anyone
| also have a look at Go, which is similarly performant and
| allows you to build runtime independent executables by
| default, which is easier than in either .NET or Java. It's
| also pretty easy to write and has seen good use for the
| development of tools, since its startup time is a tad
| better than either that of Java or .NET as well. Here's the
| three compared: https://www.techempower.com/benchmarks/#sec
| tion=data-r20&hw=...
| hawk_ wrote:
| any references/benchmarks for some realworld apps/services?
| and also what do you mean by oracle suing if you implement
| value types?
| shartacct wrote:
| > any references/benchmarks for some realworld
| apps/services?
|
| .NET 6 is vastly more performant than .NET 5, which was
| already faster than openjdk and openj9
| (https://devblogs.microsoft.com/dotnet/performance-
| improvemen...)
|
| > and also what do you mean by oracle suing if you
| implement value types?
|
| this one shouldn't need an explanation, oracle very
| commonly pursues frivolous lawsuits as a way of bullying
| money out of businesses that don't have the budget to
| fight them for years in various courts.
| hawk_ wrote:
| where does it say .net 5 was faster than openjdk? hotspot
| is a very sophisticated jit compiler that has probably
| 100 manyears put into it just in optimizations. given
| that .net added monomorphic/bimorphic call site
| devirtualization recently which is considered quite basic
| in the hotspot, it would be good to see real world usage
| comparison.
| throw868788 wrote:
| Where required there are ways to force it to
| inline/devirtualise yourself. For example using refied
| generics is one way I've seen - i.e. there is no
| interface/virtual casting since it takes a type that
| implements interface, rather than the interface itself.
| It allows you to make polymorphism compile time rather
| than runtime. Seem comparison libraries to Java (closed
| source) that have run much faster as a result.
|
| I do find people comparing Java and .NET Core often are
| compare apples to oranges however. Working on both
| languages it is just my opinion but the .NET platform is
| newer - it has a better "base" even without the same man
| hours. Much of the engineering time in both ecosystems is
| spent optimising for code typical to that ecosystem which
| is affected by history/legacy like any other software
| system.
| Zababa wrote:
| I don't see any mention of Java in the article you
| linked, do you have any source on .NET being faster?
| amarshall wrote:
| I'm confused why you're suddenly talking about .NET.
| shartacct wrote:
| There's no real reason to use java for new development in
| 2021.
| ptx wrote:
| Here is one real reason to prefer it over .NET Core:
| https://github.com/dotnet/sdk/issues/6145
| tester756 wrote:
| why actually? what does it send?
| chrisseaton wrote:
| Java has a better technology stack. The JVM is light-
| years ahead of the .NET runtime.
| shmel wrote:
| Err... Not defending Java, but does .NET support Linux at
| all?
| shartacct wrote:
| Yes. It's ported to every mainstream CPU architecture and
| OS.
| seedie wrote:
| Yes, https://github.com/dotnet/core/blob/main/release-
| notes/6.0/s...
| rsj_hn wrote:
| Yes, via mono:
|
| https://www.mono-project.com
| tester756 wrote:
| .NET Core is main support for Linux for .NET
| shade wrote:
| Yes - .NET 5 and 6 both have runtimes and SDKs available
| for Mac and Linux. At least in my opinion, Linux is the
| preferred deployment platform for it now unless you have
| a specific (usually older) library that only works on
| Windows.
| matsemann wrote:
| Then use Kotlin, and take advantage of the jvm and the
| ecosystem, and avoid basically all the stuff you listed
| about the java language.
|
| "no real reason" is a stupid take. I could list multiple,
| but a big one is that there are hundred java developers
| for each dotnet developer in my city. The java env is
| well tested and well understood, if anything one should
| argue why _not_ use it instead of a hip and trendy
| alternative.
| shartacct wrote:
| > take advantage of the jvm
|
| In what way? It's slower and has less features than the
| .NET runtime.
|
| > "no real reason" is a stupid take. I could list
| multiple, but a big one is that there are hundred java
| developers for each dotnet developer in my city. The java
| env is well tested and well understood, if anything one
| should argue why not use it instead of a hip and trendy
| alternative.
|
| So, your only credible excuse for using java is inertia
| from boomers and middle managers refusing to adapt from
| the standard of the early and mid 2000s?
| Zababa wrote:
| > So, your only credible excuse for using java is inertia
| from boomers and middle managers refusing to adapt from
| the standard of the early and mid 2000s?
|
| If you come in and freely migrate all of the Java
| codebases to .NET while maintaining code quality and
| functionalities, I'm sure many people would let you do
| it. If you don't understand why people stick to one
| language, that means that you've never worked on a big
| codebase, or completly ignore the business side of the
| developer job. In both cases, that's a lack of wisdom on
| your part.
| shartacct wrote:
| I guess you missed the 'new development' part of my
| original comment? Obviously it would be nonsensical to
| port a large extant codebase to a new language and tech
| stack if it's just being maintained.
| Zababa wrote:
| Their point about using .NET were not really valid since
| one of the big and best reason to use Java is that you
| already have a Java codebase, but things like value types
| and generics without type erasure aren't solved in
| Kotlin, so Kotlin isn't really a good answer to his not
| really valid point.
| ptx wrote:
| > things like value types and generics without type
| erasure aren't solved in Kotlin
|
| Perhaps not solved, but at least partially addressed with
| value classes[1] and reified type parameters[2].
|
| [1] https://kotlinlang.org/docs/inline-classes.html
|
| [2] https://kotlinlang.org/docs/inline-
| functions.html#reified-ty...
| sneeeeeed wrote:
| Java is way better than .net, which nobody at all uses
| outside MS. Certainly not in enterprise.
| Zababa wrote:
| > Certainly not in enterprise.
|
| Lots of people use .NET in enterprise, I don't know where
| you got that impression.
| tester756 wrote:
| >Certainly not in enterprise.
|
| pretty odd take, in which country?
| erikerikson wrote:
| LTS = long term support
|
| Support for vulnerability patches, stability, and so on. You
| can automatically update and maybe that goes well and maybe
| problems are caught in testing. Regardless those events and
| changes have over time have increased costs. LTS should mean
| lower costs both through increased support focus, increased
| population of active users, and reduced forced change.
|
| You're not wrong...
| KronisLV wrote:
| Currently upgrading a ~1M SLoC Java enterprise app (with
| regular Spring, Jetty in there, scheduled processes, PrimeFaces
| for web UI, REST API services, SOAP services, the whole
| shebang) from Java 8 to Java 11 (since 17 wasn't out when that
| change was approved) and it's largely proving to be a pain.
| Since the version of Spring is ancient and changes over to
| Spring Boot were also approved, now have to rewrite parts of it
| and also get rid of the XML configuration and other old
| approaches which are simply no longer compatible with this
| upgraded tech stack. It feels like something that perhaps a
| team should do, instead of one dev over a month or so, but
| scope creep and estimates for something like that are nigh
| impossible, so we'll see.
|
| My point is that migrating to new releases isn't always
| trivial, especially the more complicated and complex a project
| gets. If i knew that i'll run if compiled successfully, then it
| wouldn't be too bad, but with the amount of reflection, dynamic
| class loading etc. that frameworks like Spring favor, my
| workflow to date has been fixing a bug, building and running,
| something else breaking, fixing that bug, building and running,
| something else breaking, realizing that i cannot fix this
| because upgrades to the logic would be inherently "lossy" due
| to a mismatch of what the new framework versions provide,
| making it so that breakages that aren't covered by tests will
| also be created and so on ad infinitum.
|
| Sometimes it makes me wonder why JDK 9 onward just didn't have
| a compatibility module: "Here, install this to have all of the
| old Java classes that were removed from the standard library
| after JDK 8 and retain that old functionality for software
| projects that would otherwise be stuck in development hell
| short of a full rewrite." Or something like that for Spring
| Boot, that lets you use web.xml instead of having to use hacks
| to load its contents and register all of the servlets, with
| half of them not working anyways, because some class names were
| changed along the way.
|
| Software doesn't always age beautifully.
|
| Furthermore, it feels like new runtime and package versions are
| made in ways that accidentally break backwards compatibility
| with no clear ways to avoid this.
| zz865 wrote:
| Just do the 8-11 upgrade first. The XML part has a lot of
| life left in it, still lots of advantages over attributes.
| swsieber wrote:
| I hope you move to spring voot first vefore upgrading to
| JDK11, or vice versa.
|
| I'm in the middle of a migration to 11 and my general
| approach has been to get it compiling on 11 while targeting 8
| with (--release 8). That seems to catch a great many things
| that would otherwise fail. The hardest part thus far was
| figuring out the appropriate libs to replace Java 8 ee stuff,
| mostly wrt soap and xml. I'm hoping moving to 11 goes
| smoothly but we'll see. I'm hoping to have the artifacts to a
| point where they can run on either 8 or 11 without issues.
| stickfigure wrote:
| It sounds like the problem is the scope creep. Do the JDK
| upgrade _or_ the spring boot migration first. Yes it is
| tempting to do both at once but you are adding a lot of risk.
| KronisLV wrote:
| Agreed! Sadly, it wasn't my choice to make. Then again, if
| it's an older version of Spring, chances are that a lot of
| changes would be needed regardless.
| virtue3 wrote:
| I think this is one of the few benefits of micro service
| architectures. You end up with much smaller pieces to migrate
| over. And if the service is well defined and you have ample
| logging for endpoints you actually could re-write it.
|
| Mind you; you usually end up with the services all in
| different states of node/jdk/etc versioning(at least the
| companies I worked at).
| AmpsterMan wrote:
| We had that about a year ago in our product as well, though
| from Java 7 to Java 11. That JDK 9+ hump was definitely bad,
| but since then each incremental JDK has been smooth. The idea
| of using "the latest JDK" is fairly modern in the Java world,
| so people are still getting used to it. I'd say it's good now
| though, with perhaps 16 -> 17 being a minor hump since things
| that were deprecated but allowed in 9+ are now removed.
| chrisseaton wrote:
| Can you give a specific technical problem with updating from
| 8 to 11? Everyone says it's hard - nobody's ever able to give
| a practical example of a problem.
| jeroenhd wrote:
| Oh, I have a fun one. The company I work at leverages
| Nashorn for running some user-customizable scripts and when
| upgrading from 8 to 11 we found out that Nashorn changed
| the way they express numbers under the hood. Basically,
| every number is either an integer or a float and it used to
| be that every number was a long or a float.
|
| This silently broke a bunch of scripts and callbacks
| because of class cast exceptions and such. The solution was
| to rewrite the scripts in such a way to import the Java
| Long class and use that directly to express large integers.
|
| The most important breaking issues I've found were not
| necessarily in our code base, but in dependencies.
| Libraries that include libraries that include libraries,
| all doing their own thing, a lot of the time involving some
| pretty scary reflection stuff for some unexplained reason.
| Blindly upgrading libraries only gets you so far, sometimes
| a dependency gets abandoned and you need to find a
| replacement and rewrite your code to call the APIs in the
| right manner to be backwards compatible enough.
| chrisseaton wrote:
| > involving some pretty scary reflection stuff for some
| unexplained reason
|
| This is where it always seems to end up. Why do people
| bend over so far backwards doing reflection that isn't
| specified?
| KronisLV wrote:
| I sadly didn't write everything down, or didn't keep
| references to the GitHub issues, but here's a few of the
| things that i ran into.
|
| Here's a list of the things that were available in JDK 8
| and no longer are: https://advancedweb.hu/a-categorized-
| list-of-all-java-and-jv...
|
| When you stumble upon something like that, at best you can
| import a Maven dependency with a version that has what you
| need, at worst you need to rewrite the code to use another
| library or set of libraries.
|
| If you have any low level logic like custom class loaders
| written against older JDK versions (think before 8), then
| they'll be forwards compatible until 8 for the most part,
| but will break afterwards. Coincidentally, reading code
| that deals with low level logic is also not easy to do,
| especially if it's not commented well.
|
| If you rely upon reflection, or use advanced language
| features (like the JasperReports framework for generating
| PDFs, which also has a build step for building the
| reports), in some cases things might compile but not work
| at runtime due to class mismatches.
|
| Many frameworks need new major versions to support newer
| releases than JDK 8, for example Spring Boot 1.5 needs to
| be upgraded, so you're also dealing with all the changes
| that are encapsulated by your dependencies. In another
| project that i also migrated, needed to rewrite a lot of
| web initialization code for Spring Boot 2.X.
|
| Not only that, but with those framework changes, certain
| things can break in the actual environments. For example,
| if you package your app as a far .jar, then you'll no
| longer be able to serve JSP files out of it. It makes no
| sense, but packaging it as a .war which can be executed
| with "java -jar your-app.war" will work for some reason.
|
| I some other libraries, method names remain the same, but
| signatures change, or sometimes things just get deprecated
| and removed - you have to deal with all of that, which is
| especially unfun in code that isn't commented but that the
| business depends on to work correctly. Throw in external
| factors such as insufficient coverage of tests and you're
| in for an interesting time. I'm not saying that it's a type
| of environment that should be condoned, but it's the
| objective reality in many software projects.
|
| Oh and i hope that you're also okay with updating all of
| your app servers (like Tomcat) or JDK installs on the
| server as well, especially if you depend on some of the
| Tomcat libraries to be provided and for your
| frameworks/libraries that depend on them being present at
| runtime to accept those new versions effortlessly. It all
| feels very brittle at times.
|
| This is especially a nightmare if your servers were
| configured manually - personally i'm introducing Ansible
| and containers to at least isolate the damage of Ops rot,
| but it's been an uphill battle since day 1.
|
| Here's an exceedingly stupid one: sometimes there are
| checks in code to make sure that you're using the right
| version of JDK (or even the Oracle JDK), which get confused
| with the larger versions. It's easy to fix when it's your
| code, but really annoying when it's external tools -
| personal nitpick.
|
| Addendum: here's something that i expected to break, but
| didn't. We use myBatis as an ORM. It has XML mapper files
| that define how to map entities and construct queries
| against the DB based on that. Also, it uses Java interfaces
| and dynamically calls the underlying XML code as necessary.
| So essentially you have an interface, which has a
| corresponding XML file in which you have quasi-Java code
| (e.g. checking what parameters are passed in to the query)
| that's used alongside a number of tags to dynamically build
| SQL queries. Here's an example:
| https://mybatis.org/mybatis-3/dynamic-sql.html
|
| Instead of something breaking in myBatis, what broke
| actually was Hibernate in the newer versions of Spring. Oh,
| and Flyway for DB migrations simply used to work with a
| particular Oracle DB version as well.
| krzyk wrote:
| JDK 8 -> 9 migration was painful, but all other upgrades
| should be painless (well, maybe the 16-17, but I assume that
| most libraries will be fixed by the time you upgrade - either
| add `add-opens` instructions or use appropriate new classes
| from JDK).
| __jem wrote:
| I got stuck in this conundrum at my previous gig as well, and
| think reached a very different conclusion than you. In short,
| while I'm skeptical of some of the degree of churn across
| modern software development as a whole, I'm not sure that
| this is actually an issue with the Java ecosystem, which has
| been, and I think continues to be, way more sensitive to
| backwards compatibility than almost any other ecosystem.
|
| In some ways, this is just a consequence of a kind of
| evolutionary leap forward for many applications. We don't
| deploy our WARs into application servers anymore, we try to
| pack a fat JAR, or maybe even a statically linked runtime,
| into a container. We rebuild the whole world on CI all the
| time. I mean, Java 8 has issues just respecting cgroup
| limits, which many a despondent ops engineer has discovered.
|
| I think there's still room for the 1M SLoC monolith even in
| this new world, but there are real benefits on the horizon
| for upgrading to Java 17 and beyond. We've reached a point
| where it's just more expensive not to make upgrades a regular
| part of you development cycle. And, no one is stopping you
| from just staying on 1.8. I mean, I'm sure there are still
| decaying enterprises stranded on 1.3.
| dtech wrote:
| In general you are right that the Java ecosystem is highly
| backwards compatible, but 9 is a bit of an exception. The
| module system breaks a lot more stuff than usual, and is
| the reason a lot of legacy is stuck on 8.
| KronisLV wrote:
| Personally, i'd never let a single monolith grow that far.
| Having a problem component or two that could be left on JDK
| 8 until they die and are rewritten (which would actually be
| possible with systems that have clearly defined boundaries
| and smaller scope), while migrating everything else.
|
| Sadly, i don't get that choice, nor do i get the choice to
| make the judgement call to leave the monolith on JDK 8 in
| the name of stability. But hey, at least i'm paid a bit of
| money for it, so i have some motivation to work on all of
| it to the best of my abilities, learn a bit more about the
| JDK internals, have a word or two to tell others about my
| experience before i inevitably burn out from the churn.
|
| Personally, i do still think that Java is pretty good when
| it comes to stability and backwards and forwards
| compatibility, especially since tooling like Maven is
| actually pretty good when compared to the alternatives
| (well, the parent POM functionality is confusing sometimes,
| but oh well, it has its use cases). That said, JDK 8 to
| newer releases was indeed a generational shift (probably
| one for the better) and you see similar things with Spring
| Boot 1.5 to Spring Boot 2.X, those breaking releases are
| inevitable.
|
| I only wish that the things blocking people from writing
| more modular systems would disappear over time, so that
| huge monoliths that are incredibly hard to work with
| wouldn't be such an issue. I'm not necessarily advocating
| for microservices here, since people tend to go straight
| from one ditch into the opposite one (multiple services per
| person, nightmarish service mesh, needlessly large % of the
| code being for shuffling data around, suddenly building a
| distributed system even within a single domain), but at the
| very least it would be really nice to have someone look at
| it and say: "Hey, this PDF generation logic looks really
| brittle and perhaps should be a service of its own." or
| maybe: "Oh, hey, we're serving our RESTful API calls and
| front end resources from the same application, maybe we
| should have a separate front end app, served through a
| regular web server?"
|
| Then again, if nothing else, i always have the choice to
| choose where i'm employed, even though i don't feel like
| letting my coworkers down at the moment either.
| DarkmSparks wrote:
| There is more to this now tho, because even their topline
| recommendation misses the fact that Temurin (anagram of
| runtime) only provides a small subset of tested builds you
| need.
|
| They are in there but easy to miss - Bellsoft actually have
| builds for both jdks and jres for more than mainstream x86_64.
| Termurin dont even have jres anymore (last time I checked)
|
| https://bell-sw.com/pages/downloads/#/java-17-current
| krzyk wrote:
| Are JREs still a thing (they were removed from Oracle builds
| in JDK 9)? Those were mostly for applets or JWS.
|
| Nowadays no one keeps just one JRE in their laptop/desktop
| and disk sizes are in TBs so no point in saving 100 MB and
| lacking development tools.
|
| And in one targets containers or systems with small amount of
| disk jlink give more gains than JRE.
| DarkmSparks wrote:
| If you are distributing software based on java a 40mb jre
| in place of a 400mb jdk is surely preferred. You can build
| them yourself for each OS you target with jlink, or you can
| just grab the latest built and tested one from e.g.
| Bellsoft - but not Adoptium or Oracle.
|
| Java has been "breaking changes" between releases to make
| python blush for a few years now, 17 finally looks like a
| worthy migration from 8.
| pron wrote:
| The safest, cheapest choice for applications that are heavily
| maintained is to use the most recent version. LTS is designed
| for legacy applications that are no longer heavily developed,
| and might benefit from security and bug fixes only (note that
| this model is new; in the past, back when there were major
| versions, minor updates included both patches and big
| features).
| fwip wrote:
| It also depends on your target environment, and how much
| control you can exert over the machine where your software
| will run.
|
| Sometimes you're creating an app that other users need to run
| in their own environments - and in that case, targeting
| "latest LTS" is safer, as they may have requirements on what
| they can run that you don't.
| pron wrote:
| True, there are, indeed, times when you _can 't_ use the
| current version, but note that Java applications are now
| encouraged to bundle their own runtime (generated with
| jlink).
| karmakaze wrote:
| 'heavily developed' is the operative consideration as this
| means upgrading (not merely updating) your Java installations
| every 6 months.
| krzyk wrote:
| Which is quite painless, I do it since JDK 10, upgrade up
| to 1 week after JDK release and it was painless (with one
| exception around JDK 12 or 13 where spring have some issue
| for 1 month until I could upgrade).
| pron wrote:
| With major releases gone, this isn't hard, and, overall
| cheaper and easier than upgrading less frequently. But it
| is _some_ work, which is why the LTS service was added for
| the benefit of legacy applications. Note that under the old
| model, LTS didn 't exist. There was a new feature release
| every six months that everyone _had_ to upgrade to. The
| names of those releases didn 't stand out as much (8u20,
| 8u40 for feature releases [1] as opposed to, say, 8u25,
| 8u45 for patches) as they do now when we did away with
| major releases and gave every new feature release a new
| integer number.
|
| Because now the feature releases can add new APIs rather
| than just new JVM features as they did under the old model,
| this process can be slightly more work, but still
| significantly less work over time. As regularly maintained
| applications update code and dependencies regularly,
| anyway, this is a clear win. Not only is the upgrade
| process easier and cheaper, but you get to enjoy the
| regular and significant performance improvements that have
| always been part of the six-monthly feature releases, but
| aren't in the LTS patches.
|
| [1]: Those feature releases under the old model also added
| major new features with significant changes to the VM. For
| example, the G1 GC and JFR were added in feature releases.
| smarx007 wrote:
| I think this advice only applies to the end users of the JDK and
| libs, e.g. people who develop webapps. We maintain an OSS library
| and plan to support JDK 8 for as long as possible (though some of
| our dependencies made a move to JDK 11 and most likely we'll have
| to follow suit). With this approach, our libraries can be used by
| developers under JVM 8, 11, or 17.
| yjftsjthsd-h wrote:
| _Thank you_ ; it is so appreciated when libraries don't abandon
| old versions.
| rococode wrote:
| These recommendations are pretty arbitrary and don't even attempt
| to scratch the surface of what is actually materially different
| between the JDKs. Don't use Corretto outside of Amazon... why?
| Don't use Dragonwell because... China bad? Use Red Hat OpenJDK if
| you're running on Red Hat servers, Microsoft OpenJDK if you're on
| Azure, SapMachine if you're on SAP, because... the name matches
| so that's nice? At least they're consistent on that point. There
| are (generally pretty niche) reasons to pick specific distros,
| but those reasons certainly aren't discussed here.
|
| I feel like the actual decision process is fairly straightforward
| in nearly all cases:
|
| - Use whatever vendor happens to be most convenient to install.
| If nearly everyone using your OS is installing Java one way, and
| you're installing it some other unusual way, you should be
| crystal clear about why exactly you need to do that.
|
| - Generally go with JDK 11, if you may have to deal with older
| software then maybe go with 8, if you want the shiny new stuff
| and don't mind some extra hassle then go with JDK 17 (it's not
| well-supported by everything yet).
|
| That's pretty much it. There are exceedingly few cases where it
| actually matters whether you installed Corretto or Oracle
| OpenJDK, and in those cases you'll likely end up either testing
| all the JDKs anyway to make your decision or writing your own
| patches for whatever you need.
| morpheuskafka wrote:
| > Use Red Hat OpenJDK if you're running on Red Hat servers,
| Microsoft OpenJDK if you're on Azure, SapMachine if you're on
| SAP, because... the name matches so that's nice?
|
| Presumably this has to do with support and possible testing.
| People buy RedHat EL for the longterm support, if they use a
| different vendor for the JDK they have to set up a whole new
| contract for that with a different company. By contrast, people
| using a free Linux distro may not have any benefit to using
| RedHat's JDK.
| Decabytes wrote:
| I've tried more than once to learn Java I find it very confusing.
| This website resolves one of the issues. The other issue I have
| is that most Java tutorials use IntelliJ, or some other IDE,
| which makes it difficult to figure out what a non IDE workflow
| actually looks like, some managing dependencies is confusing.
|
| I wonder if c# and mono is better in this respect
| gadrev wrote:
| C# in mono has the csharp interactive prompt, and you can also
| use it to run script files (like .csx).
|
| Java often uses IDE but there are tools to run a REPL. Groovy
| had this before Java got it. You can use it to write Java,
| since Java code is Groovy. It comes with a GUI console into
| which you can type and evaluate too, or you can write script
| files and run them. It's not as fashionable nowadays as it used
| to be (now it's Kotlin, Scala, etc.) but it works great and can
| be useful for learning Java too.
| the8472 wrote:
| java itself ships no build and dependency management tools. So
| you get either the built-in stuff that IDEs offer or use maven,
| gradle, ant. For toy programs you can also invoke javac
| directly but as it grows it quickly gets as impractical as
| compiling large C codebases by hand.
| AmpsterMan wrote:
| What programming language are you comfortable with? I'd say
| syntactically Java is fairly simple and at least superficially
| similar to C/C++. Environment wise, it's definitely very large
| and oriented toward "powerful but complex" rather than "simple
| and orthogonal". For build and dependency management systems,
| Gradle or Maven are your tools. I personally prefer Gradle
| since it uses a programming language for it's configuration,
| rather than xml.
|
| There is definitely a lack "end-to-end" tutorials that don't
| rely on some form of tooling support. I would love to see more
| content on how to make a Java program with nothing but an
| editor and a command line, but I suspect there isn't much of a
| need for that. Java's tooling is exceptionally good, it's
| libraries mature and robust. Part of the reason every tutorial
| out there uses an IDE is because through quirks of history Java
| is basically an Enterprise programming environment where "Build
| the Right Thing" predominates over "Worse is Better".
|
| EDIT: There is a REPL included with each JDK after 9 called
| JShell. It's useful if you just want to get up to speed or if
| you want to test something quickly.
| npteljes wrote:
| The strongest plus I could say for Java is that it's a stable
| workhorse that pays the bills, and that the tooling is pretty
| good. Non IDE workflows don't exist practically, as a curiosity
| it's nice to compile something "by hand", but the knowledge is
| nonessential. Switching from one IDE to another is not that big
| of a deal, workflow-wise, you shouldn't worry about it.
|
| As a side note, I appreciate that we have multiple tooling for
| Java. It doesn't sit well with me when the whole language, and
| its IDE and compiler and everything is bundled up in one
| package and that's all you have.
| Something1234 wrote:
| I think most languages have a really difficult to configure
| environment if you mess it up or need to keep multiple versions
| around. Windows is especially bad about it because of the
| java_home variable. Mono is a mess to configure on Linux, or at
| least the last time I tried it to learn F#.
|
| Java is actually nice in that a lot of distros are packaging a
| version manager for it. Arch and centos lead the pack in this.
| Although cent continues to be a mess about how many jdks and
| Jres are available.
| ahmedfromtunis wrote:
| I wish there were a section like this one in every tools'
| home/download page.
|
| A section called "For production use this" or "if you don't know
| what you're looking for, use this". And "this" can be a
| particular version (Ubuntu 20.04.6) or a rule of thumb (for
| production, always use x.y.1 version or above).
|
| Or it can be a table like this one. Django is, as it is in many
| fields, the gold standard in this regard.
|
| It gets confusing sometimes. Yesterday I was trying to update the
| python version of one of my applications and was wondering;
| should I do it now, or do I need to wait for 3.10.1? I did it
| anyway because the app barely gets traffic anyway, but more
| clarity is always welcome.
| miked85 wrote:
| I find some of these recommendations confusing, there doesn't
| seem to be reasons to back them.
|
| For example: > _Use Corretto, only if you run Java applications
| directly on Amazon Linux 2 in AWS_
|
| Why?
| ryanmarsh wrote:
| What a zoo. So glad I'm not trying to deploy Java workloads
| anymore. It used to be the best JVM was the Sun JVM and everyone
| used it.
| ypcx wrote:
| Use Openj9 to lower your RAM requirements. Use HotSpot for
| compatibility with tools like heap/thread dumpers and I guess
| profilers/debuggers.
| bombcar wrote:
| No mention of GraalVM - https://www.graalvm.org - perhaps because
| it's Oracle?
| zh3 wrote:
| For those of us supporting more than a few legacy apps, use the
| oldest version (7 in our case) because then there's less chance
| of things going wrong (depends, of course, whether you bill per
| support call or a fixed annual fee).
| isbvhodnvemrwvn wrote:
| I don't understand this way of thinking, do you also run RHEL 4
| on your servers?
| zh3 wrote:
| No, too unreliable.
| [deleted]
| numpad0 wrote:
| That'll be insane but half-yearly releases of a language
| spec/language hybrid is insane too, which is what Oracle is
| doing recently.
| foepys wrote:
| Sometimes there is just not enough resources (time,
| developers, expertise) to update the project. Those projects
| are often internal and never see the outside of a companies
| network.
| underscore_ku wrote:
| java --version
|
| openjdk 11.0.11 2021-04-20
|
| OpenJDK Runtime Environment (build 11.0.11+9-Ubuntu-0ubuntu2)
|
| OpenJDK 64-Bit Server VM (build 11.0.11+9-Ubuntu-0ubuntu2, mixed
| mode, sharing)
| TheDesolate0 wrote:
| none.
| Thev00d00 wrote:
| What is this naming? Embarrassing levels of bad "Adoptium Eclipse
| Temurin OpenJDK "
| shagie wrote:
| Adoption is the project umbrella under the Eclipse Foundation.
| Temurin is the project. OpenJDK is the artifact.
|
| https://projects.eclipse.org/projects/adoptium
|
| > The mission of the Eclipse Adoptium Top-Level Project is to
| produce high-quality runtimes and associated technology for use
| within the Java ecosystem. We achieve this through a set of
| Projects under the Adoptium PMC and a close working partnership
| with external projects, most notably OpenJDK for providing the
| Java SE runtime implementation. Our goal is to meet the needs
| of both the Eclipse community and broader runtime users by
| providing a comprehensive set of technologies around runtimes
| for Java applications that operate alongside existing
| standards, infrastructures, and cloud platforms.
|
| Under Adoption, there is:
|
| * Eclipse Adoption Incubator
|
| * Eclipse AQAvit
|
| * Eclipse Mission Control
|
| * Eclipse Temurin Compliance
|
| * Eclipse Temurin
|
| But yea... the name is awkward.
| easton wrote:
| It sounds like something Microsoft would come up with. Well,
| it's missing a "NT Azure Client Access License".
|
| Why didn't they just keep AdoptOpenJDK? That was a good name
| IMO.
| shagie wrote:
| From https://developer.ibm.com/announcements/adoptopenjdk-
| has-a-n... (Eclipse is sponsored by IBM)...
|
| > Along with the move to the Eclipse Foundation, the
| project has a new name: Eclipse Adoptium. The move and name
| change are being made to ensure vendor independence and
| long-term viability of the project. As you know, the
| Eclipse Foundation has a number of key projects, such as
| Jakarta EE, under its umbrella, with the foundation
| providing the necessary legal and operational support for
| its projects.
|
| I suspect that part of this is that it has _more_ to it
| than just the JDK.
| smarx007 wrote:
| https://adoptium.net/ "Eclipse Temurin is the name of the
| OpenJDK distribution from Adoptium."
|
| Eclipse Temurin 17 or Temurin JDK 17 should be sufficient.
| tinus_hn wrote:
| I wonder how good the adoption is for that product. Didn't
| they adopt a new name recently?
| sireat wrote:
| So for those running Scala in production, which version do you
| use?
|
| I am still seeing a lot of projects on 8.
|
| New Scala projects are generally on Corretto 11.
| miked85 wrote:
| I've never heard of Adoptium Eclipse Temurin before. It looks
| like all releases were just within the last few months, but this
| is the recommendation? Seems a bit strange.
| traspler wrote:
| It's the successor to AdoptOpenJDK:
| https://blog.adoptopenjdk.net/2021/03/transition-to-eclipse-...
| nlitened wrote:
| Is there a way to apt-get the new JDK 17 as a package on Ubuntu,
| instead of piping a shell script from curl or unzipping a tar?
| Does anybody use package managers on Linux anymore?
| needusername wrote:
| Getting Java through apt-get gives you more or less the worst
| quality builds
| https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-May/0...
|
| You get mystery bits that haven't been put through the TCK.
| nlitened wrote:
| I think a custom package repository could be a proper
| solution then. This way one would get version upgrades for
| free. Much better than installing (curl-piping) yet another
| package management tool `sdkman` with a new syntax.
|
| Though, I might be missing some important details, and I
| would love to understand it better.
|
| Edit: a sibling comment suggested that now there's a package
| repository for that, and indeed there is.
| severino wrote:
| Last time I checked, at least in Ubuntu 20.04, there was
| already a package for OpenJDK 17, so I think that's the
| straightforward and recommended way to get Java 17 in Ubuntu.
| nlitened wrote:
| Wow, you're actually right -- I wasn't able to find it before
| (maybe Java 17 was too new back then).
|
| If anybody's interested: sudo add-apt-
| repository ppa:linuxuprising/java sudo apt-get update
| sudo apt-get install oracle-java17-installer oracle-
| java17-set-default
| severino wrote:
| Yes, I checked some weeks ago and v.16 was the last one, so
| I guess it was too soon.
|
| However, you don't need a special repo for getting OpenJDK
| 17. Yours is for getting Oracle JDK 17, right?
| irq-1 wrote:
| Now do .NET :)
|
| No, seriously, we need the same thing for .NET
___________________________________________________________________
(page generated 2021-10-10 23:00 UTC)