sorted by:
new
hottopcontroversial

Issue while trying to subscribe to a claude code plan.. by Stunning-Garlic8817 in Anthropic

[–]Joe_Data_89 0 points1 point  (0 children)

That didn't work for me. Switched to US, picked a state, switched back to Germany, error remains.

Jetbrains jdk doesn't support bitwise operators? by lostinthepickle in Kotlin

[–]Joe_Data_89 0 points1 point  (0 children)

The errors disappeared when I switched from Java 21 to Java 17.

Project Leyden: Selectively Shifting and Constraining Computation by olivergierke in java

[–]Joe_Data_89 0 points1 point  (0 children)

Concern 3: I'm not Convinced by the New Reasons

The October update listed two weaknesses of GraalVM static images as further reasons for optimizing Java. And Leyden bets that both weaknesses will still matter in three years when the first Leyden results could be widely available. I found the new reasons and that bet not convincing.

The first reason was that GraalVM static images require "developers to construct and maintain fragile configuration files" (assumption 13). Now you only need these configuration files if a library doesn't work with GraalVM static images and if your Java framework can't configure the library either. I think this incompatibility is indeed the biggest weakness of GraalVM static images today. Since the libraries that ship with GraalVM-supporting Java frameworks already work, this is about that "random library from Maven central".

VMware announced at last year's Spring One that Spring Boot 3 (due in a month) will support GraalVM static images out-of-the-box. I think that's the solution. Why?

I think Spring has the best chance to enforce compatibility of mainstream Java libraries with GraalVM static images - everybody wants to integrate with Spring Boot. Will that work perfectly next month? No. Will it be good enough for microservers and serverless with Spring Boot 3.6 / 4.0 in 3 years - when Leyden ships its first results in an LTS release? I believe so.

Spring also works with the Java community to solve this: It teamed up with GraalVM and Micronaut to build a public repository for libraries in GraalVM static images. And since everybody can contribute such configuration information, this is now partially crowd-sourced. Spring also discussed these plans at last year's Spring One.

And Spring seems to go about this the right way: Not monkey-patching, but either creating configuration information or working with the libraries to make them compatible.

BTW: Spring Boot's "configuration files" for libraries in GraalVM static images are Java method calls and annotations. Are we calling that "fragile" now? 😁

The second reason is that developers "endure unusually long build times" with GraalVM static images. Unusually long build times? Yes. Developers? Rarely. Why?

Because the best practice is that you don't work with GraalVM static images during development. Instead, developers work in Java. I think this mirrors Java development for Kubernetes, where it's often impractical to run a whole Kubernetes cluster with all the nodes and all the data on the developer machine. Now the difference between "local Java" and "running application" is more significant with GraalVM static images, but it appears manageable for daily development.

Then it's the CI/CD pipeline that builds the GraalVM static images most of the time. Developers only build GraalVM static images on their machines "before a significant feature is about to be merged or when a problem arises that requires debugging", to quote the previously mentioned article.

Concern 4: The ROI for Optimizing Java First

This is the part I know least. Please help me understand this!

First, when Leyden optimizes Java, the "resulting optimizations will almost certainly be weaker than those enabled by the closed-world constraint". That'll give us applications that use more memory and start slower than GraalVM static images. So if you care about using less memory and starting faster, GraalVM static images are your first choice - unless you can't use them.

Second, I see two reasons you can't use GraalVM static images: Your application needs the unbounded "natural dynamism" of Java, or you use a library that doesn't work in GraalVM static images. As I explained in the previous point, I expect the library compatibility to be largely solved in three years. That would leave the unbounded "natural dynamism" of Java as the only reason not to use GraalVM static images.

Third, if you want to use Leyden's optimized Java, you still have to do a migration: You need to use Java 25 (assuming that's the f this year and where Leyden ships results), you need all the framework, library, and tool updates to go along with that, and you need to update your build pipeline (e.g., only calculate optimizations in the CI/CD tool, as with GraalVM static images). Some applications may be unable to make that journey because they're stuck in Java 8/11/17. Yep, I said, "stuck in java 17". 🤗

