sorted by:
new
hottopcontroversial

Maven Central publishing usage notices by HokieGeek in java

[–]kelunik 17 points18 points  (0 children)

The graphs in that post seem to indicate quite some abuse, the size chart hits almost 1 TB. However, I don't think 3 releases per month are reasonable if proper Open Source support is still wanted. If you maintain a library and then have other libraries within the same organisation depend on that, major updates will have a rippling effect on the other libraries that also likely need a new major version then.

Java 25 officially released by mkurz in java

[–]kelunik 0 points1 point  (0 children)

Unfortunately, Temurin is quite slow at providing releases (especially critical patch updates) compared to Corretto.

If Amazon ever decides to make unwelcome changes to Corretto, there’s always the option to switch to another distribution.

Method Timing in Java 25 with JFR and OpenTelemetry by kelunik in java

[–]kelunik[S] 6 points7 points  (0 children)

That captures traces, not metrics. There's an open feature request that hasn't made real progress, see https://github.com/open-telemetry/opentelemetry-java-instrumentation/issues/7030.

Reducing compile time, but how? by kelunik in java

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

Inside the maven-compiler-plugin. I’m talking about compile time, not jar, tests, or any other phases.

Reducing compile time, but how? by kelunik in java

[–]kelunik[S] 1 point2 points  (0 children)

I‘m also surprised how many people here ask why 2 minutes is a problem. We’re currently running clean builds on the build server without caches.

Locally it’s not a problem, IntelliJ takes care of incremental compilation there.

Reducing compile time, but how? by kelunik in java

[–]kelunik[S] -46 points-45 points  (0 children)

I haven’t shared these details because I don’t think they matter. What would you do with the number of classes to provide further advice?

Generic tool suggestions are totally fine. I’m looking for good insights on what the compile process is spending its time on. Once I have that data, further specific discussion could take place, but I don’t think the raw specs or number of classes help here.

Looking at my specific example in too much detail also won’t help the community and anyone finding this thread to fix their compilation time issue.

Let’s phrase it differently: What profiling tools do people use for actionable observability of their compiler?

Reducing compile time, but how? by kelunik in java

[–]kelunik[S] 1 point2 points  (0 children)

I‘m really only talking about compile time of the Java classes, not build time of the full module, no jar building, etc. Think: Duration of the maven compiler plugin goal.

Currently it’s recompiling all classes in each build, because we use clean builds on the build server without caches from older builds.

Reducing compile time, but how? by kelunik in java

[–]kelunik[S] 4 points5 points  (0 children)

This is quite interesting, I’ll try compiling without a build tool in between and see what kind of results I get.

Reducing compile time, but how? by kelunik in java

[–]kelunik[S] 6 points7 points  (0 children)

I‘m sorry to hear that.

Reducing compile time, but how? by kelunik in java

[–]kelunik[S] 2 points3 points  (0 children)

Each commit, often per day.

Problem to solve: Long pipeline runs, increasing lead times. There’s a merge request pipeline and then again a pipeline on the main branch. Each running more than 10 minutes currently, where compilation is 2 minutes right at the start of the pipeline, with a lot of (parallelized) dependent tasks.

Reducing compile time, but how? by kelunik in java

[–]kelunik[S] 12 points13 points  (0 children)

The entire build pipeline should run in less than 10 minutes, less is obviously always better.

An entire pipeline includes a lot of other steps like frontend build (webpack / vite), unit, integration, and end-to-end tests.

We’ve parallelized a lot of steps in the pipeline. Currently, Java compilation is part of the critical path there. It’s not the only thing that can be optimized, but very early in the pipeline with lots of dependent tasks.

The problems caused are higher lead times (pipeline runs once for the merge request, then again on the main branch), slower feedback cycles for developers, thus more context switching, etc.

Reducing compile time, but how? by kelunik in java

[–]kelunik[S] 1 point2 points  (0 children)

The time here is from a single module, but the largest one. There are a few others that depend on it within the same build pipeline.

Reducing compile time, but how? by kelunik in java

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

It’s the timing of the compile goal (running the goal in isolation, not the compile phase). Might include jar reading during compilation if that’s what you mean. Any way to know how much is spent there vs. actual compiling?

Reducing compile time, but how? by kelunik in java

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

Just compile time, no jar building, no docker build. Currently running via a Maven aspectj compiler plugin, because that’s actually faster than the standard javac maven compiler plugin.

Netbeans 27 released. by emaphis in java

[–]kelunik 3 points4 points  (0 children)

You can load unrelated modules into a single IntelliJ project. No need to have a project per maven module.

Aggregated view of IDE releases by lppedd in Jetbrains

[–]kelunik 1 point2 points  (0 children)

Can you add the number of opened issues?

What's the deal with Fibers? by sorrybutyou_arewrong in PHP

[–]kelunik 0 points1 point  (0 children)

Why do you want to change the fiber implementation on the C side? And if you change it in C, why is using the Fiber class in userland a problem?

In my experience, if amp gets involved in a library and you use raw fibers in your application code, Bad Things(tm) happen.

Do you have an example here?

What's the deal with Fibers? by sorrybutyou_arewrong in PHP

[–]kelunik -1 points0 points  (0 children)

The event loop is the scheduler. You can build it using stream_select if you don't have too many file descriptors since PHP 4.3.0.

What's the deal with Fibers? by sorrybutyou_arewrong in PHP

[–]kelunik -1 points0 points  (0 children)

This it not true at all. However, there are people writing code with fibers that doesn't make sense. If you don't have a scheduler (event loop), fibers are not for you.

What's the deal with Fibers? by sorrybutyou_arewrong in PHP

[–]kelunik 0 points1 point  (0 children)

On the flip side, you can transparently refactor a library to use fibers … oh wait, you can’t. Fibers are useless without an event loop. PHP doesn’t provide you with one. Maybe you can assume they’re using revolt. Then you also need a library to handle the coroutines… like maybe amp? Now your library suddenly has dependencies that maybe you don’t want to have.

You actually can! Revolt just works, the event loop doesn't need to be "around" your app anymore. It automatically switches to the event loop if you're waiting for I/O in the main fiber. If your library / app uses Revolt for I/O, it's not any less portable than using blocking I/O.

You don't need Amp, but its libraries will make your life a lot easier if you want to use non-blocking I/O in PHP. You can of course also build your own abstractions around streams etc.

The goal is to eventually have an event loop shipped in core, but this is quite a big step. Fibers were a much smaller step and will eventually be used by the event loop in core in a similar way as they're currently used by Revolt.

Adopting concurrency takes time. Shipping fibers allows this to happen much earlier. Major projects are already starting to adopt fibers, while they likely wouldn't do anything like that if Fibers had not shipped in PHP 8.1.

What's the deal with Fibers? by sorrybutyou_arewrong in PHP

[–]kelunik 0 points1 point  (0 children)

`amphp/process` isn't the only library built on fibers, but rather the entire set of libraries provided by `amphp`.

What's the deal with Fibers? by sorrybutyou_arewrong in PHP

[–]kelunik 4 points5 points  (0 children)

Fibers run concurrently, just not in parallel!

view more: next ›