You can now watch the recording of my #DPESummit talk: Boosting Developer Productivity Through Better Modularity

Thoughts on: Why do we have too much accidental complexity in the modularity setup of many software projects? How can that be improved in the Java ecosystem?

πŸŽ₯ Video: https://dpe.org/sessions/jendrik-johannes/boosting-developer-productivity-through-better-modularity

πŸ—‚οΈ Slides/Example: https://github.com/jjohannes/java-module-system

#Gradle #Java #JPMS #Modularity

Boosting Developer Productivity Through Better Modularity | DPE Summit 2024

Presented by Jendrik Johannes (Onepiece.Software) at DPE Summit 2024, an event developed and hosted by Gradle.

Developer Productivity Engineering Summit 2024

#dpesummit

Gradle in Ephemeral Build Environments

* you can accumulate irrelevant stuff in cache, so you may want to clear or prune it periodically

#dpesummit

(tuning) Gradle to be fast in Ephemeral Build Environments

* Gradle readonly cache across multiple Docker instances running Gradle.
* Or save your dependency cache outside the ephemeral environment and restore it.

* always use the smallest distribution (like the no-docs distribution)

#dpesummit

Gradle and Ephemeral Build Environments

* measure your baseline case
* compare each change

* you can include, in your Dockerfile (etc.), the Gradle wrapper distribution; it's a safe choice to reinstall it.
* generate your files as part of the ephemeral build environment creation and bake them in, if possible, don't regenerate them.

#dpesummit

Gradle and Ephemeral Build Environments

you can keep some basic state around like the Gradle wrapper which includes some baked-in resolution

don't regenerate those each time in your ephemeral environment

(some other details as to what you can do to reduce the dependency resolution time)

#dpesummit

Gradle Build Tool
* running daemon
* active config cache with data
* build cache (shared, still works)

Things you should do to make the Gradle Build Tool, what to do and what not to do in an ephemeral CI environment.

Don't run some of the caches.

Build tool provides: Caching, Incrementality, Parallelism

caches and incrementality are gone in ephemeral CI.

(some details of Gradle build process and sequence)

#dpesummit

Last talk (in "Gods and Monsters" lightning talks set).

"Don't let ephemeral CI kill your developer build productivity"

why is Gradle fast? / what do you get with ephemeral build environments?

* Gradle daemon
* config cache
* parallel execution
* build cache

Ephemeral environments:
* industry trend
* isolation -> fewer state problems
* short-lived -> wipe it clean, don't manage it or keep it going

but you need some state to start from. How much can we use?

#dpesummit

Buck2 Q and A

Q: (Eden...)
A: You don't need Eden FS to get the Buck2 benefits.

Q: (integrations)
A: Buck2 supports the standard Bazel plugins for build integrations, like Build Buddy.

#dpesummit

Buck2 Q and A

Q: can it cache test results like Bazel?
A: yes, it may be turned off

Q: how do you use external packages?
A: Rust cargo to import, using our tool "reindeer"; but FB vendors-in dependencies, and some imports are more supported than others.

Q: Is open-source Eden Filesystem available in MacOS?
A: You should check the Eden project website for that. Try Buck2 without Eden first, because it needs a kernel module.

#dpesummit

Performance 5 of 5 (guess I missed 3 and 4?)

repository watcher needed to keep a sense of when files have been last changed, can't really do a traversal in reasonable time

Good:
* powerful, fast, modern build system
* actively under development
* Open source, meaningfully.

Bad:
* a heavy lift to change build systems
* new, only a few external to FB/Meta users
* some rules aren't ready for Open Source yet (mobile, Android)
* integration w/package managers weak (vendored-in at FB)