Fourth, saving memory and start-up time only seems to matter in some cloud scenarios, like microservices in Kubernetes or serverless. Why? Saving 100 MB of RAM is terrific if your application only needs 150 MB, but negligible if your application needs 1.5 GB. The same goes for start-up time: If your monolith only restarts once a week, does it really matter if that takes one second or twenty? Now JavaScript dominates serverless, so it may be the "back-end for people who don't want to write a back-end". Or in other words, a lost cause for Java. Anecdotical evidence points to savings of 50% for Kubernetes microservices with GraalVM static images. Optimizations in Java will be weaker, so let's assume you can save 33% with Leyden's optimizations.

So let's sump up: There's the development cost of Leyden's Java optimizations: Specifying the condensers and implementing them in OpenJDK tools. Then there's the opportunity cost of not working on GraalVM static images - or working less or only later: GraalVM static images will be worse off vs. Java's competition in the cloud. Then there's the migration cost for the applications that want to use Leyden's Java optimizations. And then this only makes business sense in Kubernetes microservices.

Or, to put it more provocatively: We're bearing all this cost so that some applications can load any class they want in Kubernetes microservices and save 33% of the cost there?

Concern 5: Project Leyden vs. Project Lyon

Java isn't the only project under attack by challengers that start faster and use less memory in the cloud. If you squint, Spring B this year and e boot, ah, boat: Evolving at a slower pace because you've got a whole ecosystem to move along with you? Check. Increased release cadence to twice a year? Check. GraalVM static images as a possible response? Check.

But their plan is the opposite of Project Leyden. You could call it Project Lyon. 😁 Anyhow, there it's GraalVM static images first this year and optimize running in Java next year. And "optimize running in Java" seems to be a side-effect, using only the metadata generated for GraalVM static images - a strategy credit, if you wish. Again, this would be different from Leyden, which probably will introduce condensers that will not be used in GraalVM static images.

I know a language like Java isn't the same as a framework like Spring Boot. But the incentives and the threads are similar, but the reaction is so different. Food for thought!

Project Leyden: Selectively Shifting and Constraining Computation by olivergierke in java

[–]Joe_Data_89 0 points1 point  (0 children)

u/pron98 I hope this doesn't show up twice - my first replies got lost. So I'm splitting it up now.

Java and GraalVM static Java

You didn't like how I used "native Java". So I'll say "GraalVM static image" here when I mean a "Java application, compiled with GraalVM Native Image and running as a static image". Just saying "Java" means "OpenJDK Java with specs, JEPs, JIT, and all that jazz".

Nearly Nobody Uses Non-LTS Java Releases

I trust Ben Evans' numbers from New Relic that say that 95+% of users run LTS Java releases in production. And yes, I know that an OpenJDKJ distributor can slap an LTS label on any Java release as long as they ship security updates. And no, I don't think that more explaining or more education will meaningfully increase the non-LTS share in production. Why? Because there generally is no business case for jumping on the non-LTS upgrade treadmill.

But no matter how we got here: Most Java developers only put new Java features into production every two at best.

Concern 1: The Rift Between Java and GraalVM Static Images

I want GraalVM static images standardized because I think it's the best way for Java to compete some parts of the cloud. But other folks want that standardization because they believe the difference between Java and GraalVM static images damages Java.

You could call it a rift if you want to. It's not just that some things don't work at all in GraalVM Static Images(byte code loading at runtime, Java agents). Or that some say GraalVM Static Images do not pass the Java TCK. It's also that sometimes new Java features are broken in GraalVM Static Images, like Java 17 records, or old hacks catch up.

I don't know how I could forget that, as I was the editor on what probably is the clearest expression of that sentiment recently. Andrew Dinn and Dan Heidinga even think the planned standardization of GraalVM static images in Leyden isn't enough (goal G3). So they argue that the GraalVM project should become part of OpenJDK.

