[HN Gopher] How much faster is Java 17?
___________________________________________________________________
How much faster is Java 17?
Author : vips7L
Score : 242 points
Date : 2021-09-15 15:08 UTC (7 hours ago)
(HTM) web link (www.optaplanner.org)
(TXT) w3m dump (www.optaplanner.org)
| gavinray wrote:
| Taking this opportunity to promote the author of this article
| (Geoffrey de Smet) and the project he's been the lead of for some
| very long amount of time (Optaplanner):
|
| If you've never heard of constraints programming -- it's really
| interesting (personal opinion).
|
| It lets you programmatically state "rules" and "goals" of some
| system, and solvers will automatically attempt to find the best
| solution.
|
| Optaplanner is one of the most advanced of such engines that I'm
| aware of: Under the hood, OptaPlanner combines
| sophisticated Artificial Intelligence optimization algorithms
| (such as Tabu Search, Simulated Annealing, Late Acceptance and
| other metaheuristics) with very efficient score calculation and
| other state-of-the-art constraint solving techniques.
|
| But it's also really approachable since they re-wrote it in 2020
| to accept regular code for rules, instead of the custom DSL
| language they used before (Drools).
|
| https://www.optaplanner.org/blog/2020/04/07/ConstraintStream...
|
| I got interested in this area some years ago, and reached out to
| Geoffrey personally. He took the time to reply to me and answer a
| few questions. Great person, he's brilliant and super passionate
| about the domain.
|
| If you have any sort of practical usecase for this (scheduling,
| vehicle routing, cost optimization, etc) and this sounds at all
| interesting, highly recommend giving it a shot!
|
| As an example of what you can do in a few lines with this, here's
| one from the docs: The following code snippet
| first groups all processes by the computer they run on, sums up
| all the power required by the processes on that computer using
| the ConstraintCollectors.sum(... ) collector, and finally
| penalizes every computer whose processes consume more power than
| is available. private Constraint
| requiredCpuPowerTotal(ConstraintFactory constraintFactory) {
| return constraintFactory.from(CloudProcess.class)
| .groupBy(CloudProcess::getComputer,
| sum(CloudProcess::getRequiredCpuPower))
| .filter((computer, requiredCpuPower) -> requiredCpuPower >
| computer.getCpuPower())
| .penalize("requiredCpuPowerTotal",
| HardSoftScore.ONE_HARD, (computer,
| requiredCpuPower) -> requiredCpuPower - computer.getCpuPower());
| }
|
| ---
|
| As a bonus, it's natively integrated into Quarkus and the Quarkus
| ecosystem. Quarkus is the best thing since sliced bread if you're
| on the JVM and are writing API's.
|
| https://docs.optaplanner.org/latest/optaplanner-docs/html_si...
| stncls wrote:
| Geoffrey de Smet, Optaplanner, and Constraint Programming (CP)
| are all amazing indeed. If we're talking about underhyped tech
| that _actually_ works wonders in practical business problems, I
| would also take advantage of the limelight to include the whole
| CP field (including other solvers like Gecode), SAT solvers
| (MiniSat, Lingeling, Glucose, Chaff, ...) and SMT software
| (MiniZinc, Z3, ...), and Operations Research / mixed-integer
| programming (MIP) in which unfortunately open source software
| lags behind the stat of the art (Gurobi, Fico XPress).
| thechao wrote:
| I wish, SMT-solvers, in particular, were easier to approach.
| I have a number of problems that are solved once-per-month,
| that I wouldn't mind throwing a couple of weeks of compute at
| to get absolute tip-top results.
|
| Posing SMT-problems though ... that's an art. There's not
| enough resources for "problems at scale" for me to just dip
| my tie into...
| mzl wrote:
| Strong recommendation to take a look at MiniZinc. It's a
| modeling language for combinatorial optimization problems,
| and is often quite easy to model problems in it. The cool
| thing is that one can then solve the problem using many
| different solver technologies.
| tra3 wrote:
| Is there an intro you can recommend? I've never heard of
| CP, would love to read about it.
| mzl wrote:
| There are a couple of very good coursera courses on
| modeling with MiniZinc, the first one being
| https://www.coursera.org/learn/basic-modeling
| lsuresh wrote:
| If you're interested in this topic, we're building a tool for
| building cluster manager components (like policy-based
| container schedulers) using constraint programming, where
| constraints are specified using SQL.
|
| Paper: https://www.usenix.org/system/files/osdi20-suresh.pdf
|
| Code: https://github.com/vmware/declarative-cluster-management/
| gavinray wrote:
| Holy smokes, this is one of the coolest thing I've ever seen.
|
| This lets you use data from standard, JDBC-supported SQL
| databases and write constraints as plain SQL-like queries?!
| This reminds me of an idea I had about embedding a solver API
| in Postgres using it's extension functionality and being able
| to make SQL "VIEWS" that represent solver results, like a
| delivery route or employee roster. CREATE
| VIEW todays_employee_schedule AS SELECT ...
| CHECK row_satisfies_constraints(...)
|
| If I'm understanding this properly, this seems like this
| could be applied to general-purpose problems as well -- not
| just the one you're targeting right? //
| Create an in-memory database and get a JOOQ connection to it
| final DSLContext conn = DSL.using("jdbc:h2:mem:");
| // A table representing some machines
| conn.execute("create table machines(id integer)");
| // A table representing tasks, that need to be assigned to
| machines by DCM. // To do so, create a variable
| column (prefixed by controllable__).
| conn.execute("create table tasks(task_id integer,
| controllable__worker_id integer, " +
| "foreign key (controllable__worker_id) references
| machines(id))"); // Add four machines
| conn.execute("insert into machines values(1)");
| ... // Add two tasks
| conn.execute("insert into tasks values(1, null)");
| ... // Time to specify a constraint! Just
| for fun, let's assign tasks to machines such that the machine
| IDs sum up to 6. final String constraint =
| "create constraint example_constraint as " +
| "select * from tasks check sum(controllable__worker_id) = 6";
| // Create a DCM model using the database connection and the
| above constraint final Model model =
| Model.build(conn, List.of(constraint)); //
| Solve and return the tasks table. The controllable__worker_id
| column will either be [1, 5] or [5, 1] final
| List<Integer> column = model.solve("TASKS").map(e ->
| e.get("CONTROLLABLE__WORKER_ID", Integer.class));
| lsuresh wrote:
| Thank you for the kind words!
|
| Yes it could be applied to general problems as well. In
| fact, we used it once to plan a program committee meeting.
| The library (DCM) has no idea what problem setting its
| being used for, and has no semantic info about the problem
| other than the schema and constraints we tell it about.
|
| That said, the current focus is on things like incremental
| computation, debuggability, automatically subsetting the
| relevant state from the DB, and scalability to really large
| cluster sizes (O(50K) nodes), which are more useful in the
| cluster management context than general-purpose constraint
| programming tasks.
|
| Edit: Also worth mentioning is that your intuition is spot
| on. The earlier versions of the library went with a CREATE
| VIEW syntax as you wrote it out. Now that we have a
| customizable parser, we have since changed it to CREATE
| CONSTRAINT for clarity.
| renewiltord wrote:
| He's also a fairly good manager of PRs in my experience. He's
| sort of blunt which can be hard to deal with if you're used to
| more Anglo pleasantries but you can tell he's ultimately being
| helpful.
| vips7L wrote:
| I recently got super interested in constraint problems after
| reading Classical Computer Science Problems in Java. They were
| really fascinating (along with all the problems in the book).
| scns wrote:
| Thank you very much for the recommdation, looks like an
| amazing resource. Hopefully i'll be able to schedule time
| work through this. Would have loved to study CS but
| awesome/time consuming events in my life prevented it, which
| is totally fine.
| vips7L wrote:
| The author also wrote the book for Python or Swift if
| you're not into Java.
| WoodenChair wrote:
| Author here... thanks really appreciate the shoutout! The
| Java version is the most recent and probably the best
| version if you know multiple of the languages and have to
| choose between them. The Python and Java versions cover
| all of the same problems. The Swift version (the oldest)
| is missing a couple. You can find out more about all
| three, including links to translations in 9 languages,
| here: https://classicproblems.com/
| darksaints wrote:
| I would also add that Constraint Programming has a small but
| very dedicated community, and the amount of innovation in the
| space is incredible given how niche it is. Some things I find
| amazing:
|
| * Dozens of solvers with hundreds of search methodologies
|
| * Intermediate Language specifications (FlatZinc) to allow
| solvers written in one language to interact with completely
| different languages via a common intermediate language.
|
| * Entire catalogs of useful constraints
| https://sofdem.github.io/gccat/
|
| * Solver Competitions https://www.minizinc.org/challenge.html
|
| * Peer Reviewed journals https://www.springer.com/journal/10601
| adamc wrote:
| How does Oracle licensing play into this? Are these improvements
| likely to show up in less encumbered Java versions?
| carimura wrote:
| Although there are lots of contributors to OpenJDK (which is
| where Java SE is built), Oracle continues to show up and do a
| large part of the work. This work is then used to build many
| distributions, including Oracle's JDK's. So the answer is yes
| these improvements will show up in most distributions.
|
| But anybody who wants to use a JDK built by Oracle can choose
| between the Oracle OpenJDK build [1] with the GPLv2 w/
| classpath exception license, and now have the option to use the
| OracleJDK free of charge in production with a one year overlap
| between LTS's [2].
|
| [1] https://jdk.java.net/ [2]
| https://blogs.oracle.com/java/post/free-java-license
| vlovich123 wrote:
| I'm curious how the Shenandoah GC stacks up here.
| darksaints wrote:
| Optaplanner is very much not the type of workload that would
| benefit from Shenandoah, which is optimized for reduced pause
| times and low latency. Optaplanner's most useful solvers do
| lots of garbage collection, so throughput considerations
| dominate significantly over latency concerns. You'd use G1,
| ZGC, or Shenandoah for web apis or trading platforms, but not
| for a computation heavy solver that is expected to not produce
| useful results for minutes or hours.
| marsdepinski wrote:
| Good clarification as I don't believe many JVM users realize
| that the various GCs have different use cases.
| anonymousiam wrote:
| I still have Java 8 installed. I'm not willing to accept Oracle's
| new Java license.
| BossingAround wrote:
| You shouldn't accept Oracle's new license, migrate to OpenJDK.
| vips7L wrote:
| OpenJdk builds are GPLv2 with class path exception.
|
| Oracle JDK builds are also now free:
|
| https://blogs.oracle.com/java/post/free-java-license
| shrdlu2 wrote:
| >Oracle will provide these free releases and updates starting
| with Oracle JDK 17 and continue for one full year after the
| next LTS release. Prior versions are not affected by this
| change.
|
| So, if that had applied to 11, it would lose updates from
| Oracle in 1 year from now. Whereas something like Corretto is
| currently committed to Java 11 updates until 2027 [0].
|
| They seem to also be planning to increase frequency of LTS to
| every 2 years, so, basically assuming you upgrade to next LTS
| immediately (unlikely in any moderately complex app with
| deps) you have 3 years of free updates.
|
| No thanks.
|
| [0] https://aws.amazon.com/about-aws/whats-
| new/2020/08/amazon-co...
| bullen wrote:
| Thx, this is great news, but why the back and forth, they
| thought anyone would pay for something that has been free for
| 27 years?
|
| Java does not belong to Oracle, it belongs to whom ever codes
| Java. I have still to find a company that understands open-
| source.
| fareesh wrote:
| Is it worth upgrading for any performance improvements for a
| typical Android/Flutter workflow? Any improvements in compile
| times, running the emulator, running Android Studio, etc. ?
|
| How about gradle? I really dislike gradle.
| [deleted]
| titaniumtown wrote:
| woah, super interesting. you should test ZGC as well.
| noisy_boy wrote:
| Considering tons of folks are still on Java 8, I would have liked
| to also see comparison between that and Java 17. Based on the
| improvements shown from Java 11 to 17, one could expect even
| larger improvements from Java 8.
| surfsvammel wrote:
| We are still on Java 8 in many applications and there is no
| real reason for it. Very much looking forward to get our hands
| on some new GC implementations.
|
| We will definitely move to 17 already next year.
| pantalaimon wrote:
| I'm surprised that it's now common for software to require a
| certain (old) Java version.
|
| Wasn't the whole "write once run anywhere" promise about
| backwards compatibility too?
| paulmd wrote:
| Oracle moved away from their "free" license to requiring a
| $100 or $200 per seat license for home users (and I think
| even more for business users), so the clock stopped ticking
| at Java 8u202 for a lot of people who refused to (or
| couldn't) move to OpenJDK.
|
| edit: although this appears to have recently changed!
| https://blogs.oracle.com/java/post/free-java-license
|
| It was really a terrible idea from a security perspective -
| and unfortunately there are organizations that won't consider
| software without a support contract.
| _pmf_ wrote:
| All desktop software I knew around 2009 already used a
| bundled JRE.
| osrec wrote:
| I know it does happen, but I wouldn't say it's common.
| Generally speaking, most of the software I use runs without
| issues on newer JVMs, despite being built for an old one.
| the8472 wrote:
| That generally holds when you stick to public APIs. But there
| are many libraries that used reflection to access unstable
| internals. And that broke with modules.
| native_samples wrote:
| No, it was more than that. Java has broken a ton of
| backwards compatibility in recent years. They stopped
| shipping a lot of stuff (like JavaFX), JavaEE stuff was
| removed from the JDK and then re-namespaced, they changed
| the formatting of the version number, they removed Web
| Start, they moved some stuff out of Unsafe, they changed
| how you access class files inside the JDK and so on.
|
| The idea that the only thing that changed was access to
| internals isn't really the case, but a lot of these changes
| were "allowed" because Java cares about compatibility with
| its own spec rather than specific popular apps.
| josefx wrote:
| > They stopped shipping a lot of stuff (like JavaFX),
|
| I thought they just split up the JDK into modules, making
| some libraries optional for a smaller footprint if you
| decided to ship your program with the JDK included. I am
| quite sure swing was also split of and all my toy
| programs still run despite that.
|
| > JavaEE stuff was removed from the JDK and then re-
| namespaced,
|
| JavaEE was never part of the standard JDK. Never used it,
| but you can probably still find the old java package
| somewhere.
|
| > they moved some stuff out of Unsafe
|
| out of sun.misc.Unsafe, an internal API of the Sun JDK
| that wasn't in the java namespace, wasn't documented and
| had nearly every IDE scream at you.
| brabel wrote:
| > I am quite sure swing was also split of and all my toy
| programs still run despite that.
|
| Swing is still distributed with the JDK, but JavaFX
| isn't. If you use JavaFX, you need to either add Maven
| dependencies on the JavaFX modules or compile with a JDK
| distribution which still includes JavaFX (e.g. jdk-fx
| from Azul: https://www.azul.com/downloads/?package=jdk-
| fx).
| pram wrote:
| Tried running a Java applet recently? ;P
| bydo wrote:
| Oracle itself still sells and supports software that runs
| client-side as Java applets in IE (the "server" that comes
| with it is an old HP desktop).
|
| If you ever peek at the software some industries are
| running, you may find yourself extremely surprised. A lot
| of it is incredibly specific, and truly terrible.
| msgilligan wrote:
| The answer to this question is almost certainly "no".
|
| It is ironic that what was originally the most hyped
| feature of Java has now been removed. But nobody is going
| to miss it.
| lucumo wrote:
| I worked on one this year. You need Java 8 for it and an
| insanely old browser.
|
| They didn't mention the applet part in the job
| description. That was my shortest tenure ever, including
| Summer jobs and internships...
| msgilligan wrote:
| Ugh. Sounds horrible.
| vbezhenar wrote:
| Some applets could be launched with javaws, but it would
| require some tinkering to extract proper jnlp file from
| HTML or JavaScript. I managed to do so with HP iLO remote
| KVM app.
| marwis wrote:
| javaws was also removed =)
| tablespoon wrote:
| >> Tried running a Java applet recently? ;P
|
| > The answer to this question is almost certainly "no".
|
| For me, it's a yes. My employer uses some ancient
| monitoring application called SiteScope. They recently
| "upgraded" from an ancient version to a newer one (I
| think the latest), and nearly the whole frontend appears
| to be implemented as a Java Applet. Since no browser on
| the Mac supports Applets anymore, their workaround was to
| download some Java App that ran the UI.
|
| The older version we had used HTML.
| latchkey wrote:
| I love the concept that the solution is to work around
| the applet issue and not find some new monitoring
| software.
|
| I wonder how effective ancient monitoring software is.
| tablespoon wrote:
| > I love the concept that the solution is to work around
| the applet issue and not find some new monitoring
| software.
|
| The workaround is actually part of the software itself
| (there are instructions right below the login box).
|
| My understanding is they're only upgrading because the
| old version didn't support modern versions of TLS, and
| there's a big push to get off of those. Finding new
| monitoring software would be probably be more work. At a
| minimum, the new version probably supports all the
| features we're using, and at best all our configuration
| can be automatically migrated. I don't know the details:
| I'm not part of the project, I just have an some apps
| with some monitors setup for them.
|
| > I wonder how effective ancient monitoring software is.
|
| It gets the job done.
| NovemberWhiskey wrote:
| At the byte code level, maybe - but any language as large as
| Java is (over the course of 20+ years) going to have changes
| to its libraries, including deprecations / removals.
| msgilligan wrote:
| It's common to require a certain old Java version _or newer_.
| In general Java is extremely backward compatible.
|
| There have been a few minor breaking changes from JDK 8 to
| JDK 17, but the worst ones have had command-line options to
| disable them.
|
| Maybe you're referring to JEE and/or specific "enterprise"
| software which does tend to move much more slowly.
| colechristensen wrote:
| I've run into several performance regressions from 8 -> 11
| -> beyond
|
| Code still _worked_ but services would easily get
| overloaded, there would be one piece of code which ran
| crazy slow, or new memory issues would come up.
|
| It absolutely is not just safe to jump versions in
| production, usually it's been weeks of testing finding and
| fixing perf bugs.
| msgilligan wrote:
| Yes, what you describe is entirely believable. And one of
| the legitimate reasons why enterprise software is slow to
| upgrade.
| pabl0rg wrote:
| Yes. But in the move to java 9 they broke java's customary
| backward compatibility and left behind a lot of users.
|
| It doesn't help that there is no good, clear and complete
| guide on how to upgrade SOAP clients.
|
| I went through this recently and learned that because jakarta
| uses multi-release jars, we have to do the regular dependency
| changes and also change our fat-jar based build/release to
| Docker images. In other words, they decided to throw out
| decades of users' investment in learning the ecosystem.
|
| I'm not surprised that people seem to be leaving the
| ecosystem.
| keymone wrote:
| The way to upgrade SOAP clients is to generously pour the
| office with gasoline and set it on fire.
| mirekrusin wrote:
| It's a SOAP so flush down the toilet should do the trick.
| occz wrote:
| What are your gripes with SOAP? Genuinely interested.
| I've used it once professionally, and while there was an
| initial learning curve, it seemed to have some nice
| properties once you got past that.
| Spivak wrote:
| SOAP is fine if you're talking to yourself or otherwise
| confined to a single dialect. But that's not saying much
| since that's true of any data format. SOAP falls down
| when trying to get systems all developed by n different
| companies all talking to one another which was/is the
| whole point of the stupid thing.
| keymone wrote:
| http://harmful.cat-v.org/software/xml/soap/simple
| dtech wrote:
| Just like with XML, it's suffers from being about 300x
| more complicated than is proper for what is does
| pron wrote:
| > But in the move to java 9 they broke java's customary
| backward compatibility and left behind a lot of users.
|
| The main backward incompatible changes between 8 and 9 were
| the changing of the version string to remove the "1."
| prefix, and the removal of a handful of methods hardly
| anyone had used. In other words, the chances of spec-
| compliant code that ran on 8 failing on 9 were slim. What
| happened was that in the long 8 timeframe, many libraries
| -- for various reasons, some reasonable -- have
| circumvented the Java spec and hacked into JDK internals,
| making themselves tightly coupled to 8. When internal
| classes changed in 9, those non-portable libraries broke,
| and so did their clients. Now that strong encapsulation is
| finally turned on (as of JDK 16), this shouldn't happen
| again.
|
| There were some significant breaking changes to the spec in
| 11, but those comprised separating modules from the JDK
| into external dependencies, and didn't require any code
| change.
| malfist wrote:
| I remember there were a lot of libraries that were part
| of the jdk that got decoupled and no longer included in
| the move from java8 to java9. I specifically remember
| this impacting anyone who parsed xml or json. I vaguely
| remember it being something in the javax.validation
| package.
|
| My company migrated from 8 to 11 but we had a lot of
| headaches around those libraries that were pulled out of
| the jdk.
|
| To be fair, those should not have been coupled to the jdk
| in the first place, but it did break backwards
| compatibility which was a cardinal sin for java.
| chrisseaton wrote:
| Can you give any concrete examples of what broke?
| avereveard wrote:
| A lot of bcel/aspect code had to be rewritten. I've had
| to patch a couple transitive dependencies to bring a 2018
| platform from Java 1.8 into Java 12 land, and it's stuck
| there forever since after 12 something else it depended
| on was removed. We're migrating to a simpler, saner
| runtime, but still, stuff takes time.
| oauea wrote:
| > It doesn't help that there is no good, clear and complete
| guide on how to upgrade SOAP clients.
|
| > I went through this recently and learned that because
| jakarta uses multi-release jars, we have to do the regular
| dependency changes and also change our fat-jar based
| build/release to Docker images. In other words, they
| decided to throw out decades of users' investment in
| learning the ecosystem.
|
| Could you clarify what you ran into? Why docker? I'll have
| to do this soon.
| Alupis wrote:
| Specifically, a ton of used-to-be-included in the
| standard JDK things like nearly all XML processing are
| now broken out into modules or require maven
| dependencies, etc.
|
| So it's not "turn-key" to upgrade to jdk 9 or above, like
| say, 6 -> 7 -> 8 was.
|
| Sounds simple... "just add it to your maven deps!" - but
| in practice it's more complicated than that and requires
| careful planning and testing. Some things might even
| surprise you and run for a while before a classloader
| can't find something and explodes in runtime.
|
| Java 9 created quite a mess. Once you finish that upgrade
| though, moving into Java 11 or anything newer is
| basically turn-key like it was before. But, this had the
| effect of many companies staying with Java 8 until forced
| to upgrade.
| _hilro wrote:
| from OP > Could you clarify what you ran into? Why
| docker?
|
| Not sure I follow why you had to turn to docker
|
| > Some things might even surprise you and run for a while
| before a classloader can't find something and explodes in
| runtime.
|
| The JVM is deterministic - I don't follow this statement?
| Alupis wrote:
| > Not sure I follow why you had to turn to docker
|
| I didn't, and OP could have stuck with Java8 since it's
| LTS. So I'm not sure either where Docker comes into play.
| It seems the parent was deploying fat jars, and now due
| to the complications of all the various deps, they opted
| to use Docker images as a new "fat jar". Perhaps it
| simplified their build process, but that's just a guess.
|
| > The JVM is deterministic - I don't follow this
| statement?
|
| Custom classloading simply requires a string path and FQN
| of the class to attempt to load it from disk. Compile
| time checking doesn't validate the actual existence of
| the class, which is the point of runtime custom class
| loaders.
|
| A lot of plugin loaders are done this way, etc. So...
| your program might be humming along just fine until it
| classloads in a plugin (or whatever) that depends on Jaxb
| for example, then everything explodes since Jaxb is now a
| dep instead of built into the jdk.
| _hilro wrote:
| Sure but that's always been the case.
|
| Anyways, I had read your comment as: ~"Classloader loads
| class X fine one moment and then suddenly can't" which is
| why I mentioned deterministic.
| Alupis wrote:
| > Sure but that's always been the case.
|
| Well, no it hasn't. Things like Jaxb, for example, have
| always existed in the JDK since they were introduced
| (java 1.2 in Jaxb's case). XML processing code compiled
| with jdk5 (circa 2004) still worked fine on java8, for
| example, with zero code or dep changes. Suddenly that
| assumption is broken with java9.
|
| > Anyways, I had read your comment as...
|
| It was just an admittedly contrived scenario where the
| upgrade path to jdk9+ wasn't as straight forward as just
| adding deps to maven and calling it a day, since you may
| not be aware of all code interactions, depending on the
| system you're upgrading.
|
| Your program might even have a dep on some jar that was
| compiled under jdk4 and the author and source are nowhere
| to be found (or went out of business a decade ago)... and
| suddenly it breaks under java9. Things like that are
| largely what prevented mass adoption of jdk9 immediately.
| AtlasBarfed wrote:
| Simple Object Access Protocol...
|
| Simple: by the end I was dealing with self-signed bodies
| and validation, version hell, framework hell, and
| namespace super-hell.
|
| Object: um, not really. It was request/response. Nothing
| really "OOP" about it at all.
|
| Access: didn't really help much with access, that was all
| HTTP
|
| Protocol: There were so many protocols and frameworks
| attached to those protocols and versions of the protocols
| that ... in the end of the day, it had no protocol.
| native_samples wrote:
| Hmm, fat jars still work OK in latest Javas. What is the
| issue is with Jakarta multi-release JARs? A MR JAR is just
| a regular JAR with files in different directories. They
| should fat-jar together OK.
|
| There's certainly no requirement to start using Docker
| images!
| mumblemumble wrote:
| The problem I've run into with mrjars is that they tend
| to break libraries that do a bunch of classpath scanning.
| Mrjars add some stuff to the classpath that the older
| tools didn't understand and would choke on.
|
| It's one of those things I would personally argue is a
| naughty hack that should be avoided if at all possible,
| but it's also something that's historically been
| ubiquitous within the Java ecosystem. It's frequently how
| convention-over-configuration dependency injection (as
| found in Spring Boot or Jersey) tends to be done, for
| example.
| DarkmSparks wrote:
| Im more skeptical. one of the reasons we're still on jre8 is
| any of the newer jres I tested throw crash panics on several
| tasks and the ones that dont take 40 or 50 hours to finish
| instead of instead of 4 or 5. (mostly changes in the garbage
| collection as far as i could tell, several command line options
| we rely on for performance were depreciated with no way to turn
| them back on)
|
| That left me with the impression that stability and performance
| had been abandoned over throwing everything including the
| kitchen sink at it to try and attract people who like rust and
| go.
|
| Could be wrong, but the hand waving away the implication that
| 17 is slower than 15 at the end and not even trying to compare
| with 8 which is rock solid and crazy performant leaves me
| thinking nothing actually changed.
| [deleted]
| vips7L wrote:
| Here is a blog that compares garbage collection across
| several versions and GC's: https://jet-
| start.sh/blog/2020/06/09/jdk-gc-benchmarks-part1
|
| They concluded:
|
| "JDK 8 is an antiquated runtime. The default Parallel
| collector enters huge Full GC pauses and the G1, although
| having less frequent Full GCs, is stuck in an old version
| that uses just one thread to perform it, resulting in even
| longer pauses. Even on a moderate heap of 12 GB, the pauses
| were exceeding 20 seconds for Parallel and a full minute for
| G1. The ConcurrentMarkSweep collector is strictly worse than
| G1 in all scenarios, and its failure mode are multi-minute
| Full GC pauses."
| DarkmSparks wrote:
| I forget, bit iirc it uses one by default, but you can
| specify the number of threads to use with
| XX:ParallelGCThreads=<N> which is what got depreciated
| later.
|
| its target is throughput rather than response so yep
| "pauses", but the entire job takes 4 hours instead of 40.
| In production those pauses vanish with load balancing.
|
| checking for jdk8 vs jdk17 turns up
|
| https://www.google.com/amp/s/www.infoworld.com/article/3606
| 8...
|
| "New Relic found that nearly 100 percent of users are
| running either JDK 11 or JDK 8, the two most recent LTS
| releases."
|
| so 17 being 8% faster than 11 apart from when its 10%
| slower, "maybe" slower or faster than 15 but they chose not
| to do a like for like comparison.... but 11 being
| catastrophically lower throughput than 8....
|
| I may get some time soon to do some benching, I dont want
| to be back on 8, but the benching I did for at least 10 and
| 11 just made them a no go, completely crashing the jvm was
| an even bigger issue than the time.
| hilbertseries wrote:
| Are you sure ParallelGCThreads was deprecated? The cms GC
| algorithm was deprecated but that doesn't use that
| setting, which is used by the ParallelGC algorithm. The
| default was changed to the g1gc algorithm. But if you
| were manually specifying parallelgc that shouldn't have
| been impacted.
| DarkmSparks wrote:
| >Are you sure ParallelGCThreads was deprecated?
|
| Definitely not sure it was that op exactly, reasonably
| sure it was something related to it (maybe it no longer
| working with a gc it used to).
|
| TLDR:I found out "the hard way" -XX means "jvm specific,
| can change meaning at any time and is jvm vendor
| specific".
|
| oracle java 8 had a sweet spot that made perf awesome,
| nothing since has come close.
| hyperpape wrote:
| The magnitude of the change should tell you that you're
| hitting a weird edge case. Obviously new versions of the jre
| are not going to be 10x slower in general.
| pron wrote:
| The current JDKs are at least as stable and, for most
| workloads, significantly more performant and less RAM-hungry
| than 8. JDK 8 is medieval technology compared to the modern
| JDK. The savings in hardware alone pay for the cost of
| migration within less than a year.
| DarkmSparks wrote:
| Yes i did see the "less ram hungry"
|
| thought that may actually be part of the issue - not
| keeping things that benefited from that persistence around
| long enough. Traded throughput away for smaller lookup
| tables.
|
| As for "medieval technology" in what way? If the jvm cant
| run a day without creating a hcrash report and you need 10
| times as many cpus to complete a job in the same time, how
| is that a step forward?
| pron wrote:
| > Traded throughput away for smaller lookup tables.
|
| Much of the improvement came from a re-encoding of String
| (no longer internally encoded as UTF-16), and more
| sophisticated GC algorithms.
|
| > If the jvm cant run a day without creating a hcrash
| report and you need 10 times as many cpus to complete a
| job in the same time, how is that a step forward?
|
| If you see crashes, submit a bug report, but we've not
| been seeing any increase in crash reports. It's possible
| that you're using a library that hacks into JDK internals
| and is a cause of such problems. Try using JDK 16 or 17,
| where strong encapsulation is turned on (at least by
| default).
| DarkmSparks wrote:
| Those crashes were just on our unit tests, creating
| linking and destroying large volumes of objects, throwing
| them in a thread for some basic compute then writing
| results to disk. I agree its really about the gc, but the
| new ones just never seemed to beat the setup we have on
| 8, and there is only so much time that can be devoted to
| making things that work, work on "new shiney".
|
| java after 8 is just mayhem, before it was easy, oracle
| for some things, ibm for others.
|
| now there are new long term releases faster than we can
| test them, they fail at least one of the unit tests that
| all pass on 8, and openjdk is missing half the really
| nice stuff that was once free.
|
| >submit a bug report but to who and under what title?
| Oracle, IBM, openjdk?
|
| e.g. "none of the corba stuff works anymore because its
| not part of 'new java'" is whose fault?
| sandGorgon wrote:
| this is super interesting. Honestly, I do think that your
| testcase is worth replicating.
|
| I dont think anyone is advocating you tradeoff stability
| for shiny features, but i think everyone is existing in a
| state of disbelief that Java 17 would break on your
| usecase.
|
| But if what you're saying is true... it super duper worth
| it for everyone to submit that test suite. Java 17 is
| also LTS ...so that effort would be worth it in the long
| term.
| crummy wrote:
| > now there are new long term releases faster than we can
| test them
|
| Aren't they every 2-3 years?
| quantified wrote:
| They're pretty well spaced out.
| DarkmSparks wrote:
| used to be.
|
| java 6 (previously widely deployed jvm) was 2006 java 8
| (current widely deployed jvm) was 2014 now, 7 years
| later, we are on java 17 and the most significant thing
| to change is to break most everything that worked in
| 2014, and promotional material dare not mention java 8...
|
| In fact "widely deployed" doesnt cut it for java 6,
| pretty much every pc, windows linux and mac had a solid
| java 6 deployment.
|
| java 17 has a lot to live up to.
| DarkmSparks wrote:
| now yes. fixing what isnt broken isnt high on the list of
| things to do.
| rualca wrote:
| > fixing what isnt broken isnt high on the list of things
| to do.
|
| It's hardly reasonable to try to pin the blame of not
| wanting to maintain software as a stability issue with a
| newer LTS release of the JDK. It's perfectly fine if you
| make the call to stick with JDK8 forever, but that's a
| personal call.
| quantified wrote:
| Java 8 is medieval. Java 17 is at least Enlightenment-era.
|
| At a prior employer, we ran a heavy-duty compute engine and
| a bunch of other services on Java _13_ (don't ask) without
| any issues. Stupid JDK tricks in dependencies were the hard
| part of migrating 8 to 13.
| StreamBright wrote:
| Does this include the cost of migration? In my experience
| it is not as easy to move companies from LTS JDK to newer
| ones. There are external dependencies sometimes too.
| ashtonkem wrote:
| Must be something unique in your workload. For my team, later
| versions of Java have been stable and a bit faster than older
| versions.
| krzyk wrote:
| jdk 8 is not rock solid nor performant.
|
| You should look at your codebase, you might be doing some
| strange things that changed in newer JDKs (e. g. String split
| no longer uses the sour String, but I don't remember when
| they changed that). Some options were deprecated because they
| are also always on (not all probably).
| DarkmSparks wrote:
| 3 years uninterupted uptime and counting.
|
| what in 17 do you think is worth risking downtime?
| fridif wrote:
| Nothing for you, but something for us.
| sigzero wrote:
| Why would there be downtime? It's faster. Less RAM
| hungry. Tons of new great features.
|
| I mean, if you don't want or feel the need to upgrade
| then don't. There are plenty of reasons to do so IMO.
| DarkmSparks wrote:
| Because the core system dates back to jre... 1.4, has had
| ~2 decades of painful testing and big chunks of code dont
| currently work on anything newer than 8.
|
| a bug that takes 100 hours to manifest takes multiples of
| that to fix.
|
| compute and ram is crazy cheap these days, developers are
| not, and finding good ones is harder than ever.
| stuff4ben wrote:
| Yeah I'm gonna say you're an edge case and that the
| majority of users will see performance benefits. Maybe
| not you, but that's legacy code for ya and an awful lot
| of technical debt that's likely not worth it.
| DarkmSparks wrote:
| every java dev was an edge case, from small houses
| building blockbusters like triage through to the likes of
| gazprom and google building their entire backend on it
| with tens of thousands of devs.
|
| since you threw them out, which "majority of users" are
| you thinking of?
| rualca wrote:
| > 3 years uninterupted uptime and counting.
|
| Didn't you had to install updates and patches during the
| past three years? Or were those sacrificed to keep an
| uptime streak that matters nothing?
| Spivak wrote:
| People still take outages for patching? I think the
| parent means service uptime.
| rualca wrote:
| Taking a node down does not mean outage at all. Service
| uptime also reads like a non-sequitur given the comment
| on the JDK11 crashes sounded like OP was doing something
| weird with the new JDKs, not with the old prod system
| running JDK8.
|
| JDK11 was released way back in 2018. Any claim that it's
| unstable these days is not credible.
| DarkmSparks wrote:
| Sure, but no other updates or patches require massive
| rewrites to work as well as it does now, and they can be
| applied one machine at a time.
|
| e.g. a non insignificant portion relies on corba/rmi. it
| works, and works fine.
|
| switching, e.g.
| https://stackoverflow.com/questions/51710274/is-there-a-
| repl...
|
| might break in unexpected ways, bringing down everything
| that needs it.
|
| I see 17 is potentially ripping out security manager,
| why? wth?
|
| So suddenly jars that expect to throw an exception if 3pd
| code wants to do something they arent allowed to will now
| just run fine?
|
| Really really very sad face.
| derefr wrote:
| > I see 17 is potentially ripping out security manager,
| why? wth?
|
| Because Security Manager -- which enforces _runtime_
| access capabilities, like an OS kernel does -- exists for
| the sake of Java applets, and Java applets have been dead
| for a long time. The Security Manager enables secure
| execution of "mobile" (i.e. untrusted, not-auditable-at-
| time-of-release) code -- cases where the "host" and
| "guest" codebases are compiled separately with the "host"
| having no ability to introspect the "guest" during the
| "host's" compilation, because the "guest" doesn't exist
| yet.
|
| Security Manager does _not_ exist for the sake of
| fighting against your own project 's dependencies. There
| are much simpler and more runtime-efficient solutions
| (like linters / static-analysis tools) for the case where
| the "host" can see the "guest's" code at compile time.
|
| Security Manager doesn't exist for the sake of "plugins"
| (e.g. WARs, Java Agents, etc), either. Even if you don't
| have a plugin's source code available in your project
| worktree at build time, you can still validate the
| plugin's behavior at _release_ time by statically
| analyzing its bytecode before building it into your
| release fatJar. Which still allows you to make _much_
| stronger guarantees than Security Manager can.
| DarkmSparks wrote:
| no, not just applets. its used for any kind of secure
| system where developers and their components are
| forbidden from say network access, e.g. some nashorn map
| reduce javascript. java _used_ to be the language of
| choice for building complex systems with large
| multinational multidisciplinary teams. security manager
| was a vital part to those projects, removing security
| manager means none of that can migrate.
|
| why do it?
| spullara wrote:
| Anyone still on Java 8 can just stay there. If they cared about
| whatever it is they would have upgraded years ago.
| derkoe wrote:
| Our Spring Boot showcase application
| https://github.com/porscheinformatik/angular-spring-heroes starts
| ~ 10% faster on Java 17 compared to Java 11 (compiled with target
| 11).
| vips7L wrote:
| I hope spring moves to compile time di like quarkus and ajave
| inject instead of scanning the classpath at runtime.
| dlbucci wrote:
| Isn't that what Micronaut does, from the creators of Spring?
| I never used the latter, but I really like working with the
| former.
| derkoe wrote:
| Yes, Micronaut and Quarkus do that. Micronaut was created
| by a company (https://objectcomputing.com/)
| _old_dude_ wrote:
| You mean Spring native [1], i think it's not ready yet.
|
| [1] https://docs.spring.io/spring-
| native/docs/current/reference/...
| vips7L wrote:
| No I do not. I do not want native image. I want the
| dependency injection container created at compile time like
| Dagger2 [0] or Avaje Inject [1] or quarkus without native
| image.
|
| [0] https://dagger.dev [1] https://avaje.io/inject/
| _old_dude_ wrote:
| You can use the Spring AOT plugin [1] without enabling
| the support of GraalVM native image
|
| [1] https://docs.spring.io/spring-
| native/docs/current/reference/...
| vips7L wrote:
| Ohhh I see. Thank you!
| facorreia wrote:
| Do you happen to have a comparison from Java 8 to 11?
| derkoe wrote:
| Just tried it - there is no significant difference between
| Java 8 and 11! They both start around 6.5s (JVM running for
| 7.4s). Java 17 starts the app in approximately 5.9s (JVM
| running for 6.7s).
| derkoe wrote:
| Even more interesting is the memory usage (app started and
| opened index page in browser): - Java 8/11 uses
| ~ 550MiB - Java 17 uses ~ 260MiB
|
| (all run with Docker and a memory limit of 1GiB)
| CyanLite4 wrote:
| Still in the bottom half of most benchmarks. Still magnitudes
| slower than its market competitor (.NET)
| bambam24 wrote:
| In silicon valley Java Is abandoned, and seen as a legacy
| programming language like php
| flerchin wrote:
| I would like to see some workloads, not just GC times.
| Someone wrote:
| FTA: _"Each run solves 11 planning problems with OptaPlanner,
| such as employee rostering, school timetabling and cloud
| optimization."_
|
| How is that "just GC times"?
| netr0ute wrote:
| One common workload is Minecraft, which just happens to be
| completely incompatible if you have any mods to improve
| performance already.
| bladelessninja2 wrote:
| Yeah, I would like to see them to, especially when I see
| something like this:
|
| > When we benchmarked JDK 15, we saw that Java 15 was 11.24%
| faster than Java 11. Now, the gain of Java 17 over Java 11 is
| less. Does that mean that Java 17 is slower than Java 15?
|
| > Well, no. Java 17 is faster than Java 15 too. Those previous
| benchmarks were run on a different codebase (OptaPlanner 7.44
| instead of 8.10). Don't compare apples and oranges.
|
| Author is defending their other article by discrediting their
| own methods - what those percent values even mean if they
| differ so much between different versions of the same
| benchmark? Shouldn't benchmarks be profiled for specific
| workload types to simulate real life examples? How could you
| possibly change the workload so much it affects result so
| significantly and not change the nature of your benchmark?
| igouy wrote:
| Apparently it depends which GC is used, so:
|
| > "0.37% faster than Java 16 for ParallelGC"
|
| > "2.41% faster than Java 16 for G1GC (default)"
|
| But as you asked, toy benchmark programs!
|
| https://news.ycombinator.com/item?id=28530126
| jakozaur wrote:
| It looks like majority of this gains are related to memory
| management and garbage collector or am I missing something?
|
| JDK 8 -> JDK 11 gains were huge thanks to String optimisations
| (e.g. GC could dedup strings and store one char as byte in many
| cases).
| mumblemumble wrote:
| I'm not super surprised? That seems to be where most
| improvement happens across a variety of languages nowadays.
|
| I recently listened to an interview with someone working on
| Intel's C++, and he indicated that, contrary to popular
| assumption, most of the speed boost you can get with it isn't
| from better instruction-level micro-optimization, it's from
| analyzing information flows and maximizing locality of
| reference.
|
| Perhaps this is an inevitable result of that ever growing
| processor-memory performance gap. Nowadays, the cost of having
| to take a walk of shame out to the RAM chips is so great
| compared to everything else that I would assume that minimizing
| the number of times you have to do that is by far the lowest-
| hanging fruit.
| pulse7 wrote:
| Java's value objects (inline classes) will "maximize locality
| of reference". [1]
|
| [1] https://openjdk.java.net/jeps/169
| kllrnohj wrote:
| That draft is approaching 10 years old now. Has there been
| any indication of progress on this front in the recent JDK
| versions?
|
| The kotlin workaround hacks are clever but also nasty and
| having real VM support for this would be great. But it also
| is starting to seem like the type of issue that just won't
| ever be fixed, despite how hugely important it is for
| performance.
| pulse7 wrote:
| It takes time to make such a fundamental, but backwards
| compatible change for 10 million developers... Nobody
| wants Python 2 -> 3...
| kllrnohj wrote:
| It's a new keyword & bytecode feature, so there's no
| backwards compatible risks to it. Nobody's existing code
| would be impacted as nobody's existing code is using
| user-defined value types in the byte code.
|
| It looks like there were some experiments and prototyping
| out of Valhalla from 2014-2018 (including a publicly
| available build: https://jaxenter.com/java-value-
| type-163446.html ), but there doesn't seem to be any
| updates since then
| lsuresh wrote:
| It's being actively worked on [1, 2].
|
| [1] https://github.com/openjdk/valhalla/ [2]
| https://mail.openjdk.java.net/pipermail/valhalla-dev/
| Sindisil wrote:
| > there doesn't seem to be any updates since then
|
| Oracle (Brian Goetz in particular) regularly gives talks
| and interviews and publishes updates.
|
| There was even a link on this site a couple weeks ago:
| https://news.ycombinator.com/item?id=28364500
| hn_go_brrrrr wrote:
| Or at least partially mitigate one of Java's biggest
| performance weaknesses.
| RNCTX wrote:
| My knee-jerk reply when click on the topic was "depends on how
| much memory it demands."
|
| Good to find that the assumption was correct, lol.
| lmilcin wrote:
| Anything more than couple percent just due to improved memory
| management is phenomenal improvement.
| vbezhenar wrote:
| I think that one of the improvements is the ability to release
| memory to OS from VM when it's not needed. Might help with
| microservices.
___________________________________________________________________
(page generated 2021-09-15 23:00 UTC)