DEV Community: Davor Hrg

Why Why Why Wyhash could be a valuable tool in your toolbox

Davor Hrg — Sun, 22 Mar 2026 10:39:09 +0000

I recently went down the rabbit hole of non-cryptographic hash functions and emerged with a new favorite: Wyhash. It's not just another hash algorithm; it's a tiny beast that has found its way into modern high-performance environments like Zig and Bun.

Here is why I think it deserves a spot in your developer toolbox.

Of series of #stealbackfromai

The Need for Speed on Modern Hardware

We are living in a 64-bit world, yet many legacy hash functions (like MurmurHash3) were designed when 32-bit operations were king. Wyhash is unapologetically modern.

It is designed efficiently for 64-bit processors, leveraging native 64x64 -> 128-bit multiplication. This allows it to process data in larger chunks and achieve incredibly high throughput without needing complex, platform-specific SIMD instructions (like AVX or NEON). It’s portable speed.

Quality You Can Trust

Speed is nothing without quality. "Fast" hash functions often fail to pass stringent statistical tests, leading to collisions and poor distribution in hash maps.

Wyhash passes Smhasher, the gold standard test suite for non-cryptographic hash functions. It produced no bias and no collisions in the entire battery of tests. This makes it safe for hash tables, bloom filters, and other probabilistic data structures where collision resistance matters.

Simplicity is the Ultimate Sophistication

The algorithm is surprisingly simple. The core implementation fits on a single screen. It uses a "multiply and mix" (MUM) strategy:

Initialize state with a secret and seed.
Consume input in 48-byte blocks.
Mix the state using 128-bit multiplication products XORed into 64-bit results.
Finalize with a last round of mixing.

That's it. No complex S-boxes, no massive lookup tables.

Learning Java 18+ along the way

One of the hurdles in porting Wyhash to Java is that it relies heavily on unsigned 128-bit math. Java, historically, has been strictly signed.

In the past, we had to use "tricks" to emulate unsigned multiplication, often involving multiple operations and careful bit-shifting.

However, while implementing this, found out that Java 18 introduced Math.unsignedMultiplyHigh(long x, long y). This intrinsic method maps directly to the hardware instructions (like MUL on x86_64) that produce the upper 64 bits of a 128-bit product.

The Power of the Default Seed

We often think of seeds as something that must be random to prevent HashDoS attacks. And for hash maps receiving untrusted input, that is true.

But Wyhash could serve another powerful purpose: Compatibility.

By using the standard "default secret" (originating from the C++ implementation) and a fixed seed (like 0), Wyhash becomes a deterministic, cross-language checksum.

You can hash a file in Zig, send it over the wire, and verify it in Java or JavaScript (Bun) using the exact same algorithm. This is incredibly to me personally, and you may have totally different requirements. Sadly it is not given that same variant is implemented in different languages. So if you are aiming for compatibility you yourself must make sure same variant is used.

A Note on Versions and Compatibility

Wyhash has evolved through several versions (v1, v2, v3/final3, v4). While the algorithm's core principles remain the same, different versions produce different hash outputs for the same input. From what I was able to research, and my own preferences v3/final3 looks to be the way to go.

Java Port & Zig: This Java implementation is a direct port of the version used in the Zig standard library (std.hash.Wyhash), effectively the final3 (v3) variant. This ensures binary compatibility with Zig applications.
Bun: Bun.hash is directly compatible with Zig's std.hash.Wyhash. Because Bun is written in Zig, its Bun.hash function is a direct binding to the Zig standard library's implementation.
Go 1.17+: Not compatible. Uses a "Wyhash-inspired" fallback implementation for its map hashing. It is not a direct port and will not be binary compatible with standard Wyhash implementations.
@pencroff-lab/wyhash-ts: provides a specific wyhash_bun function to explicitly guarantee this Zig-compatible behavior in other Node.js environments.

So, for cross-language checksums, ensure both sides are speaking the same "dialect" (version) of Wyhash and using the same seed.

The "Frozen" Problem: Zig values stability in its standard library. Because std.hash is often used for persistent data (like hash maps or disk-backed caches), the Zig team is extremely hesitant to update the implementation to the latest C version (v4.2). Doing so would change the hash output for the same input/seed, silently corrupting data for anyone relying on consistent hashes across Zig versions.