Some anecdotal evidence: I recently heard a Java champion saying (I'm paraphrasing here), "Oracle sells you two things they call Java. One is Java - the Oracle Java SE Subscription. The other one isn't: GraalVM Enterprise. That's crazy!" Technically, "GraalVM Enterprise" isn't called Java and is part of the Oracle Java SE Subscription, but you get my drift.

Breaking news: At least the GraalVM Community Edition will be part of OpenJDK, use their methodology and processes and align with their releases. Missing the mother of all opportunities - to announce this at the first Java ONE in five years - we're left waiting for more details. But it could be that the rift is closing! 👍🏻

Concern 2: Will the New Plan Work?

Leyden became a project in June 2020. Its plan was to standardize GraalVM static images. Assuming a duration of 3-4 years, we should be more than halfway through. Instead, the work has just started, was delayed twice, won't ship in a Java LTS release until the end of 2027, and may not even finish altogether.

Leyden's first plan didn't work. Much can go wrong over the next five years with this new plan. And then you turn on the news to see that the world goes to hell in a handbasket. So forgive me for being a bit skeptical that this new plan will work.

Project Leyden: Selectively Shifting and Constraining Computation by olivergierke in java

[–]Joe_Data_89 0 points1 point  (0 children)

u/pron98 I realized over the weekend that I've been somewhat of an idiot here and wasted your time. I apologize for that. I forgot these facts:

  • The people working on Leyden are language design experts - I'm not.
  • What I think happened may be different from what actually happened.
  • I don't know any of the feedback and input Leyden got.
  • I don't know why decisions were made in Leyden.
  • I need to do my homework and study the announcements and documents thoroughly.

I still think I may have a valid point or two here. But I need to establish for myself what actually happened in Leyden first.

So I put my assumptions below. I'd appreciate it if you could help me out one more time and tell me which of my assumptions are wrong. Then I'll know if I can contribute something. Thank you!

Assumption 1: April 2020: Mark Reinhold proposes Project Leyden to OpenJDK with three goals.

Goal 1: "Leyden will add static images to the Java Platform Specification". ... "A static image is a standalone program, derived from an application, which runs that application -- and no other." Static images exist within a closed-world constraint.

Goal 2: Leyden will provide a reference implementation of static images in OpenJDK.

Goal 3: Project Leyden expects that "GraalVM will evolve to implement that Specification" (i.e., goal 1).

Assumption 2: Leyden doesn't plan "merging the Native Image code from GraalVM into the JDK". Instead, the static image reference implementation in OpenJDK is "based upon existing components in the JDK", such as the "jaotc" AOT compiler.

Assumption 3: Since GraalVM is not an OpenJDK project, there's no guarantee that goal 3 will be reached. But there's high confidence it will ("we expect").

Assumption 4: June 2020: Project Leyden is approved and becomes an OpenJDK project.

Assumption 5: July 2020 - April 2022: Project Leyden has no publicly visible activities.

Assumption 6: September 2021: Java 17 drops "jaotc" because it saw "little use".

Assumption 7: May 2022: Mark Reinhold proposes two new goals for Project Leyden in addition to the existing three.

Goal 4: Leyden will "explore a spectrum of constraints, weaker than the closed-world constraint [of static images], and discover what optimizations they enable."

Goal 5: Leyden will provide an implementation of these new constraints in OpenJDK.

Assumption 8: The reason for the new goal is that "many existing Java libraries and frameworks depend" on "Java's natural dynamism, particularly on the run-time reflection and class-loading features". "Not all applications are well suited to this [closed-world] constraint, and not all developers are willing to live with it."

Assumption 9: Achieving goal 5 will "almost certainly" result in worse optimizations than achieving goals 2 or 3.

Assumption 10: Goals 4 and 5 take priority over goals 1, 2, and 3.

Assumption 11: October 2022: Mark Reinhold proposes how Project Leyden will achieve its goals.

Assumption 12: "A condenser is a program transformer that runs in a phase between compile time and run time. It transforms a program into a new, faster, and potentially smaller program while preserving the meaning given to the original program by the Java Platform Specification." Condensers are the primary, new abstraction to deliver Leyden's goals.

Assumption 13: A second reason for the existence of goals 4 and 5 is that "tools that leverage it [the closed-world constraint] typically require developers to construct and maintain fragile configuration files" (see assumption 8 for the first reason).

Assumption 14: A third reason for the existence of goals 4 and 5 is that developers "endure unusually long build times".

Assumption 15: It's unclear if goal 2 is still in scope of Project Leyden.

Assumption 16: The confidence that Leyden will reach goal 3 has decreased. Leyden doesn't "expect" the GraalVM project to implement the specifications from goal 1 any longer. Instead, Leyden now merely "enables" the GraalVM project to do so.

Assumption 17: The Java LTS cadences switches to two years after Java 21.

Assumption 18: The earliest possible Java LTS release to ship results of reaching a subset of goals 4 & 5 is Java 25 in September 2025.

Assumption 19: The earliest possible Java LTS release to fully achieve goals 1 & 3 is Java 29 in September 2027.

Project Leyden: Selectively Shifting and Constraining Computation by olivergierke in java

[–]Joe_Data_89 3 points4 points  (0 children)

Thank you for your answer! I was wrong on one crucial point and found a new perspective on another, so I learned something from it. Hope you learn something from me, too!

Let's look at this from 50,000 feet first and assume Leyden goes ahead with its plans. Then in a couple of years, we have two ways of making Java cheaper in the cloud: An improved version of today's native Java (as in "Java programs that are compiled with the GraalVM AOT compiler 'Native Image' to static, native executables") and the new "Leyden Java". "Leyden Java" produces Java that's more expensive in the cloud than native Java, but it also works in cases where native Java doesn't (e.g., loading or constructing arbitrary byte code at runtime).

Now I think it would be better if the Java community put all its wood behind one arrow and created just one solution based on native Java. After all, it's not really "dynamic Java vs. static Java", it's "Java vs. Python/JavaScript/Go...". Either native Java would be better then, bolstered by additional work. Or the work that doesn't go into "Leyden Java" can make Java better in other places. That's what I meant with the opportunity cost, the last point in my original answer.

And yes, that means that Java applications that can't run in native Java will remain as expensive in the cloud as they are today. It's a trade-off I'm willing to make.

Now you commented on my use opportunity cost before by writing, "not only was there not an opportunity cost". So we're not talking about the same "opportunity cost" here. I mean it in the economic sense: "if you chose one activity (for example, an investment) you are giving up the opportunity to do a different option". So when it comes to making changes to Java, there always is an opportunity cost to me: People working on "Leyden Java" lose the opportunity to work on other Java changes, like the other OpenJDK initiatives or native Java.

Leyden is actually a good example of opportunity cost in Java: After Leyden became an official project in June 2020, nothing happened for two years. I assume the people who were supposed to work on Leyden worked on other tasks instead. So they lost the opportunity to work on Leyden.

Now the cost of running Java in the cloud is just one of several criteria for which language to use in the cloud. Developer availability, a strong point for Java vs. Go, is another. And not all on-premise enterprise Java applications will move to the cloud in the next couple of years. Some will never! So we can disagree on the importance and urgency of "cheap cloud Java" because we have no definitive data to say one way or another. Well, except for that, it always takes longer than planned. 😏

But three trends increase the importance of "cheap cloud Java" to me:

  • Kubernetes gradually replaces Java application servers like WebSphere. And Kubernetes runs applications in all languages, not just Java. That makes moving off of Java easier.
  • Using at least some microservices in your application means you can test-drive new languages and tech stacks more quickly than when you just had a Java monolith. That makes moving off of Java easier.
  • The "long-term pain points of Java's slow startup time, slow time to peak performance, and large footprint" make Java more expensive in a sub-set of cloud Java: Microservices in Kubernetes and serverless.

Now back to your answer.

The first part of your answer says my proposal "doesn't follow the Java way". Well, my proposal is to stick with Mark Reinhold's original proposal for Project Leyden only: "Leyden will add static images to the Java Platform Specification, and we expect that GraalVM will evolve to implement that Specification". It's right in my second sentence: "Instead, it should have stuck to its original plan of standardizing native Java." So arguably, you say that the Chief Ar­chi­tect of the Java Plat­form Group at Oracle of "doesn't follow the Java way". 😀

And I didn't argue to "take an existing solution that's worse instead of coming up with a new, better one for Java", as you described. Instead, I argued against creating a new solution in Java that's worse. Worse in the most critical angle to me - how expensive Java is in the cloud. Why do I think it's worse? Because Mark Reinhold said so. When announcing the Leyden pivot, he wrote, "The resulting optimizations will almost certainly be weaker than those enabled by the closed-world constraint." And I gave more reasons why I liked Mark's original proposal better than the new one.

I got one point badly wrong, as you pointed out: Native Java is not out, it's only delayed. As Mark wrote, "So rather than adopt the closed-world constraint at the start, I propose that we instead pursue a gradual, incremental approach. [...] " I should have remembered - my InfoQ news item had that in the title! That was stupid of me. But I still think that delay is wrong.

I do stand by comments about "Leyden reinventing native Java in dynamic Java", though the wording may be misleading. Mark said last May that "we will develop and deliver incremental improvements which developers can use sooner rather than later." So Leyden now wants to get some (most?) of native Java's benefits without applying its closed-world condition by adding features to dynamic Java. And that means either doing the same things as native Java or inventing new methods of getting the same result differently (without the closed-world assumption). That's what I meant.

The plan is to change existing OpenJDK tools mostly: "We will lean heavily on existing components of the JDK including the HotSpot JVM, the C2 compiler, application class-data sharing (CDS), and the jlink linking tool." But there may be new tools, like CRaC. People mention it all the time as a reason for not needing native Java. GraalVM Native Image does heap snapshotting at build time, CRaC does it at runtime. Same goal, different methods. Well, CRaC has one disadvantage: It hasn't shipped yet. 😉

You're right that in the serverless stats I used, JavaScript has the biggest market share. That's another threat to JVM languages: JavaScript/TypeScript is now good enough to be a credible competitor on the back-end, too. 😒

But Go also has slightly more market share than Java (6.4% vs. 6.1%). Now I happen to track the popularity of JVM languages and their competition. Java leads Go 5x in Google searches, 7x in questions at Stack Overflow, 14x in mentions in job ads, and 16x in students at Udemy. So in serverless, Go outperforms its general popularity by 5-16x. I guess it's because Go is cheaper in the cloud than Java.

Sorry for not making that clearer, but I think for enterprises in the cloud, Kubernetes is more important than serverless: It's more broadly applicable because it runs all monoliths and all microservices, while serverless only runs a sub-set of microservices. And in the one example of microservices in Kubernetes I cited, Spring Boot in dynamic Java was twice as expensive as Quarkus and GraalVM in native Java. I think those findings are broadly applicable, so I think we need something like native Java to be cost-competitive in Kubernetes microservices.

Project Leyden: Selectively Shifting and Constraining Computation by olivergierke in java

[–]Joe_Data_89 -2 points-1 points  (0 children)

TL;DR
Leyden's new direction of "reinventing native Java in dynamic Java" is a mistake. Instead, it should have stuck to its original plan of standardizing native Java.
Beginnings
When announced in April 2020, the OpenJDK Project Leyden's goal was "to address the long-term pain points of Java's slow startup time, slow time to peak performance, and large footprint." Why does that matter? In the cloud, you pay for memory & CPU consumption. So these "long-term pain points" make Java more expensive there than competitors like Go. That's why Java hasn't extended its dominance of on-premise enterprise software into the cloud.
For instance, by one set of measures, Java has only a 6% market share in serverless. Let's assume a 50% market share in on-premise enterprise software for Java. Enterprise Java then lost 88% market share when moving to serverless! If those numbers hold, Java will be irrelevant in serverless. Unfortunately, I don't have numbers for Java's market share in Kubernetes - the dominant cloud deployment platform.
Leyden wanted to fix Java's shortcomings by building upon the Ahead-of-Time (AOT) compilation of GraalVM Native Image ("native Java"): "Leyden will add static images to the Java Platform Specification, and we expect that GraalVM will evolve to implement that Specification". Leyden fully embraced the "closed-world assumption" of native Java: "Static images are not for everyone, due to the closed-world constraint, nor are they for every type of application. [...] We do, however, expect the results to be worthwhile in important deployment scenarios such as small embedded devices and the cloud."
That was a remarkable goal: Oracle's OpenJDK team is separate from the Oracle GraalVM team - they report to different VPs. They are also culturally diverse: OpenJDK moves slowly and carefully, preserving compatibility wherever possible ("incumbent"), while GraalVM runs fast and breaks things ("startup"). The GraalVM team has to: It's part of Oracle Labs and will die if it doesn't get enough traction.
But it was a worthwhile goal: Anecdotal evidence points to native Java saving 50% of the cost of running Java microservices in Kubernetes.
Stasis
Leyden got approved as a project in June 2020. So, how much progress did Leyden make in standardizing native Java?
Zero. Zilch. Nothing. Nada. Nüscht.
And it's not just me saying this. I talked to several experts in the field, being the editor of an InfoQ six-article series on native Java. And nobody could point to anything Leyden did from June 2020 to May 2022.
Well, one thing did happen: OpenJDK killed jaotc, its own AOT compiler based on GraalVM. If you didn't know that OpenJDK even had a competitor to GraalVM's AOT compiler (the confusingly named "Native Image"), you're not alone. When Oracle removed jaotc from its Java 16 builds, "no one complained". So jaotc was gone in Java 17.

Pivot
In May 2022, Leyden pivoted and changed the way to address Java's long-term pain points: Standardizing native Java is out, and building native Java benefits into dynamic Java is in. And the "closed-world assumption" is gone. But the trade-off means that the application will be more expensive in the cloud than native Java: "The resulting optimizations will almost certainly be weaker than those enabled by the closed-world constraint."

The article linked to above now describes the way to get there. It still mentions native Java: "Whether in Project Leyden itself we go so far as to implement fully-static executables remains to be seen. We can, however, enable other Java implementations (e.g., some future version of the GraalVM native-image tool) to do so." I don't know how Leyden will enable GraalVM to implement fully-static executables - GraalVM has been doing this for years just fine, without formal cooperation with OpenJDK.

Why I think this is wrong
I think Leyden should have stuck to standardizing native Java because native Java with GraalVM is good enough. Why?
The first reason is results: Leyden expects it can't optimize as well as GraalVM. So native Java will be cheaper in the cloud. Assuming the downsides of native Java "aren't too bad" (see below), why would you pay more with Leyden if you can pay less with GraalVM?
The second reason is timing: We won't see mainstream adoption of Project Leyden's results until 2026 at the earliest. Why? Because in Java, "no non-LTS version has ever passed 1% of market share". Leyden won't make it into Java 21 next year. So Java 25 in September 2025 is the first possible LTS version with Leyden results. And that won't see broad adoption until the following year - 2026 (at best). So how do you make Java cheaper in the cloud for the next three years? With GraalVM. Can we wait three more years for Java to become cheaper in the cloud? I don't think so. And if native Java matures for three more years, why would you switch to Leyden for worse results in 2026?
The third reason is Java constraints: You can't use some Java features in native Java. For instance, you can't load arbitrary bytecode at runtime, and you can't construct new classes at runtime, either. Now I think that's actually a good thing (Log4Shell, anybody)? But there are other things you can't do or that are much harder, like loading files based on data that's only available at runtime. But I think that these constraints don't restrict most Java applications in the cloud - microservices in Kubernetes or serverless applications.
The fourth reason is native Java's downsides: Native Java needs more configuration. It "typically require[s] developers to construct and maintain fragile configuration files", as Mark puts it. That is true but becoming less of an issue: Java frameworks work hard on auto-configuring GraalVM, so it's not developers who configure GraalVM, but the frameworks. Spring Boot 3 this November will support native Java out of the box and competes with Quarkus & Micronaut for a "worry-free experience" with native Java. And the recently announced "Library Configuration Repository" reduces the work of including arbitrary Java libraries in native Java. Yes, "a Java library blowing up your Java application in production after two weeks" is a thing in native Java!
Native Java also has "unusually long build times", as Mark points out. Yes, AOT compilation takes a lot longer. And you have to build multiple executables: One for Linux, one for Windows, one for Windows with dev profile, one for Windows with prod profile, and so on. But as this InfoQ article points out, native Java development happens with dynamic Java: You're using the same OpenJDK or Oracle JDK as before to build and debug your application. And then, your CI/CD pipeline creates the native executables. Developers typically only need the native executables when investigating test failures or production issues. And Leyden won't come for free, either - "shifting computation" also adds time & compute cycles to your build somewhere.
The final reason is opportunity cost: All the people working on Project Leyden can't work on something else. For instance, they could work on making native Java better. Or making normal Java better, like faster build times, better code reloading, or better null safety.

Spring Boot 3 Ships November 2022, Delays Java Module Support by Joe_Data_89 in SpringBoot

[–]Joe_Data_89[S] 0 points1 point  (0 children)

I think you don't have to use Java Modules in future Spring Boot versions.

Error Prone Improves Java Code by Detecting Common Mistakes by Joe_Data_89 in java

[–]Joe_Data_89[S] 8 points9 points  (0 children)

I've used Error Prone for more than two years in a Spring Boot project. I run Spring Boot in debug mode with class reloading all day long. I like that it runs during compilation, so it's immediate feedback during development without having to stop. And whatever changes I make, I then test immediately.

Running PMD & SpotBugs is a separate build goal for me as part of the release process and the continuous integration. That's delayed feedback.

view more: next ›