Why a Standalone Implementation?

Initially, I looked at existing libraries like Hash4j. It's a fantastic library, but it's a large dependency if you only need one algorithm.

Sometimes, the best dependency is the one you don't add.

Wyhash represents a sweet spot in modern engineering: it's fast, simple, high-quality, and portable. If you need a hash function for your next tool, give it a look.

scrollbar-gutter to the rescue

Davor Hrg — Fri, 06 Mar 2026 10:09:17 +0000

As of 2026, scrollbar customization has reached a high level of cross-browser stability through standard CSS properties, specifically addressing preventing content width changes (layout shifts).

Of series of #stealbackfromai

Preventing Content Width Changes

The most effective way to ensure a scrollbar does not change content width is the scrollbar-gutter property, which is now widely supported in modern browsers.

scrollbar-gutter: stable;: This reserves space for the scrollbar even when content doesn't overflow. This prevents the "jumping" effect where content shifts left once a scrollbar appears.
Integrating with Padding: When no scrollbar is present, the reserved gutter is painted as an extension of your existing padding. This allows you to define a consistent layout where the scrollbar simply "fills in" the space you've already allocated.
Centering Content: You can use scrollbar-gutter: stable both-edges; to reserve space on both sides of a container, keeping centered content perfectly aligned regardless of scroll state.

Floating/Overlay Behavior

"floating" scrollbars are typically handled as overlay scrollbars by the operating system (standard on macOS and mobile).

Native Overlay: If the OS uses overlay scrollbars, they naturally float on top of content without affecting layout width.
Standard Styling: You can now use standard properties like scrollbar-width (values: auto, thin, none) and scrollbar-color to adjust look and feel across Chrome, Firefox, and Safari without relying solely on old -webkit- prefixes.

Implementation Summary

To achieve a look where the scrollbar doesn't shift content and fits within your padding:

.container {
  overflow-y: auto;
  /* Reserves the space so content width stays fixed */
  scrollbar-gutter: stable;
  /* Modern styling for the scrollbar itself */
  scrollbar-width: thin;
  scrollbar-color: #888 transparent; 
}

To implement a layout where the scrollbar occupies the "padding" area without shifting content, you can combine

scrollbar-gutter: stable with CSS variables to dynamically manage your container's internal spacing.

Modern Implementation with CSS Variables

This approach uses a variable for padding that accounts for the scrollbar space, ensuring your content remains visually centered or aligned as if the scrollbar were "floating" in that reserved gutter.

:root {
  /* Define base padding for your layout */
  --site-padding: 2rem;
  /* Use a variable for scrollbar color for easy theme switching */
  --sb-thumb: #888;
  --sb-track: transparent;
}

.scroll-container {
  /* 1. Layout Stability */
  overflow-y: auto;
  /* Always reserves space for the scrollbar so content doesn't jump */
  scrollbar-gutter: stable; 

  /* 2. Visual Customization (2026 Standards) */
  scrollbar-width: thin; /* Options: auto, thin, none */
  scrollbar-color: var(--sb-thumb) var(--sb-track);

  /* 3. Padding Integration */
  /* Content is padded by --site-padding, and the gutter 
     sits alongside it without pushing the content in further */
  padding-inline: var(--site-padding);

  /* Optional: Mirror the gutter on the left for perfect centering */
  /* scrollbar-gutter: stable both-edges; */
}

/* Hover effect to make the "floating" bar more interactive */
.scroll-container:hover {
  --sb-thumb: #555;
}

demos

CodePen by Connum Comprehensive Toggle Demo: This allows you to toggle scrollbar-gutter: stable and both-edges on and off to see exactly how it prevents layout shifts.
CodePen by waxolunist Centered Content Demo: This shows how to use stable both-edges to keep content perfectly centered within its padding, even when a scrollbar is added.
interactive demo on Defensive CSS shows how this works with your padding specifically, which focuses on using this property to keep UI "polished" and prevent content from bumping into the scrollbar.

Recap

In these examples, the magic happens with these three lines:

.container {
  overflow-y: auto;          /* Only show scrollbar if needed */
  scrollbar-gutter: stable;  /* Reserve the space to prevent width change */
  padding: 20px;             /* Scrollbar sits in its gutter, NOT on your padding */
}

how does this compare to scroll: always

While overflow-y: scroll (always) and scrollbar-gutter: stable both prevent layout shifts, they differ significantly in visual "clutter" and how they handle different operating systems.

Comparison Table

Feature	`overflow-y: scroll`	`scrollbar-gutter: stable`
Visibility	Always shows the scrollbar track and thumb, even if content doesn't overflow.	Only shows the thumb when content overflows, but always reserves the space.
Visual Look	Can look "broken" or cluttered on short pages due to the empty track.	Keeps the layout clean; the reserved space is invisible (matches background) until needed.
Layout Shift	Prevents shifts because the scrollbar is permanent.	Prevents shifts by "locking" the content width regardless of overflow state.
Overlay SB	Forces a gutter even on systems that use floating/overlay scrollbars (like macOS).	Smart: On overlay systems, it reserves zero space because the scrollbar floats on top anyway.

The main drawback of the old overflow-y: scroll trick is that it forces an "ugly" empty scrollbar track on every page.

With scrollbar-gutter: stable, the browser reserves the exact width of a scrollbar as a "blank" gutter.

When content is short: You see your background color in that gutter, but no scrollbar track.
When content overflows: The scrollbar thumb simply appears in that reserved space.
With Overlay Scrollbars: It does nothing on mobile or macOS (where scrollbars don't take up space), whereas overflow: scroll might force an unnecessary layout change

Reset

Many modern "resets" now use this combination for a polished feel:

html {
  /* Only scroll if needed */
  overflow-y: auto; 
  /* Fallback for older Safari versions */
  overflow-y: scroll; 
  /* Modern standard to prevent jumping */
  scrollbar-gutter: stable; 
}

caniuse scrollbar-gutter
MDN Web Docs scrollbar-gutter
CSS-Tricks Guide scrollbar-gutter
Go Make Things Prevent scrollbar jump

Java record compact constructors (steal back from ai)

Davor Hrg — Wed, 25 Feb 2026 09:49:29 +0000

First in the series of #stealbackfromai

you need validation for record or default values ?

I was silly trying this to define default values in a record:

public static record SomeCounts(UUID id, Long v1, Long v2, Long v3){
    SomeCounts(UUID id, Long v1, Long v2, Long v2){
        this(id,
                v1== null ? 0l : v1,
                v2== null ? 0l : v2,
                v3== null ? 0l : v3
                );
    }
}

It does not compile (Canonical constructor cannot delegate to another constructor). Turns out there is nicer and cleaner way already provided called compact constructor.

Compact constructors

Compact constructors in Java records provide a concise way to customize the canonical constructor (the default one matching the record's components) without repeating parameter names.

Syntax Basics
Declare it immediately after the record header, using just the record name in braces—no parameter list needed:

public static record SomeCounts(UUID id, Long v1, Long v2, Long v3){
    public SomeCounts{
        // id = id; //do not do this, just set values you want to change
        v1 = v1== null ? 0l : v1,
        v2 = v2== null ? 0l : v2,
        v3 = v3== null ? 0l : v3
        // Validation example: 
        //if (id == null) throw new IllegalArgumentException();
    }
}

The compiler implicitly supplies parameters matching the fields and handles field assignments after your body executes.¹²

Execution Flow

Your compact body runs first (for validation/normalization).
Compiler auto-assigns parameters to final fields.
Superclass Record constructor completes.

You can modify parameters (like null checks), throw exceptions, or print logs, but cannot assign fields directly (this.v1 = ... fails compilation).³

Key Benefits

Zero boilerplate: No need to write this.field = field; everywhere.
Immutable safety: Fields stay final; changes only affect incoming parameters before final assignment.
Canonical only: Applies to the main constructor; doesn't affect static factories or other overloads.

Common Patterns

Use Case	Example Code
Null-to-default	`v1 = (v1 != null) ? v1 : 0L;` ⁴
Range validation	`if (v3 < 0) throw new IllegalArgumentException();` ⁵
Normalization	`id = id.toString().toLowerCase();` ⁵

This keeps your record cleaner while ensuring numeric fields are never null post-construction.¹⁶⁷⁸⁹¹⁰

Do not set all fields

How Assignment Works
The compact constructor modifies local parameter variables, not fields directly. After your body executes, the compiler implicitly assigns each parameter to its corresponding final field, so those values that you do not change are set(I was defensive and setting all of them, but even).

If you declare an empty compact constructor, it will work just fine, no worries like for java beans.

public static record SomeCounts(UUID id, Long v1, Long v2, Long v3){
    public SomeCounts{
        // all values will be set, do not worry
    }
}

"Steal" back from AI #stealbackfromai

Davor Hrg — Wed, 25 Feb 2026 09:31:36 +0000

What?

I am making tiny an effort, to share summaries from things I find useful, that google and others stole from stackoverflow and all of us. It may be recursive or pointless, but I am doing it anyway.

Also, if anyone is interested, can comment on each of those, maybe fix some mistakes or provide different opinion, or whatever.

No commitment, just an experiment. Also, could be useful to me in the future, ... who knows.

There will likely be somewhat embarasing things, I should have known much before, but hey, shit happens.

They are pisseed

My thing here is in no way as consequential as destilling, but hope never dies that I can make some tiny difference.

https://www.youtube.com/watch?v=W9WB2xbM5sc

REST is often THE WRONG CHOICE, it is a lazy default for too many, and I am sick of it.

Davor Hrg — Sun, 21 Dec 2025 17:48:05 +0000

TL;DR: Rant: When the frontend simply calls backend methods(it's RPC), REST is the wrong choice there. It’s your decision if you still want to use it, sure it gets the job done, but it’s not really ok when forced on those who don’t need or want it. You should at least know JSON-RPC exists (and has actual good spec, unlike REST).

Thumbnail from The Family Guy :

dick, you ever wonder what's outside those walls ?
now, that's dangerous thinking Paul, you better stick to your work

Why I rant about it

This wouldn’t be as bad if it weren’t affecting the freedom to choose the best fit for a specific project in practice. The problem with trendy tech is that it trickles down, so it’s shoved down our throats regardless of whether it fits or not. All kinds of "experts" who influence the choice of technology in specifications, auditing, and management go along with those trends, because deviating would make them look less "expertly."... Also AI loves statistically average slop.

Scope

This text applies to use cases where two sets of code communicate through method calls. A persistent backend that exposes API methods to perform some work, and a frontend that uses a wrapper—such as Axios to turn the API into convenient methods for components to call. Using REST as the communication layer in this scenario is downright disgusting. REST may be better fit for PHP depending on how URLs are routed, or whatever else.

I prefer making single-page applications and do not care even slightly for SSE. I’ve done my share of PHP programming, experienced some horrible things in Java EE, ASP and .NET, and I’m never going back to that.

Why REST is wrong here

On both sides of the communication, you have code that is neatly defined as a method or an interface. It has a method name, some parameters, a return value, and it can throw an exception (or, if you prefer, return a union type with an error).

Instead of providing a clear and simple mapping, you are using REST, and it introduces an unnecessary layer of noise:

Different HTTP methods
Different content types in responses, especially in case of errors
Sometimes parameters are passed in the URL
Sometimes they are passed in the request body

This gives me flashbacks to SOAP, where values could be passed either in tags or in attributes, creating a mess when you try to map everything.

Look at this simple example in Java

@GetMapping("/users/{userId}/orders")
public List<Order> getUserOrders(
    @PathVariable Long userId,       // From path: /users/123/orders
    @RequestParam String status  // ?status=PENDING
) {
    return orderRepository.findByUserIdAndStatus(userId, status);
}

It may not look too bad because people are used to it. But there is so much pointless noise here.

@Rpc()
public List<Order> getUserOrders(Long userId, String status) {
    return orderRepository.findByUserIdAndStatus(userId, status);
}

R: But I like REST

Why are you reading this? Just move along.

R: But REST is better because of X...

Why are you still here? GTFO.

There are better ways

Anything consistent is better. I’m sure there are great options like gRPC, but it’s easy to build your own. And if you’re used to sending JSON around, it will probably end up looking like JSON-RPC .

R: But I like shiny generated Swagger/OpenApi

You can still generate that easily without the REST mess. I have written code to generate API swagger few times, and it is not rocket science. You should be ashamed If you can't use some Java reflection to do the same.

R: Are you sending HTTP 200 for errors too ?

By default yes, because I do not care, HTTP is just one of possible transport layers. Errors are communicated inside the JSONRPC protocol. Why do you care? If really needed it is rather simple to also send different HTTP codes.

Adding security to routes

I would not do it by default. It is trivial to do, just enforce method names are part of the URL (even if it means they are redundantly in the RPC payload).

On the other hand it is actually not a bad idea to add method name to url in a way it can be ignored by the backend, as it helps you see method names when inspecting in browser (instead a slew of requests to /rpc).

Compact API on JS side

Mapping API methods can be done in type safe way without bloating the bundle with a simple proxy and types declaration.

const handler = () =>{
  const makeRpcHandler = method =>{
    return function(params){
      return new Promise((resolve,reject)=>{
        // call api method here and resolve / reject
      })
    }
  }
  return {
    get(target, prop, receiver) {
      if(prop in target)  return target[prop]
      return target[prop] = makeRpcHandler(prop)
    },
}}

/** @typedef { import('./MyApiInterface.js').MyApi } MyApi */
/** @type {MyApi} */ 
export const MyApi = new Proxy(target, handler())

And the MyApiInterface.ts

export interface SearchParam {
  filter?: Array<Object>
  order?: Array<string>
}
export interface Book {
  id: number
  title: string
}
export interface SearchResult<T> {
  data: Array<T>
  limit: number
  offset: number
  rowcount: number
}

export interface MyApi{
  bookSearch(search: SearchParam): Promise<SearchResult<Book>>
}

Later in your code, just import MyApi and use with all of the types visible in your editor.

import {MyApi} from './MyApi.js'

function someThing(){
  // IDE will know result is SearchResult<Book>
  const result = await MyApi.bookSearch({filter:[...]})
  console.log(result.data)
}

Notice that you have a single proxy that routes methods, and type safety is achieved through type definitions that will not be part of the bundle. Therefore, whether you have one method or one hundred, the bundled code for the bridge remains the same size.

More details

How about NO. The point here is that you think about it a bit and decide if you still think REST is so great, and then accept the consequences of your decision. Code examples here are not a full solution, just to explain a bit deeper, what things could be.

If you think SOAP is terrible but REST is great.

I have news for you. SOAP is objectively much better technology than REST, but that also makes it complicated, and then sprinkle complication by big companies(MS, IBM, Oracle) and SOAP becomes even bigger pain in the ass to use as a developer.

Enshittification

https://en.wikipedia.org/wiki/Enshittification is really nice term that I would like to draw some parallels here. REST by itself is not the sole issue here, it is part of a pattern.

I can not speak about other languages, but in Java this ties neatly into Spring. These systems are intentionally made complicated so a ecosystem of consultants earn money. You are lured into using it by "Look how easy it is to make XY" but then for every little step you have to learn (or pay consultants) how to do it with Spring. Soon you are not coding, but configuring Spring. After you are hooked with "simple to start a project" you pay the price later (search: Spring cloud Gateway).

AI can help

I strongly disagree here. AI will just make it worse. It will help produce more of the same bloated code that is in-line with short term corporate thinking, and will create a long term nightmare.

Hibernate HQL builder

Davor Hrg — Wed, 05 Mar 2025 21:53:50 +0000

Intro

A single utility class for writing HQL in more readable way. Simplifies writing multiline queries, and queries that have optional parts depending on parameter values (like API adding extra filter by date if supplied date != null).

The utility

For now, this not published as a maven library. Just copy the utility class HqlBuilder.java from hql-query-builder to your project. If you like it, but not 100%, just tweak it to your own coding style.

Rant: *I both love and hate(more) Hibernate. I try to avoid it, but that is not always possible. Technologically Hibernate is great , and has sooo many features. For the same reason it is also is a huge bloat, slows down start-up, does freaky bytecode manipulation, and is pain in the ass so many times. Takes a ton of time to learn and obscures learning actual SQL. *

Basic comparison and sample use

Standard way to write HQL is ok for smaller queries, but gets ugly very quickly.

Query q = session.createQuery(
  "SELECT id FROM Adddress WHERE userId = :userId AND houseNo > :houseNo")
q.setParameter("userId", userId);
q.setParameter("houseNo", 2L);

This style is also supported by HqlBuilder (but it allows much more)

var hb = new HqlBuilder(
  "SELECT id FROM Adddress WHERE userId = :userId AND houseNo > :houseNo");
hb.p("userId", userId);
hb.p("houseNo", 2L);

The above query can be written like this:

var hb = new HqlBuilder();
hb.add("SELECT id");
hb.add("FROM Adddress");
hb.add("WHERE");
hb.add("  userId = :userId", userId);
hb.add("  AND houseNo > :houseNo", 2L);

in a way that allows more formatting options for readability, and also placing parameter values close to where they are used in the query itself.

Each call to add puts a newline before each line(except the first), so, for the code above, HQL will look like this:

SELECT id
FROM Adddress
WHERE
  userId = :userId
  AND houseNo > :houseNo

Debug and logging

You can get the query that is going into hibernate by calling hb.getQueryString() and you will get the query above.

You can also dump what query with values looks like with hb.toString(). Not actual SQL that will go into database, just an approximation where parameter placeholders are replaced with values(NULL for null values, and for other .toString())

SELECT id,street,city
FROM Adddress
WHERE
  userId = 11
  AND houseNo > 2

You can improve this output by implementing more logic into valueToString method.

Executing the query using Hibernate

When you finish building the desired HQL, just call .build(session) or .build(session, resultType) to create a Hibernate Query object (that you can then use to list results)

hb.build(session, Long.class).list()

More details on .add

The builder can be constructed empty, or with parameters (it is just alias to .add)

var hb = new HqlBuilder();
hb.add("SELECT * FROM User");
// is same as
var hb = new HqlBuilder("SELECT * FROM User");

So, the further examples we will be for .add method

Add just a new query part (with or without parameter placeholders)

hb.add("FROM User");

Add query part with parameters and values

hb.add("WHERE userId = :userId", userId);

If you are providing values for parameters, you must match count of parameters in query part. Either provide all parameter values, or provide none (and define them later using .p).

Add a new query part with parameter placeholders, and provide parameter values separately)

hb.add("  AND city = :city");
hb.p("city", city);

Hibernate HQL works nice with records

As you can give a record to Hibernate Query to fill it with query results, this gives a nice way of working with selected data (this is part of Hibernate, not a feature added by this utility).

// Address entity has many more fields, here we define those that we plan to select
public record AddressPart(Long id, String street, String city){};

public List<AddressPart> getUserAddresses(Long userId){
  var hb = new HqlBuilder();
  hb.add("SELECT id,street,city");
  hb.add("FROM Adddress");
  hb.add("WHERE");
  hb.add("  userId = :userId", userId);

  Session session = ...;// obtain hibernate session in your app

  return hb.build(session, AddressPart.class).list()
}

More examples

A query that has optional name filter. If name is not provided, name filter is not added to query.

public List<User> getUsers(String name){
  var hb = new HqlBuilder();
  hb.add("FROM User");// HQL when selecting whole entities only needs FROM
  hb.add("WHERE");
  hb.add("  deleted = :deleted", false);
if(name != null && !name.isEmpty()){
  hb.add("  name LIKE :name", "%"+name+"%");
}
  Session session = ...;// obtain hibernate session in your app

  return hb.build(session, User.class).list()
}

Dilemma 1: parameters without name

Not sure if it s good or bad to use the builder like this, but I could not help but to allow this use-case. If you just use : without defining parameter name, then values are required at the .add method call.

var hb = new HqlBuilder();
hb.add("SELECT id,street,city");
hb.add("FROM Adddress");
hb.add("WHERE");
hb.add("  userId = :", userId);
hb.add("  AND houseNo > :", 2L);

For the code above, HQL will look like this:

SELECT id,street,city
FROM Adddress
WHERE
  userId = :_param_1
  AND houseNo > :_param_2

Dilemma 2: conditional code formatting

I would like to keep consistent visual formatting of indent in conditional statements. Example of such is:

  var hb = new HqlBuilder();
  hb.add("FROM User");// HQL when selecting whole entities only needs FROM
  hb.add("WHERE");
  hb.add("  deleted = :deleted", false);
  if(name != null && !name.isEmpty()){
    hb.add("  name LIKE :name", "%"+name+"%");
  }

Now that if statement moves/confuses the indent of the HQL slightly. This is not a huge issue, but it bothers me. I have not found perfect solution, but am playing with few ideas.

One idea is to move java code indent back:

  var hb = new HqlBuilder();
  hb.add("FROM User");FROM
  hb.add("WHERE");
  hb.add("  deleted = :deleted", false);
if(name != null && !name.isEmpty()){
  hb.add("  name LIKE :name", "%"+name+"%");
}

Another idea is utility function in the builder (but it works only for one line of HQL)

  var hb = new HqlBuilder();
  hb.add("FROM User");
  hb.add("WHERE");
  hb.add("  deleted = :deleted", false);
  hb.add(name != null && !name.isEmpty(),
      "  name LIKE :name", "%"+name+"%");

... Edit: addNextIf (it was very error prone) is replaced with overload to add with first argument as boolean condition for when to add the part or not.

Java livereload

Davor Hrg — Wed, 22 Jan 2025 14:00:22 +0000

Intro

Aim of this article is to help you reduce delay between writing code and seeing the results in Java.

Background: I have been coding Java in backend and JavaScript in fronted for ages, and have grown accustomed to test things in JavaScript with livereload, but was not doing enough of that in Java.

Disclaimer: I am not a fan of TDD, and amount of test I write depends on time I got and also on my mood at the time. Even if you do not write many tests you can see how playing with some pieces of code and seeing results immediately can be useful.

How ?

Steps are really simple.

run in DEBUG mode
collect list of files to watch
run a thread to watch for changes
wait for a bit (100ms is reasonable) for hot-code-replace to kick in
re-run your code
continue looping until files change

package hr.hrg.livetest4j;

import java.io.File;

public class BasicExample {

    public static void main(String[] args) {
        new Thread(()->{
            File[] files = {new File("target/test-classes/hr/hrg/livetest4j/BasicExample.class")};
            long lastMod = 0;
            while(!Thread.interrupted()) {
                try {
                    long mod = lastMod;
                    for(File file:files) {
                        if(!file.exists()) {
                            System.err.println("file not found "+file.getAbsolutePath());
                            return;
                        }
                        mod = Math.max(mod, file.lastModified());
                    }
                    if(mod != lastMod) {
                        // wait a bit more for hot-code-replace to kick in
                        Thread.sleep(100);
                        test();// run this on change
                    }
                    lastMod = mod;
                    Thread.sleep(100);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }).start();
    }

    static void test(){
        System.out.println("Hello basic 1");
    }
}

Location of class files may be different depending on your IDE setup, and common ones are:

target/classes
target/test-classes
bin

LiveTest4j utility

https://github.com/hrgdavor/livetest4j

For now I do not plan to package it as maven dependency. It is simple enough to copy the Utility class from the project into your own project with other test classes.

It started rather simple like the basic example above, but I have added few nice things so it is more usable in general.

After you copy LiveTest4j.java to your project create a new file and simply use it like this:

public class LiveTestSimple {
    public static void main(String[] args) throws Exception{
        new LiveTest4j(()->{
            System.out.println("Hello live 1");
        })
        .run();
    }
}

Run you class in debug mode, change something , save and watch the magic happen!

The utility has some nice things

it can extract class info from lambda to automatically add class file to watch list
uses few common paths to search for generated class (and you can add your own)
has debug mode detection to warn you if you mistakenly run it normally
has an annotation to declare dependencies (classes,files) to add to watch list

This can be very useful for specific use-cases, and if you like the benefits you can go further

run a specialised agent that allows more advanced code replace (built-in code reload is limited to method bodies)
setup live reload in Spring
use a commercial solution like JRebel

Feedback

All feedback how to improve the utility are welcome, also further resources on this topic as well.

I tested this only in eclipse, so it would be great you can try it in your favourite editor and see if advanced things like debug mode detection works.