Java Code Geeks

Level up your penetration testing skills with this 9-course bundle

Java Code Geeks — Sat, 18 Apr 2026 10:30:30 +0000

Level up your penetration testing skills with this 9-course bundle

TL;DR: The 2026 Complete Offensive Cyber Security Bundle packs 9 courses and 78 hours of hands-on online security training, covering Kali Linux, Metasploit, Burp Suite, and more, for just $29.99 (reg. $180).

Whether you’re a junior developer looking to break into security or a senior engineer who wants to formalize offensive techniques you’ve already been using, quality training is essential.

The 2026 Complete Offensive Cyber Security Bundle gives you a structured, comprehensive path through the core tools and methodologies that define modern ethical hacking. It’s on sale for $29.99 (reg. $180).

Put together by Oak Academy, the bundle covers 78 hours of curriculum across 9 full courses. You get practical, tool-focused training on the platforms and frameworks that actually show up in professional penetration testing engagements: Nmap and Nessus for network scanning, Metasploit for exploitation, Kali Linux for your primary attack environment, and Burp Suite for web application bug bounty workflows.

What the curriculum covers

The web application coverage is especially thorough. Two dedicated courses walk through hacking web apps and conducting penetration tests against them, with a third course zeroing in on Burp Suite specifically for bug bounty hunters. For anyone targeting certifications like CEH, OSCP, or CompTIA PenTest+, this breadth of coverage across tooling, techniques, and environments is exactly the kind of self-paced prep material that complements more formal study.

Beyond the technical tooling, the bundle also includes courses on Wi-Fi hacking and wireless penetration testing, plus a course dedicated to social engineering, phishing, OSINT, and malware, which rounds out the human-layer attack surface that often gets overlooked in more tool-centric training.

All 9 courses come with lifetime access, so you can work through the material at your own pace and return to specific modules as your projects evolve.

At $29.99 for 78 hours of content across 9 courses, the per-hour value here is hard to beat for anyone serious about building out offensive security skills.

You can grab The 2026 Complete Offensive Cyber Security Bundle today for $29.99 (reg. $180).

StackSocial prices subject to change.

Tags

[FREE EBOOKS] Ransomware Protection Playbook, Job Architecture & Four More Best Selling Titles

Java Code Geeks — Sat, 18 Apr 2026 10:30:30 +0000

Meta JCG

[FREE EBOOKS] Ransomware Protection Playbook, Job Architecture & Four More Best Selling Titles

Hello fellow geeks,

Fresh offers await you on our Information Technology Research Library, please have a look!

	Ransomware Protection Playbook ($28.00 Value) FREE for a Limited Time Avoid becoming the next ransomware victim by taking practical steps today. Colonial Pipeline. CWT Global. Brenntag. Travelex. The list of ransomware victims is long, distinguished, and sophisticated. And it’s growing longer every day. In Ransomware Protection Playbook, computer security veteran and expert penetration tester Roger A. Grimes delivers an actionable blueprint for organizations seeking a robust defense against one of the most insidious and destructive IT threats currently in the wild. You’ll learn about concrete steps you can take now to protect yourself or your organization from ransomware attacks. In addition to walking you through the necessary technical preventative measures, this critical book will show you how to: Quickly detect an attack, limit the damage, and decide whether to pay the ransom. Implement a pre-set game plan in the event of a game-changing security breach to help limit the reputational and financial damage. Lay down a secure foundation of cybersecurity insurance and legal protection to mitigate the disruption to your life and business. A must-read for cyber and information security professionals, privacy leaders, risk managers, and CTOs, Ransomware Protection Playbook is an irreplaceable and timely resource for anyone concerned about the security of their, or their organization’s, data. Get it FREE!
	Job Architecture: Building a Language for Workforce Intelligence ($35.00 Value) FREE for a Limited Time Harness the power of taxonomies for better human capital management and employee wellbeing. In Job Architecture, economist and entrepreneur Ben Zweig offers a revolutionary approach to transforming human capital management through the power of taxonomies. The book follows the experience and ideas of key individuals-from the founders of Wall Street, to the original management consultant, to a young data scientist just out of grad school looking to make sense of the modern workforce-in order to illustrate why our current human capital infrastructure is not serving employees well and what we can do to change that. By categorizing and organizing workforce data, Zweig provides a practical roadmap for creating a more efficient and data-driven labor market. This book includes key insights on how to: Use AI and similar large language model technologies to support businesses with appropriate categorization and regimentation of data. Know whether or not a taxonomy can be useful and functional for an organization in their ability to be flexible, auditable, and adaptable. Build a taxonomy that meets the needs of a workforce or organization through clustering, labeling, and production. Combining storytelling with real-world examples, theoretical analysis, and a practical framework, Job Architecture is an essential guide for companies to manage a competitive, modern workforce that improves the working experience for all employees. Offer Expires 4/28/2026. Get it FREE!
	Coexisting with AI: Work, Love, and Play in a Changing World ($28.00 Value) FREE for a Limited Time Your comprehensive, easy-to-understand guide on AI’s impact in business and life. Coexisting with AI: Work, Love, and Play in a Changing Worldis an exploration of how AI can be used at each stage of our lives. It helps readers understand the positive impact of AI and where governance is needed from both an individual and business perspective. From childhood through to aging, this book delivers a holistic understanding of this exciting new technology in language that anyone can understand regardless of technical expertise. Written by Kay Firth-Butterfield, former inaugural Head of AI at the World Economic Forum and one of the most foremost experts in the world on the governance of AI, topics explored in this book include: An explanation of AI and Chatbots and their dependence on data. How to use AI wisely in business, with your children and in your life. How AI might be used in politics and war. The good, bad, and ugly of AI now and into the future. AI’s potential to solve some of humanity’s biggest problems, from human trafficking to disease. Essential governance considerations to make AI a beneficial technological development for all. Coexisting With AIearns a well-deserved spot on the bookshelves of all individuals, from tech executives to curious citizens, seeking expert insight on where AI can take us and how to plot the best path forward for your family and business. Offer Expires 4/28/2026. Get it FREE!
	The Art of Attack: Attacker Mindset for Security Professionals ($30.00 Value) FREE for a Limited Time Take on the perspective of an attacker with this insightful new resource for ethical hackers, pentesters, and social engineers. In The Art of Attack: Attacker Mindset for Security Professionals, experienced physical pentester and social engineer Maxie Reynolds untangles the threads of a useful, sometimes dangerous, mentality. The book shows ethical hackers, social engineers, and pentesters what an attacker mindset is and how to use it to their advantage. Adopting this mindset will result in the improvement of security, offensively and defensively, by allowing you to see your environment objectively through the eyes of an attacker. The book shows you the laws of the mindset and the techniques attackers use, from persistence to “start with the end” strategies and non-linear thinking, that make them so dangerous. You’ll discover: A variety of attacker strategies, including approaches, processes, reconnaissance, privilege escalation, redundant access, and escape techniques. The unique tells and signs of an attack and how to avoid becoming a victim of one. What the science of psychology tells us about amygdala hijacking and other tendencies that you need to protect against. Perfect for red teams, social engineers, pentesters, and ethical hackers seeking to fortify and harden their systems and the systems of their clients, The Art of Attack is an invaluable resource for anyone in the technology security space seeking a one-stop resource that puts them in the mind of an attacker. Get it FREE!
	Creative Machines: AI, Art & Us ($35.00 Value) FREE for a Limited Time A bold and thought-provoking journey into AI’s power to transform human creativity. In Creative Machines: AI, Art & Us, world-renowned AI researcher and generative AI pioneer, Maya Ackerman, takes you on a thrilling journey into the rise of creative AI, from its earliest pioneers to the cutting-edge tools shaping music, art, and human imagination today. Ackerman cuts through the hype, revealing the true capabilities and limitations of generative AI while championing its potential to amplify human creativity rather than replace it. Drawing on psychology, philosophy, and her own cutting-edge research, she reveals how generative AI exposes both the brilliance and the blind spots of human society-our ingenuity, our biases, our assumptions about intelligence and identity. The book contains: The hidden history and explosive growth of AI-generated creativity. Explorations of the true capabilities and limitations of creative AI. A visionary framework for using AI as a tool to enhance, rather than hinder, human creativity. A bold new perspective on AI ethics and why fixing AI is not enough. Perfect for entrepreneurs, tech leaders, developers, ethicists, and creative professionals, Creative Machines offers deep insights, compelling stories, and a visionary perspective on AI’s impact on human society. An essential read for anyone doing their best to navigate the rapidly evolving landscape of generative AI. Get it FREE!
	Risky is the New Safe: The Rules Have Changed…($45.00 Value) FREE for a Limited Time THE NEW YORK TIMES BESTSELLER and #1 WALL STREET JOURNAL BESTSELLER. Risky Is the New Safe is a different kind of book for a different kind of thinking-a thought-provoking manifesto for risk takers. It will challenge you to think laterally, question premises, and be a contrarian. Disruptive technology, accelerating speed of change and economic upheaval are changing the game. The same tired, old conventional thinking won’t get you to success today. Risky Is the New Safe will change the way you look at everything! You’ll view challenges-and the corresponding opportunities they provide-in entirely new and exciting ways. You’ll recognize powerful new gateways to creating wealth. In this mind-bending book you’ll discover: How mavericks like Steve Jobs, Richard Branson, and Mark Cuban think differently-and what you can learn from them;. The six-month online course that could allow you to earn more than a Ph.D.;. How social media changes branding and marketing forever, and what that means for you;. What happens when holo-suites and virtual-reality sex come about, and how you need to prepare;. The new religion of ideas: How to become an “idea generator” and declare as a free agent; and,. What will cause the Euro, precious metals, and oceanfront real estate to collapse-and how that can make you rich!. Get it FREE!

That’s it for now, we hope you found them insightful. Stay tuned for more!

Till next time, keep geeking!

Tags

Recursion in Python – Introduction For Beginners

Yatin Batra — Fri, 17 Apr 2026 15:08:00 +0000

Python

Recursion in Python – Introduction For Beginners

Recursion is a fundamental concept in programming that helps simplify complex problems by breaking them into smaller, repeatable steps. Understanding how recursion works is essential for writing clean and efficient solutions for many real-world scenarios. Let us delve into our recursion in python intro for beginners to understand how this powerful technique simplifies complex problems by breaking them into smaller, manageable steps.

1. Understanding Recursion in Python

Recursion is a programming technique where a function calls itself to solve a problem. Instead of solving the entire problem at once using loops, recursion divides it into smaller, more manageable subproblems. Each recursive call works on a reduced version of the original problem until it reaches a simple condition that can be solved directly. Recursion is widely used in computer science for problems that have a natural hierarchical or repetitive structure, such as mathematical computations, tree traversal, and divide-and-conquer algorithms.

1.1 Core Rules of Recursive Functions

Base Case: This is the terminating condition of the recursion. Without a base case, the function would keep calling itself indefinitely, leading to a stack overflow error. The base case ensures that recursion eventually stops.
Recursive Case: This is the part where the function calls itself with a smaller or simpler input. Each recursive call should bring the problem closer to the base case.

1.2 When Should You Use Recursion?

Divide and Conquer Problems: When a problem can be split into smaller independent subproblems (e.g., merge sort, quicksort).
Tree and Graph Traversal: Recursive approaches naturally fit hierarchical structures like trees (DFS traversal, binary tree operations).
Nested or Hierarchical Data: Parsing JSON, file systems, or XML structures where elements contain sub-elements.
Backtracking Problems: Problems like permutations, combinations, Sudoku solving, and N-Queens where you explore all possible solutions.
Mathematical Problems: Factorial, Fibonacci sequence, power calculations, etc.

When NOT to use recursion: Avoid recursion when the problem can be solved more efficiently with iteration, especially when dealing with very large inputs due to memory overhead.

1.3 How Python Executes Recursive Calls

Python uses a call stack to manage function calls. Every time a function is called (including recursive calls), a new stack frame is created and pushed onto the stack. This frame contains:

Function arguments
Local variables
Return address (where to go after execution)

When a function completes execution, its stack frame is removed (popped), and control returns to the previous function call.

1.4 Recursion vs Iteration

Recursion	Iteration
Uses function calls	Uses loops (for/while)
Elegant and concise for complex problems	More straightforward for simple repetitive tasks
Higher memory usage (call stack)	Lower memory usage
Can lead to stack overflow if not controlled	No stack overflow risk
Closer to mathematical definitions	Closer to machine-level execution

1.5 Python Recursion Limit

Python imposes a recursion depth limit (typically around 1000) to prevent infinite recursion from crashing the program. This limit ensures that the interpreter does not exceed the maximum stack size.

import sys

# Check current recursion limit
print(sys.getrecursionlimit())

# Increase limit cautiously
sys.setrecursionlimit(2000)

This code demonstrates how to work with Python’s recursion limit using the built-in sys module. First, import sys loads the module that provides access to system-specific parameters and functions. The statement sys.getrecursionlimit() retrieves the current maximum recursion depth (typically around 1000), which is the number of nested function calls Python allows before raising a RecursionError to prevent a stack overflow; this value is printed using print(). The next line, sys.setrecursionlimit(2000), increases this limit to 2000, allowing deeper recursive calls. However, this should be done cautiously because increasing the limit does not increase available memory, and setting it too high can lead to a program crash if the call stack exceeds system capacity.

2. Recursion Examples

This example demonstrates multiple real-world applications of recursion, including mathematical computation, nested data processing, tree traversal, and optimization using memoization.

# recursion_examples.py

# 1. Factorial using recursion
def factorial(n):
    if n == 0 or n == 1:
        return 1
    return n * factorial(n - 1)


# 2. Sum of nested list using recursion
def sum_nested(data):
    total = 0
    for item in data:
        if isinstance(item, list):
            total += sum_nested(item)
        else:
            total += item
    return total


# 3. Tree traversal using recursion
class Node:
    def __init__(self, value):
        self.value = value
        self.children = []

def traverse(node):
    print(node.value, end=" ")
    for child in node.children:
        traverse(child)


# 4. Fibonacci using memoization
def fib(n, memo={}):
    if n in memo:
        return memo[n]
    if n <= 1:
        return n
    memo[n] = fib(n-1, memo) + fib(n-2, memo)
    return memo[n]


# ---- Running all examples ----

# Factorial
print("Factorial of 5:", factorial(5))

# Nested list sum
nested_list = [1, [2, 3], [4, [5, 6]]]
print("Sum of nested list:", sum_nested(nested_list))

# Tree traversal
root = Node("A")
b = Node("B")
c = Node("C")
d = Node("D")

root.children = [b, c]
b.children = [d]

print("Tree Traversal:", end=" ")
traverse(root)
print()

# Fibonacci with memoization
print("Fibonacci of 10:", fib(10))

2.1 Code Explanation

This program demonstrates multiple practical uses of recursion in Python. The factorial(n) function calculates the factorial of a number by defining a base case (n == 0 or n == 1) that returns 1, and a recursive case that multiplies n with the factorial of n-1. The sum_nested(data) function processes a list that may contain nested lists by iterating through each element; if an element is itself a list, the function calls itself recursively to compute its sum, otherwise it adds the value directly to the total. The Node class represents a tree structure where each node has a value and a list of children, and the traverse(node) function performs a depth-first traversal by printing the current node’s value and then recursively visiting each child node. The fib(n, memo={}) function computes the Fibonacci number using recursion combined with memoization, where previously computed results are stored in a dictionary to avoid redundant calculations, significantly improving performance. Finally, the program executes all examples: it computes the factorial of 5, calculates the sum of a nested list, constructs and traverses a tree structure, and prints the 10th Fibonacci number, demonstrating how recursion can be applied to mathematical problems, hierarchical data, and performance optimization.

2.2 Code Output

Factorial of 5: 120
Sum of nested list: 21
Tree Traversal: A B D C 
Fibonacci of 10: 55

The output shows the results of executing each recursive example in sequence. The line Factorial of 5: 120 comes from the factorial function, where the recursive calls multiply values from 5 down to 1 (5 × 4 × 3 × 2 × 1). The line Sum of nested list: 21 is produced by recursively traversing the nested list structure [1, [2, 3], [4, [5, 6]]] and adding all elements together. The Tree Traversal: A B D C output represents a depth-first traversal of the tree, where the root node “A” is visited first, followed by its left child “B”, then “B”‘s child “D”, and finally the sibling node “C”. Lastly, Fibonacci of 10: 55 is the result of the optimized recursive Fibonacci function, where memoization avoids repeated calculations and efficiently computes the 10th Fibonacci number.

3. Conclusion

Recursion is a powerful and elegant problem-solving technique that works by breaking complex problems into smaller, more manageable subproblems, making it especially useful for tasks like tree traversal and handling nested data structures; however, it must be applied carefully due to potential performance overhead and stack limitations. The key principles to remember are to always define a clear base case to prevent infinite recursion, ensure that each recursive call reduces the problem size so it progresses toward termination, use optimization techniques like memoization to avoid redundant computations and improve efficiency, and prefer iterative approaches when dealing with very deep recursion levels to prevent stack overflow and maintain better performance.

Tags

The Halting Problem, Rice’s Theorem,and the Walls They Build

Eleftheria Drosopoulou — Fri, 17 Apr 2026 14:28:52 +0000

Software Development

The Halting Problem, Rice’s Theorem,and the Walls They Build

Why no algorithm — and no AI model — can fully decide what programs do, and what that means for every static analysis tool you’ve ever shipped.

In 1936, Alan Turing proved something extraordinary: no algorithm can exist that reliably determines whether an arbitrary program will eventually stop running or loop forever. This was not a temporary gap in our knowledge — it was a proof that the gap is permanent. Eighty-nine years later, that result still explains why your linter produces false positives, why your AI code reviewer misses certain bugs, and why formal verification tools ask you to write invariants by hand.

This article is for developers who want the theory behind the tools — not just what these limits are, but why they exist and, critically, what they imply for the static analysis landscape of 2026.

1. The Setup: What Does “Decidable” Actually Mean?

Before we get to the proof itself, it’s worth being precise about what we’re claiming. A problem is decidable if there exists an algorithm that, given any valid input, terminates in finite time and outputs a correct yes or no. A problem is undecidable if no such algorithm can possibly exist — not because we haven’t found one yet, but because it can be proven that one cannot exist.

Notice the strength of that claim. We’re not talking about computational complexity — about problems that are solvable in principle but slow in practice. Undecidability is a categorical wall. Throwing more hardware, more memory, or more model parameters at an undecidable problem doesn’t help. The impossibility is mathematical, not technological.

Turing formalised computation itself in order to make this kind of proof possible. He invented a theoretical device — now called a Turing machine — which is a minimal model of computation powerful enough to simulate any algorithm. Once you have a formal model, you can ask rigorous questions about what that model can and cannot compute.

2. The Halting Problem: Turing’s Original Proof

The Halting Problem asks: given a program P and an input I, does P eventually halt when run on I? Turing proved in his 1936 paper that no algorithm can answer this for all possible (P, I) pairs. The proof is a masterpiece of diagonal reasoning — a technique also used by Cantor to show that the real numbers are uncountable.

The Halting Problem — Proof by Contradiction
Assume a decider HALT(P, I) exists that always returns YES if P halts on I, and NO otherwise.

Now construct a new program D(P):

If HALT(P, P) returns YES → loop forever.
If HALT(P, P) returns NO → halt immediately.

Ask: what does D(D) do? If D halts when run on itself, HALT(D, D) returns YES, so D loops forever — contradiction. If D loops forever, HALT(D, D) returns NO, so D halts — contradiction.

Conclusion: HALT cannot exist. The assumption leads to a logical impossibility regardless of which branch we follow. QED.

The key move is self-reference: we construct a program that takes another program as its own input, then feeds itself to itself. This diagonal argument creates a situation with no consistent answer, proving that no general decider can handle it.

Importantly, the proof says nothing about specific programs. We can absolutely determine that many individual programs halt — compilers do this all the time for simple loops. The undecidability is about the general case: there is no algorithm that works for every possible program.

3. Rice’s Theorem: The Full Generalisation

If the Halting Problem feels like a narrow edge case, Rice’s Theorem removes that comfort entirely. Proved by H. Gordon Rice in 1953, it says something much broader:

Rice’s Theorem (informal): For any non-trivial semantic property of programs — any question about what a program does rather than what it looks like — there is no general algorithm that decides whether an arbitrary program has that property.

A semantic property is one that depends on the program’s behaviour, not its syntax. “Does this program ever output the number 42?” is semantic. “Does this program contain a for-loop?” is syntactic. Rice’s Theorem covers all semantic properties.

“Non-trivial” means the property is true of some programs and false of others. The theorem doesn’t cover the vacuous cases of “true of all programs” or “true of no programs.” Every interesting question you’d want to ask about program behaviour is non-trivial.

Together, the two results form a complete boundary. The Halting Problem is one instance of an undecidable semantic property. Rice’s Theorem tells you that all semantic properties are undecidable — without exception.

Question about a Program	Type	Decidable?
“Does it contain a try-catch block?”	Syntactic	Yes — parse the AST
“Does it always terminate?”	Semantic	No — Halting Problem
“Does it ever throw a NullPointerException?”	Semantic	No — Rice’s Theorem
“Does it produce the same output as program Q?”	Semantic	No — Rice’s Theorem
“Does it ever access an uninitialised variable?”	Semantic	No — Rice’s Theorem
“Is it free of all security vulnerabilities?”	Semantic	No — Rice’s Theorem
“Does it conform to this type signature?”	Semantic (restricted)	Sometimes — with language restrictions

That last row is worth pausing on. Strongly typed functional languages like Haskell and languages with dependent types like Coq or Lean deliberately restrict what programs can express, specifically so that certain semantic properties become decidable. The price is expressiveness; the reward is provability. That trade-off is the entire philosophy behind type theory.

4. What This Means for Static Analysis Tools

Static analysis is the practice of examining code without running it, in order to find bugs, enforce style, or verify correctness. Every major IDE ships with static analysis. So does every CI pipeline worth its salt. But given Rice’s Theorem, what are these tools actually doing?

The answer is that they operate by restricting the problem. Since the general case is undecidable, all sound static analysis tools approximate — and every approximation has one of two failure modes:

Analysis Strategy	What It Does	False Positives?	False Negatives?	Example Tools
Over-approximation (Sound)	Reports all possible errors, including impossible ones	Yes	Never	Astree, Polyspace, Infer
Under-approximation (Complete)	Only reports confirmed real errors	Never	Yes	Fuzzing, bounded model checking
Heuristic (Neither)	Balances usability against both error types	Yes	Yes	ESLint, SonarQube, Semgrep, CodeQL

Facebook’s Infer, for example, uses a technique called bi-abduction derived from separation logic to reason about heap memory. It is sound for the properties it checks — it won’t miss a null dereference it has committed to checking — but it produces false positives and doesn’t cover all possible properties. That’s not a bug in Infer; it’s the only mathematically coherent choice available.

Meanwhile, tools like ESLint operate with heuristics: pattern-matching on ASTs, dataflow through a bounded number of steps, known-bad code signatures. These are neither sound nor complete, but they are useful — and usefulness, not completeness, is the engineering goal.

Static Analysis Tools: Soundness vs. False Positive Rate

Bubble size represents approximate deployment breadth. Tools closer to the origin are more practically useful day-to-day; tools toward the top-right sacrifice noise tolerance for guarantees.

5. The AI Problem: Why Larger Models Don’t Change the Math

In 2026, the most discussed static analysis tools are increasingly AI-powered: GitHub Copilot’s review suggestions, Amazon CodeGuru, Cursor’s inline diagnostics, and a growing constellation of LLM-backed linters. A natural question follows: do these tools escape the limits imposed by Rice’s Theorem?

The answer is no — and understanding why clarifies what AI code analysis can and cannot do.

Rice’s Theorem applies to any computational procedure, not just traditional algorithms. A transformer model is a fixed function mapping inputs to outputs. Running it constitutes a computation. Therefore, if it claimed to decide an arbitrary semantic property of programs — with no false positives and no false negatives — it would constitute a decider for that property, which Rice’s Theorem proves cannot exist.

What this means practically: An AI model that claimed to reliably detect all possible null dereferences in all possible programs would be claiming to solve an undecidable problem. Either it misses some (false negatives), flags non-issues (false positives), or both. This is not a current limitation of AI capability — it is a permanent mathematical boundary.

What AI does change is the nature of the approximation. Traditional static analysis tools use handcrafted rules and formal abstractions. AI tools use patterns learned from billions of lines of code. Neither approach is complete, but they have very different failure profiles:

Dimension	Traditional Static Analysis	AI-Powered Analysis (2026)
Theoretical basis	Formal semantics, abstract interpretation, dataflow	Statistical patterns from training data
Error type bias	Predictable (over- or under-approximation by design)	Unpredictable — depends on training distribution
Novel bug classes	Misses bugs not in its rule set	May generalise; may hallucinate new patterns
Auditability	High — rules are inspectable	Low — weights are not human-readable
Rice’s Theorem status	Subject to it; acknowledged explicitly	Subject to it; rarely acknowledged

The practical implication is that AI analysis tools are best understood as extremely sophisticated heuristics. They can catch bugs that pattern-matching rules miss. They can suggest fixes with context sensitivity that no rule system achieves. But they cannot, even in principle, achieve completeness. Every benchmark that evaluates them — including SWE-bench and emerging security benchmarks — captures an approximation of capability, not a proof of coverage.

Furthermore, AI models introduce a subtly different failure mode: confident incorrectness. A formal sound analyser that flags a false positive at least knows it’s making a conservative approximation. An LLM that hallucinates a security vulnerability explanation may do so with high fluency and apparent certainty. For safety-critical applications, this distinction matters enormously.

6. Formal Verification: Escaping Undecidability Through Proof

If undecidability prevents algorithms from automatically deciding semantic properties, how do formal verification tools like Coq, Lean, and Isabelle actually work? The answer is that they shift the burden — they don’t decide properties automatically, they help humans construct machine-checked proofs of those properties.

The key distinction is between verification and decision. Deciding whether a property holds requires an algorithm that works on any program. Verifying a specific property of a specific program, with a human-written proof, is a different task — one that can succeed even for undecidable properties, as long as a proof exists and someone writes it.

Real-world example: The seL4 microkernel is a formally verified OS kernel whose correctness — including memory safety, absence of deadlocks, and adherence to its security policy — has been mechanically checked in Isabelle. The verification took approximately 11 person-years of proof engineering. Undecidability didn’t prevent this; it just meant a human had to specify and prove the invariants, rather than a tool discovering them automatically.

This is precisely why formal verification requires human-specified invariants, loop contracts, and pre/post conditions. These annotations are the human’s contribution to the proof. Without them, the tool has no way to know what you intend the program to do — and by Rice’s Theorem, it cannot infer that from the code alone.

Assurance Level vs. Engineering Effort Across Verification Approaches

Effort is normalised relative to writing the program itself. Assurance reflects the theoretical coverage guarantee, not bug-finding rate in practice.

7. Code Coverage and the Completeness Illusion

One final implication is worth spelling out directly, because it catches even experienced engineers off guard. 100% code coverage does not mean your test suite covers all program behaviours.

Code coverage measures whether a line or branch was executed during a test. It says nothing about whether the execution explored all reachable paths, encountered all possible inputs, or triggered all observable behaviours. A function can have 100% branch coverage and still behave incorrectly on inputs your tests never considered.

Rice’s Theorem provides the theoretical underpinning for why this gap is irreducible. Deciding whether a test suite covers all semantically distinct behaviours of a program is itself an undecidable problem. No coverage tool, however sophisticated, can close that gap in general — which is exactly why coverage is a proxy metric, not a correctness certificate.

Practical takeaway: Use coverage as a floor, not a ceiling. 80% line coverage is a meaningful minimum signal. But “we have 100% branch coverage” should not be read as “we have verified correctness.” The two claims belong to entirely different theoretical categories.

Demonstrating the limits: a halting program a simple checker gets wrong

The following Python snippet is self-contained, requires Python 3.x, and illustrates why even straightforward-looking termination is hard to determine statically. It implements the Collatz sequence — a computation no one has yet proven always halts, despite being expressible in four lines of code:

# Python 3.x required — no external packages needed
# Run with: python collatz.py

def collatz(n):
    """
    Collatz conjecture: for any positive integer n,
    this sequence is conjectured to always reach 1.
    No general proof exists. A static analyser cannot
    decide termination for this function — neither can
    any human, as of 2026.
    """
    steps = 0
    while n != 1:
        n = n // 2 if n % 2 == 0 else 3 * n + 1
        steps += 1
    return steps

# These all terminate quickly
for start in [6, 27, 871]:
    print(f"collatz({start}) → {collatz(start)} steps")

# Output:
# collatz(6)   →  8 steps
# collatz(27)  →  111 steps
# collatz(871) →  178 steps

No static analysis tool, no AI model, and no existing mathematical proof can tell you that collatz(n) terminates for every positive integer n. This is not a gap in tooling maturity — it is an open problem in mathematics that Rice’s Theorem tells us cannot, in general, be mechanically decided.

8. What We’ve Learned

The Halting Problem proves — by contradiction, via Turing’s diagonal argument — that no algorithm can decide whether an arbitrary program halts for all possible inputs. This is a permanent mathematical boundary, not a temporary engineering gap.
Rice’s Theorem generalises this completely: every non-trivial semantic property of programs — anything about what a program does — is undecidable. Security, termination, output correctness, null safety: all of them, without exception.
Static analysis tools escape undecidability by restricting the problem: sound tools over-approximate (false positives, no false negatives), complete tools under-approximate (false negatives, no false positives), and heuristic tools like ESLint and SonarQube trade formal guarantees for practical usefulness.
AI-powered code analysis is subject to exactly the same theoretical limits. Larger models change the shape of the approximation — and can be dramatically better heuristics — but cannot achieve completeness for any non-trivial semantic property.
Formal verification (Coq, Lean, Isabelle, seL4) sidesteps undecidability by having humans write proofs rather than asking tools to discover them automatically. Human-specified invariants are not a workaround — they are a necessary contribution to the proof.
Code coverage is a proxy for testing effort, not a correctness certificate. 100% coverage cannot, in principle, guarantee all semantic behaviours are tested — Rice’s Theorem explains precisely why.

Tags

Jackson deserialization using a multi-parameter constructor

Yatin Batra — Fri, 17 Apr 2026 08:30:59 +0000

Core Java

Jackson deserialization using a multi-parameter constructor

JSON deserialization is a common requirement in modern applications that interact with APIs and external systems. Handling different object creation patterns efficiently is key to building robust and maintainable Java applications. Let us delve into understanding Jackson deserialization with a multi-parameter constructor.

1. Introduction to Jackson Deserialization

Jackson is one of the most widely used libraries in Java for processing JSON data. It provides powerful features for converting JSON into Java objects (deserialization) and Java objects into JSON (serialization). By default, Jackson relies on a no-argument constructor and setter methods to populate object fields during deserialization. However, in modern Java applications, developers often prefer immutable objects, constructor-based initialization, and concise data models such as records. In such cases, the default approach is not sufficient. Jackson addresses this limitation by supporting annotations like @JsonCreator and @JsonProperty, which allow deserialization using multi-parameter constructors.

1.1 Setup and Dependency Configuration

To get started, you need to include the Jackson Databind dependency in your project. This module provides the ObjectMapper class, which is the core API used for reading and writing JSON. If you are using Maven, add the following dependency to your pom.xml:

<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-databind</artifactId>
    <version>stable__latest__version</version>
</dependency>

Make sure to replace stable__latest__version with the latest stable version available in Maven Central. Once added, your project will have access to all core Jackson features required for JSON deserialization.

2. Complete Code Example

This example demonstrates multiple Jackson deserialization approaches in a single program: default constructor, @JsonCreator with a multi-parameter constructor, Java records, and enum handling.

// Main.java

import com.fasterxml.jackson.annotation.JsonCreator;
import com.fasterxml.jackson.annotation.JsonProperty;
import com.fasterxml.jackson.databind.ObjectMapper;

// Enum with custom deserialization
enum Status {
    ACTIVE, INACTIVE;

    @JsonCreator
    public static Status fromValue(String value) {
        return Status.valueOf(value.toUpperCase());
    }
}

// 1. Default deserialization (uses constructor + setters)
class DefaultUser {
    private String name;
    private int age;
    private Status status;

    public DefaultUser() {} // required default constructor

    public String getName() { return name; }
    public void setName(String name) { this.name = name; }

    public int getAge() { return age; }
    public void setAge(int age) { this.age = age; }

    public Status getStatus() { return status; }
    public void setStatus(Status status) { this.status = status; }
}

// 2. @JsonCreator with multi-parameter constructor (immutable)
class ImmutableUser {
    private final String name;
    private final int age;

    @JsonCreator
    public ImmutableUser(@JsonProperty("name") String name,
                         @JsonProperty("age") int age) {
        this.name = name;
        this.age = age;
    }

    public String getName() { return name; }
    public int getAge() { return age; }
}

// 3. Record (Java 14+)
record RecordUser(String name, int age) {}

public class Main {
    public static void main(String[] args) throws Exception {

        ObjectMapper mapper = new ObjectMapper();

        // Default deserialization
        String json1 = "{ \"name\": \"John\", \"age\": 30, \"status\": \"active\" }";
        DefaultUser user1 = mapper.readValue(json1, DefaultUser.class);
        System.out.println("DefaultUser: " + user1.getName() + " - " + user1.getAge() + " - " + user1.getStatus());

        // @JsonCreator deserialization
        String json2 = "{ \"name\": \"Alice\", \"age\": 25 }";
        ImmutableUser user2 = mapper.readValue(json2, ImmutableUser.class);
        System.out.println("ImmutableUser: " + user2.getName() + " - " + user2.getAge());

        // Record deserialization
        String json3 = "{ \"name\": \"Bob\", \"age\": 40 }";
        RecordUser user3 = mapper.readValue(json3, RecordUser.class);
        System.out.println("RecordUser: " + user3.name() + " - " + user3.age());
    }
}

2.1 Code Explanation

This program demonstrates multiple ways to perform JSON deserialization using Jackson in Java, including default deserialization, constructor-based deserialization with @JsonCreator, record support, and custom enum handling. The ObjectMapper class is the core component responsible for converting JSON strings into Java objects.

The Status enum defines two constants: ACTIVE and INACTIVE. It uses a custom @JsonCreator method named fromValue, which allows Jackson to convert incoming JSON values into enum constants. The method transforms the input string to uppercase before mapping it, enabling case-insensitive deserialization (for example, “active” becomes ACTIVE).
The DefaultUser class demonstrates standard Jackson deserialization. It contains private fields along with a no-argument constructor and public getter and setter methods. During deserialization, Jackson first creates an instance using the default constructor and then populates the fields using the setter methods. This is the most common and straightforward approach but requires mutable objects.
The ImmutableUser class illustrates deserialization using a multi-parameter constructor. Since the fields are marked as final and there are no setters, Jackson cannot use the default approach. Instead, the constructor is annotated with @JsonCreator, and each parameter is annotated with @JsonProperty to map JSON fields to constructor arguments. This approach is ideal for creating immutable objects.
The RecordUser is a Java record, which provides a concise way to define immutable data carriers. Records automatically generate a canonical constructor, accessor methods, and other utility methods. Jackson natively supports records and uses the generated constructor for deserialization without requiring additional annotations.
In the Main class, an ObjectMapper instance is created to handle the JSON processing. Three JSON strings are defined and deserialized into their respective classes. The first JSON string is mapped to DefaultUser, demonstrating setter-based population. The second is mapped to ImmutableUser, showcasing constructor-based deserialization. The third is mapped to RecordUser, highlighting record support. Finally, the program prints the deserialized values to verify that each approach works as expected.

2.2 Code Output

DefaultUser: John - 30 - ACTIVE
ImmutableUser: Alice - 25
RecordUser: Bob - 40

The output shows the successful deserialization of three different JSON inputs into their respective Java representations using different Jackson techniques. Each line corresponds to a specific deserialization strategy used in the program.

In the first case, the JSON string containing name, age, and status is deserialized into the DefaultUser class. Jackson invokes the default constructor and then sets each field using the setter methods. The status value “active” is passed to the enum’s @JsonCreator method, which converts it to uppercase and maps it to ACTIVE.
In the second case, the JSON is deserialized into the ImmutableUser class. Since the class does not have a default constructor or setters, Jackson uses the constructor annotated with @JsonCreator. The @JsonProperty annotations ensure that the JSON fields correctly map to the constructor parameters, allowing the object to be created with initialized final fields.
In the third case, the JSON is deserialized into the RecordUser record. Jackson automatically detects the record structure and uses its canonical constructor to populate the fields. No additional annotations or configuration are required, making this approach concise and modern.

Overall, the output confirms that Jackson can handle mutable objects, immutable classes with multi-parameter constructors, and Java records seamlessly, while also supporting customized enum deserialization logic.

3. Conclusion

Jackson provides flexible ways to deserialize JSON into Java objects, even when using parameterized constructors. While default deserialization works for mutable objects, @JsonCreator is essential for immutable designs. Modern Java features like records further simplify this process, and enums can be customized for robust parsing. Choosing the right approach depends on your object design and application requirements.

Tags

Probabilistic Data Structures: The Theory Behind Bloom Filters, HyperLogLog, and Count-Min Sketch

Eleftheria Drosopoulou — Fri, 17 Apr 2026 05:44:00 +0000

Software Development

Probabilistic Data Structures: The Theory Behind Bloom Filters, HyperLogLog, and Count-Min Sketch

When exact answers are too expensive, approximate answers with bounded error save the day — and the server budget.

Imagine trying to count every unique visitor to a website that receives 10 billion hits per day. Storing every single user ID would cost you gigabytes of RAM per server. Alternatively, you could use a structure that fits in 2.5 KB and gives you the right answer 98% of the time. That trade-off is exactly what probabilistic data structures are built for.

Before diving in, it helps to understand why these structures exist in the first place. In large-scale systems, three constraints regularly collide: data volume (too much to store exactly), memory budget (servers aren’t free), and latency requirements (answers must come back fast). When all three squeeze at once, exact data structures simply don’t scale. Probabilistic ones do — and they do it with mathematical guarantees on how wrong they can be.

In this article, we’ll walk through three of the most widely used probabilistic data structures: Bloom filters, HyperLogLog, and the Count-Min Sketch. We’ll explain not just what they do, but why the underlying math makes them trustworthy enough to deploy at Google, Facebook, Redis, and Cassandra scale.

A probabilistic data structure doesn’t give you wrong answers — it gives you approximate answers with quantifiable, bounded error. That’s a very different thing.

1. The Foundation: Why Hashing Makes This All Possible

All three structures rely on one core primitive: the hash function. A good hash function takes an arbitrary input and maps it to a fixed-size output in a way that appears random. Two critical properties make hashing useful for probabilistic structures:

First, uniformity: outputs are spread evenly across the output space. Second, determinism: the same input always produces the same output. Together, these properties let you encode information about a massive dataset into a compact bit array or counter table, then query it later with predictable accuracy.

The birthday paradox is worth understanding here, too. In a group of just 23 people, there’s a 50% chance that two share a birthday. Why? Because the number of possible pairings (253) grows much faster than the number of people. In hashing terms, collisions — two different inputs mapping to the same output — happen far sooner than intuition suggests. Probabilistic structures don’t eliminate collisions; instead, they account for them mathematically and use that accounting to bound error.

2. Bloom Filters: Fast Membership Testing with a Built-In Caveat

A Bloom filter answers one question: “Have I seen this item before?” It’s used everywhere — from checking whether a URL is malicious (Google Safe Browsing) to preventing duplicate writes in databases like Apache Cassandra.

How it works

A Bloom filter is simply a bit array of m bits, initially all set to zero, paired with k independent hash functions. When you insert an element, you run it through all k hash functions, each producing a position in the array, and set those bits to 1. To query whether an element exists, you check those same k positions — if all are 1, the element is probably in the set; if any is 0, it’s definitely not.

Notice the asymmetry there. That asymmetry is the entire point:

Query Result	What It Means	Can You Trust It?
All bits = 1	Element probably in set	Almost — false positives are possible
Any bit = 0	Element definitely not in set	100% — no false negatives ever

Furthermore, the false positive rate is not arbitrary — it’s precisely calculable. After inserting n elements into a filter with m bits and k hash functions, the probability of a false positive is:

P(false positive) ≈ (1 − e−kn/m)k

This formula tells you something powerful: you can tune the filter to whatever error rate you need simply by adjusting m and k. For a 1% false positive rate with 1 million elements, you need roughly 9.6 bits per element — about 1.2 MB total. That’s a remarkable trade-off for a membership test that would otherwise require storing all 1 million values.

Below, you can see how the false positive rate changes as you vary the number of hash functions for a fixed filter size. Notice how there’s an optimal number of hash functions — too few or too many, and error creeps up.

Bloom Filter — False Positive Rate vs. Number of Hash Functions

In practice, Redis’s Bloom filter module and many open-source libraries handle the math for you — you simply specify your desired false positive rate and expected element count, and the library sizes the structure accordingly. The key engineering insight is that Bloom filters never lie in the negative direction. If the filter says “no,” you can trust that absolutely.

3. HyperLogLog: Counting the Uncountable

Now consider a different problem: you want to count how many distinct values appear in a stream of data — unique users, unique search queries, unique product views. This is the cardinality estimation problem, and it’s surprisingly hard to solve exactly at scale.

The naïve solution is to maintain a hash set. But for billions of distinct elements, a hash set can require gigabytes of memory. HyperLogLog, introduced by Flajolet, Fusy, Gandouet, and Meunier in their landmark 2007 paper, achieves approximately 2% error using just 1.5 KB of memory — regardless of whether you’re counting a million or a trillion distinct elements.

The intuition: leading zeros as a signal

The insight comes from the probabilistic behaviour of hash functions. When you hash elements uniformly, the probability of seeing a hash value with k leading zeros is 2^−k. Therefore, if you observe a hash with 10 leading zeros, you can estimate you’ve seen roughly 2¹⁰ = 1,024 distinct elements.

That’s a rough estimator, but HyperLogLog improves it dramatically by using m parallel registers. Each incoming hash value is split: the first few bits select a register bucket, and the remaining bits are used to track the maximum leading-zero run seen in that bucket. At query time, a harmonic mean of all register estimates is computed. This technique — originally from the Flajolet-Martin algorithm — gives consistent, low-variance results across all ranges of cardinality.

Real-world deployment: Redis has shipped HyperLogLog as a native data type since version 2.8. A full billion-element cardinality estimate is stored in just 12 KB, with ±0.81% error. See the Redis HyperLogLog docs for implementation details.

The chart below illustrates HyperLogLog’s memory efficiency compared to exact counting across different cardinality ranges. As the cardinality grows, the gap between exact and approximate memory requirements widens dramatically.

Memory Usage: Exact HashSet vs. HyperLogLog

HyperLogLog uses fixed ~12 KB regardless of cardinality; HashSet grows linearly

It’s also worth noting that HyperLogLog is mergeable. You can run it independently on multiple servers and combine the results with a bitwise OR — a property that makes it ideal for distributed systems. Google used an extended variant, HyperLogLog++, in large-scale analytics pipelines for exactly this reason.

4. Count-Min Sketch: Frequency Estimation over Streaming Data

The third structure solves yet another problem: given a stream of events, how often has each item appeared? This is the heavy-hitter problem — finding the most frequent elements in a stream too large to store. It comes up in network intrusion detection (find the most frequent IP addresses), recommendation systems (find the most viewed items), and database query optimisation.

The Count-Min Sketch, introduced by Cormode and Muthukrishnan in 2005, uses a 2D array of counters with dimensions d × w, where d is the number of hash functions and w is the width of each row. Each incoming element is hashed by all d functions, and the corresponding counters in each row are incremented. To query an element’s frequency, you take the minimum across all d counter values — hence the name.

Why the minimum? Counters are inflated by collisions — multiple elements can increment the same counter. The minimum across independent rows gives the tightest upper bound on the true count, because at least one row is likely to have fewer collisions than the others.

Error guarantees and sizing

The Count-Min Sketch provides an overestimate guarantee: the estimated count is always ≥ the true count, never below. The error is bounded by ε × N, where ε is a user-specified error factor and N is the total number of insertions. Setting w = ⌈e/ε⌉ and d = ⌈ln(1/δ)⌉ guarantees that with probability 1−δ, the estimate exceeds the true count by at most εN.

Structure	Problem Solved	Error Type	Memory (typical)	Used In
Bloom Filter	Membership testing	False positives only	~10 bits per element	Cassandra, Chrome, BigTable
HyperLogLog	Cardinality estimation	~±2% relative error	1.5–12 KB fixed	Redis, Spark, BigQuery
Count-Min Sketch	Frequency estimation	Overestimates only	O(1/ε · log 1/δ) counters	Flink, Storm, network analytics

5. The Math That Ties It Together: Linearity of Expectation

One reason these structures work so reliably is a beautiful theorem in probability called linearity of expectation. It states that the expected value of a sum of random variables equals the sum of their individual expected values — regardless of whether those variables are correlated.

In the context of HyperLogLog’s harmonic mean across registers, this means that even though each register’s estimate is noisy, the average across m registers converges to the true cardinality predictably. You don’t need the registers to be independent; linearity of expectation holds either way. This is what makes the error bound provable rather than merely empirical.

Similarly, in the Count-Min Sketch, linearity of expectation explains why the minimum-of-sums estimator converges: even though each row accumulates collision noise, the expected collision rate is bounded by 1/w per hash function, and taking the minimum across d rows drives the expected error down exponentially.

6. Putting It into Practice: When to Use Each

Choosing the right structure depends on what question you’re asking. As a rule of thumb, think about it this way: if you want to test membership, reach for a Bloom filter. If you want to count distinct things, reach for HyperLogLog. If you want to estimate frequencies, reach for Count-Min Sketch. These aren’t overlapping tools — each is shaped to its problem.

There are, of course, limitations to keep in mind. Bloom filters are not deletable by default (though counting Bloom filters address this). HyperLogLog’s error grows slightly for very small cardinalities and requires bias correction for small sets. Count-Min Sketch only handles positive frequency updates — negative counters (deletions) require a different variant called the CMS with deletions or a conservative update scheme.

Still, for the vast majority of streaming and large-scale analytics use cases, these three structures cover the essential ground. Moreover, they compose well: for example, you can use a Bloom filter as a pre-filter before a Count-Min Sketch to avoid counting elements you’ve never seen before, reducing noise in the sketch.

A minimal Bloom filter in Python

The following Python snippet is self-contained and runnable on Python 3.6+ with no external dependencies. It demonstrates a basic Bloom filter using the hashlib standard library module:

# Requires Python 3.6+ — no external packages needed
import hashlib
import math

class BloomFilter:
    def __init__(self, n, p):
        # n = expected elements, p = false positive rate
        self.m = math.ceil(-n * math.log(p) / (math.log(2) ** 2))
        self.k = math.ceil((self.m / n) * math.log(2))
        self.bits = bytearray(self.m)

    def _positions(self, item):
        item = str(item).encode()
        for i in range(self.k):
            h = hashlib.sha256(item + i.to_bytes(2, 'big')).hexdigest()
            yield int(h, 16) % self.m

    def add(self, item):
        for pos in self._positions(item):
            self.bits[pos] = 1

    def __contains__(self, item):
        return all(self.bits[pos] for pos in self._positions(item))

# Example: 1 000 items, 1% false positive rate
bf = BloomFilter(n=1000, p=0.01)
bf.add("hello")
bf.add("world")
print("hello" in bf)   # True
print("missing" in bf) # False (no false negative possible)
print(f"Bit array: {bf.m} bits, {bf.k} hash functions")

To run this, save it as bloom.py and execute python bloom.py in your terminal. No pip installs needed. The class automatically computes optimal m and k from your target parameters.

7. What We’ve Learned

Let’s take a step back and recap what we’ve covered in this article:

Probabilistic data structures trade exactness for dramatic memory and speed gains, with mathematically bounded, predictable error — not random guesswork.
Bloom filters answer membership queries with zero false negatives. By tuning the number of bits and hash functions, you can achieve any desired false positive rate at roughly 10 bits per element.
HyperLogLog estimates cardinality — the count of distinct elements in a stream — with ~2% error using only kilobytes of memory, regardless of whether you’re counting millions or trillions of values.
Count-Min Sketch estimates item frequencies over streaming data, always overestimating (never underestimating) by a factor bounded by ε × N.
The underlying theory — hash uniformity, the birthday paradox, the Flajolet-Martin algorithm, and linearity of expectation — is what makes these error bounds provable and trustworthy in production systems.
All three structures are in active production use at major tech companies through tools like Redis, Apache Cassandra, Apache Spark, Google BigQuery, and Apache Flink.

Tags

Converting Between Byte Arrays and Short Arrays in Java

Omozegie Aziegbe — Thu, 16 Apr 2026 18:46:27 +0000

Core Java

Converting Between Byte Arrays and Short Arrays in Java

This article demonstrates how to convert a byte array to a short array and convert a short array back to a byte array in Java using the ByteBuffer class. The approach shown here provides an efficient way to handle binary data transformation while ensuring correct byte ordering and avoiding manual bit manipulation.

1. Understanding the Conversion Approach

A byte represents eight bits, while a short represents sixteen bits. This means each short value is formed from two consecutive bytes. The ByteBuffer class in Java simplifies this conversion by allowing a byte array to be viewed as a short buffer. This enables direct reading and writing of short values without manual shifting operations. The correct byte order must be specified to ensure consistent results across different systems.

2. Converting Byte Array to Short Array

The code below shows how to convert a byte array into a short array using ByteBuffer with little endian ordering.

public class ByteToShortConverter {

    public static short[] convertBytesToShorts(byte[] inputBytes) {
        if (inputBytes == null || inputBytes.length % 2 != 0) {
            throw new IllegalArgumentException("Input byte array must not be null and must have even length");
        }

        short[] outputShorts = new short[inputBytes.length / 2];

        ByteBuffer.wrap(inputBytes)
                .order(ByteOrder.LITTLE_ENDIAN)
                .asShortBuffer()
                .get(outputShorts);

        return outputShorts;
    }
}

The code defines a utility method to convert a byte array to a short array. It validates that the input is not null and that its length is even, since each short is 2 bytes. A ByteBuffer is created by wrapping the input array and setting the byte order to LITTLE_ENDIAN. The buffer is then viewed as a short buffer, which allows the data to be directly read into a short array.

3. Converting Short Array to Byte Array

This section shows how to convert a short array back into a byte array using ByteBuffer with the same byte order.

public class ShortToByteConverter {

    public static byte[] convertShortsToBytes(short[] inputShorts) {
        if (inputShorts == null) {
            throw new IllegalArgumentException("Input short array must not be null");
        }

        byte[] outputBytes = new byte[inputShorts.length * 2];

        ByteBuffer.wrap(outputBytes)
                .order(ByteOrder.LITTLE_ENDIAN)
                .asShortBuffer()
                .put(inputShorts);

        return outputBytes;
    }
}

The method converts a short array into a byte array by first allocating a byte array that is twice the size of the short array. A ByteBuffer wraps the output array and is configured to use little-endian ordering. The short buffer view of the ByteBuffer allows the short values to be written directly into the underlying byte array. This ensures that each short is correctly split into two bytes.

Below is an application that demonstrates both conversion directions and verifies the results.

public class Application {

    public static void main(String[] args) {
        byte[] initialBytes = new byte[]{0x01, 0x00, 0x02, 0x00, 0x03, 0x00};

        short[] convertedShorts = ByteToShortConverter.convertBytesToShorts(initialBytes);
        byte[] finalBytes = ShortToByteConverter.convertShortsToBytes(convertedShorts);

        IO.println("Initial byte array: " + Arrays.toString(initialBytes));
        IO.println("Converted short array: " + Arrays.toString(convertedShorts));
        IO.println("Final byte array: " + Arrays.toString(finalBytes));
    }
}

Output

Initial byte array: [1, 0, 2, 0, 3, 0]
Converted short array: [1, 2, 3]
Final byte array: [1, 0, 2, 0, 3, 0]

The printed output confirms that the original byte array and the final reconstructed byte array are identical, demonstrating that the conversion process preserves data integrity.

4. Endianness Considerations

Endianness defines the order in which bytes are interpreted when forming larger data types. This implementation uses little-endian order, meaning the least significant byte is processed first. Both conversion methods must use the same byte order to ensure consistent and correct results. Changing the byte order requires updating both methods accordingly.

5. Conclusion

In this article, the process of converting between byte arrays and short arrays in Java was demonstrated using the ByteBuffer class. The examples showed how to convert a byte array into a short array and how to reverse the process back into a byte array while maintaining data integrity.

6. Download the Source Code

This article explained how to convert between byte arrays and short arrays in Java.

Download
You can download the full source code of this example here: convert byte to short array in Java

Tags

Understanding Database Triggers

Yatin Batra — Thu, 16 Apr 2026 18:33:34 +0000

Software Development

Understanding Database Triggers

Database triggers are powerful mechanisms that allow you to automatically execute predefined logic in response to specific events occurring in a database. They are widely used in enterprise systems to enforce business rules, maintain data integrity, automate workflows, and audit changes without requiring explicit calls from application code. In PostgreSQL, triggers are flexible, robust, and tightly integrated with procedural languages like PL/pgSQL. Let us delve into understanding what are database triggers practical intro with PostgreSQL examples, exploring how they work, why they are important, and how they can be effectively used in real-world scenarios.

1. Trigger Definition and Overview

A Database Trigger is a special kind of stored procedure that automatically runs when a specific event occurs on a table or view. Unlike regular functions that must be explicitly invoked, triggers are executed implicitly by the database engine, making them a powerful tool for enforcing rules, maintaining data consistency, and automating repetitive tasks directly at the data layer. Triggers help ensure that critical logic is consistently applied regardless of how the data is modified—whether through applications, scripts, or manual queries.

1.1 Common Trigger Events in Databases

INSERT – Fired when new rows are added to a table
UPDATE – Fired when existing rows are modified
DELETE – Fired when rows are removed
TRUNCATE – Fired when all rows in a table are quickly removed

These events define the points at which a trigger can intervene in the lifecycle of data changes, enabling fine-grained control over database operations.

1.2 Internal Working of PostgreSQL Triggers

A trigger in PostgreSQL consists of two main components: a trigger function, which contains the logic to execute, and a trigger definition, which specifies when and how the function runs. The workflow operates as follows: when an event occurs (such as an INSERT on a table), PostgreSQL checks for any triggers defined on that table, executes the matching triggers automatically in the defined order, and then the associated trigger function processes the data accordingly. Depending on the trigger type, this execution can happen either before or after the actual database operation, allowing developers to intercept, validate, modify, or react to changes seamlessly.

1.3 Types of Triggers in PostgreSQL

1.3.1 BEFORE Trigger (Pre-Execution Logic)

Executes before the operation is performed, and is typically used to validate data and modify incoming values before they are written to the database. BEFORE triggers are especially useful for enforcing constraints, normalizing data formats, setting default values, or rejecting invalid transactions by raising exceptions.

1.3.2 AFTER Trigger (Post-Execution Actions)

Executes after the operation is completed, and is commonly used for logging changes and sending notifications based on the completed database action. AFTER triggers are ideal when the operation must succeed first, such as writing audit logs, updating related tables, or triggering downstream processes.

1.3.3 INSTEAD OF Trigger (View-Based Operations)

Used primarily with views to replace the default operation. Since views do not always support direct data modification, INSTEAD OF triggers allow developers to define custom logic that determines how INSERT, UPDATE, or DELETE operations should be handled. This is particularly useful for making complex or joined views behave like updatable tables.

1.4 Row-Level vs Statement-Level Triggers

PostgreSQL allows triggers to be executed at two different granularities: row-level and statement-level. Understanding this distinction is crucial for both performance and correctness.

1.4.1 Row-Level Triggers (FOR EACH ROW)

Row-level triggers execute once for every affected row in a table operation.

Triggered individually for each row being inserted, updated, or deleted
Access to OLD and NEW row values
Ideal for validations, auditing, and row-specific transformations

CREATE TRIGGER row_level_trigger
BEFORE UPDATE ON employees
FOR EACH ROW
EXECUTE FUNCTION log_salary_update();

If an UPDATE affects 100 rows, the trigger runs 100 times.

1.4.2 Statement-Level Triggers (FOR EACH STATEMENT)

Statement-level triggers execute once per SQL statement, regardless of how many rows are affected.

Triggered only once per operation (INSERT/UPDATE/DELETE)
No direct access to individual row values (OLD/NEW not available)
Best suited for logging, batching, or aggregate-level operations

CREATE TRIGGER statement_level_trigger
AFTER UPDATE ON employees
FOR EACH STATEMENT
EXECUTE FUNCTION log_update_summary();

If an UPDATE affects 100 rows, the trigger runs only once.

1.4.3 Key Differences

Aspect	Row-Level Trigger	Statement-Level Trigger
Execution	Once per row	Once per statement
Access to data	`OLD` and `NEW` available	Not directly available
Performance	Slower for bulk operations	More efficient for large datasets
Use cases	Auditing, validation, transformations	Logging, summaries, batch operations

1.4.4 When to Use Which?

Use row-level triggers when logic depends on individual row values.
Use statement-level triggers when you only care about the operation as a whole.
For bulk updates, prefer statement-level triggers to avoid performance overhead.

1.5 When to Use Database Triggers (Best Use Cases)

Triggers are particularly useful in scenarios where logic must be enforced consistently at the database level, regardless of how the data is accessed or modified. They help centralize critical operations and reduce dependency on application code.

Enforcing business rules at the database level – Ensure constraints and validations are always applied, even if multiple applications interact with the database.
Auditing changes (who updated what and when) – Automatically track modifications by capturing old and new values along with timestamps for compliance and traceability.
Maintaining derived or aggregate data – Keep summary tables, counters, or calculated fields in sync without manual intervention.
Automating repetitive logic – Eliminate boilerplate operations such as setting timestamps, default values, or status flags.
Ensuring data consistency across related tables – Automatically propagate changes or enforce referential logic beyond standard constraints.
Implementing lightweight workflows – Trigger secondary actions like inserting into queue tables or event logs for downstream processing.

1.6 When to Avoid Database Triggers (Limitations and Trade-offs)

While powerful, triggers should be used judiciously. Overusing them or embedding complex logic can lead to maintenance challenges and unexpected behavior.

Logic becomes too complex and hard to debug – Triggers execute implicitly, making it difficult to trace execution flow and diagnose issues.
Performance is critical and triggers introduce latency – Additional processing on each operation can impact throughput, especially on high-traffic tables.
Business logic is better handled at the application layer – Complex workflows, integrations, or user-specific rules are often clearer and more maintainable in application code.
Hidden side effects make the system harder to understand – Implicit execution can lead to unexpected outcomes if developers are unaware of existing triggers.
Bulk operations or large data migrations – Triggers can significantly slow down batch processing unless explicitly disabled.
Tight coupling between database logic and schema – Changes to table structures may require careful updates to dependent triggers.

1.7 Managing Triggers in PostgreSQL

Managing triggers in PostgreSQL involves creating, viewing, modifying, enabling, and disabling them as needed. Proper trigger management is essential to ensure maintainability, performance, and clarity in database operations.

1.7.1 Creating Triggers

The following statement creates a trigger that executes before an INSERT operation on a specified table. The trigger is defined to run for each row affected by the operation and invokes a predefined trigger function.

CREATE TRIGGER trigger_name
BEFORE INSERT ON table_name
FOR EACH ROW
EXECUTE FUNCTION function_name();

1.7.2 Viewing Existing Triggers

To list all triggers defined in the database, you can query the information schema. This helps in auditing and understanding existing trigger configurations.

SELECT * FROM information_schema.triggers;

1.7.3 Dropping Triggers

If a trigger is no longer needed, it can be removed using the DROP TRIGGER statement. This permanently deletes the trigger from the specified table.

DROP TRIGGER trigger_name ON table_name;

1.7.4 Enabling and Disabling Triggers

Triggers can be temporarily disabled or re-enabled without being deleted. This is particularly useful during bulk data operations or migrations where trigger execution may not be desirable.

ALTER TABLE table_name DISABLE TRIGGER trigger_name;
ALTER TABLE table_name ENABLE TRIGGER trigger_name;

2. PostgreSQL Triggers Code Example

2.1 Environment Setup: Running PostgreSQL with Docker

To get started quickly with PostgreSQL for this example, you can run it using Docker, which provides an isolated and reproducible environment without requiring a local installation. First, ensure Docker is installed on your system, then pull and run the official PostgreSQL image using a command such as docker run --name postgres-triggers -e POSTGRES_USER=admin -e POSTGRES_PASSWORD=admin -e POSTGRES_DB=testdb -p 5432:5432 -d postgres, which creates a container with a default user, password, and database while exposing port 5432 for local access. Once the container is running, you can connect to PostgreSQL using tools like psql, DBeaver, or pgAdmin by providing the host as localhost, port 5432, and the configured credentials.

After connecting, you can create tables, define trigger functions, and execute all the SQL examples provided in this tutorial. Using Docker ensures consistency across environments, simplifies setup, and allows you to easily start, stop, or reset your database instance as needed during development and testing.

2.2 End-to-End Trigger Implementation Example

### Step 1: Create a Table
CREATE TABLE employees (
    id SERIAL PRIMARY KEY,
    name TEXT,
    salary NUMERIC,
    updated_at TIMESTAMP
);

### Step 2: Create an Audit Table
CREATE TABLE employee_audit (
    audit_id SERIAL PRIMARY KEY,
    employee_id INT,
    old_salary NUMERIC,
    new_salary NUMERIC,
    changed_at TIMESTAMP
);

### Step 3: Create Trigger Function
CREATE OR REPLACE FUNCTION log_salary_update()
RETURNS TRIGGER AS $$
BEGIN
    IF NEW.salary <> OLD.salary THEN
        INSERT INTO employee_audit(employee_id, old_salary, new_salary, changed_at)
        VALUES (OLD.id, OLD.salary, NEW.salary, NOW());
    END IF;
    
    NEW.updated_at = NOW();
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

### Step 4: Create Trigger
CREATE TRIGGER salary_update_trigger
BEFORE UPDATE ON employees
FOR EACH ROW
EXECUTE FUNCTION log_salary_update();

The code demonstrates a complete PostgreSQL trigger setup: first, an employees table is created to store employee details including salary and a timestamp field, followed by an employee_audit table designed to log salary changes for auditing purposes; next, a trigger function log_salary_update() is defined using PL/pgSQL, which checks if the salary has changed during an update by comparing OLD and NEW values, and if so, inserts a record into the audit table capturing the employee ID, old salary, new salary, and the change timestamp, while also updating the updated_at field automatically; finally, a trigger named salary_update_trigger is created to execute this function before any update on the employees table for each row, ensuring that all salary changes are tracked and timestamps are consistently maintained without requiring manual intervention.

2.3 Testing Trigger Behavior

### Insert Data
INSERT INTO employees(name, salary) VALUES ('Alice', 50000);

### Update Salary
UPDATE employees SET salary = 60000 WHERE name = 'Alice';

The above SQL statements demonstrate how the trigger works in practice: first, a new record is inserted into the employees table for an employee named Alice with an initial salary, and then an update operation modifies her salary; when the update statement is executed, the previously defined trigger automatically fires before the update, compares the old and new salary values, logs the change into the employee_audit table if the salary has been modified, and updates the timestamp field, thereby ensuring that all salary changes are tracked seamlessly without requiring any additional manual logic in the application.

2.4 Trigger Execution Output and Analysis

### Employees Table

| id | name  | salary | updated_at          |
| -- | -- |  | - |
| 1  | Alice | 60000  | 2026-04-10 10:00:00 |

### Employee Audit Table

| audit_id | employee_id | old_salary | new_salary | changed_at          |
| -- | -- | - | - | - |
| 1        | 1           | 50000      | 60000      | 2026-04-10 10:00:00 |

The output illustrates the effect of the trigger after executing the insert and update operations: in the employees table, Alice’s salary has been successfully updated from 50000 to 60000, and the updated_at column reflects the timestamp automatically set by the trigger function during the update; simultaneously, the employee_audit table contains a new record capturing the change, including the employee ID, old salary, new salary, and the exact time of modification, demonstrating how the trigger ensures automatic auditing of salary changes without requiring any explicit logging logic in the application.

3. Conclusion

Database triggers in PostgreSQL provide a powerful way to automate logic and enforce rules directly at the data layer. They are especially useful for auditing, validation, and maintaining consistency across operations. However, they should be used thoughtfully. Overusing triggers or embedding complex logic within them can make systems harder to maintain and debug. A balanced approach—combining triggers with application-level logic—is often the most effective strategy. With a clear understanding of how triggers work and when to use them, you can design more robust and reliable database systems.

Tags

[DEALS] Microsoft Visual Studio Professional 2022 + The Premium Learn to Code Certification Bundle (98% off) & Other Deals Up To 98% Off

Java Code Geeks — Thu, 16 Apr 2026 10:30:30 +0000

Meta JCG

[DEALS] Microsoft Visual Studio Professional 2022 + The Premium Learn to Code Certification Bundle (98% off) & Other Deals Up To 98% Off

Hello fellow geeks,

Fresh offers await you on our Deals store, please have a look!

Microsoft Visual Studio Professional 2022 + The Premium Learn to Code Certification Bundle
(98% off)

Ending soon // by Java Code Geeks

Elevate Your Coding Prowess Today! With Top-Rated Courses & Lifetime Access to MS Visual Pro 2022

Surfshark VPN Starter Plan: 3-Yr Subscription
(80% off)

The 2026 Complete Offensive Cyber Security Bundle
(83% off)

iProVPN: 5-Year Subscription
(94% off)

Internxt Cloud Storage: Lifetime Subscription (50TB)
(91% off)

Cleaner Kit for iOS Premium Plan: Lifetime Subscription
(80% off)

Drime Secure Cloud Storage: Lifetime Subscription
(49% off)

AdGuard VPN + Ad Blocker Family Security Suite
(90% off)

Sterling Stock Picker: Lifetime Subscription
(85% off)

Babbel Language Learning: Lifetime Subscription (All Languages)
(61% off)

The Premium Learn to Code Certification Bundle
(97% off)

Tags

Post-Quantum Cryptography in Java: What the NIST Standards Mean for Your TLS, JWT, and Key Management Code

Eleftheria Drosopoulou — Thu, 16 Apr 2026 05:45:00 +0000

Core Java

Post-Quantum Cryptography in Java: What the NIST Standards Mean for Your TLS, JWT, and Key Management Code

In August 2024, NIST finalized the world’s first post-quantum cryptography standards. JDK 24 and 25 have already begun shipping the new algorithms. If you run Java services that handle authentication, encrypted transport, or long-lived secrets, this transition affects you — and the window to act is narrower than most teams realize.

For most of software history, breaking RSA-2048 or ECDH key exchange required either a room-sized classical computer running for billions of years, or simply being fictional. Quantum computers have changed that calculus — not today, but on a timeline that is now concretely measurable. Shor’s algorithm, running on a sufficiently large fault-tolerant quantum computer, reduces RSA and elliptic curve key exchange from computationally infeasible to a matter of hours. The question is no longer whether this is theoretically possible — it is a question of when.

That “when” is what drove NIST to spend eight years evaluating 69 candidate algorithms and then, in August 2024, publish FIPS 203, FIPS 204, and FIPS 205 as finalized standards. For Java developers, the practical impact falls across three critical areas: TLS handshakes, JWT signing and verification, and key generation and storage. This article walks through each one, explains what the new algorithms are and why they exist, and shows exactly what you need to change in your code.

What this article covers

Why quantum computers break RSA and ECDH — and why symmetric AES-256 is mostly fine
The three finalized NIST PQC standards and what each one replaces in your Java stack
JDK 24 and 25 support status: what is in the JCA provider today and what requires BouncyCastle
Concrete code changes for TLS configuration, JWT signing, and KeyStore / KeyGenerator usage
The “harvest now, decrypt later” threat model and why urgency is higher than most teams assume
A migration checklist and algorithm recommendation table for 2026

1. Why Quantum Computers Break the Algorithms You Are Currently Using

The security of RSA, Diffie-Hellman, and elliptic curve cryptography all rest on mathematical problems that are hard for classical computers — specifically, integer factorisation and the discrete logarithm problem. Shor’s algorithm, published in 1994, solves both problems in polynomial time on a quantum computer. That means a quantum computer with enough logical qubits could, in principle, factor a 2048-bit RSA modulus or solve an elliptic curve discrete log in hours rather than geological time.

Importantly, symmetric encryption is not equally vulnerable. Grover’s algorithm offers a quantum speedup for searching unsorted data — effectively halving the security of symmetric keys. AES-128 drops to approximately 64 bits of quantum security; AES-256 drops to 128 bits, which remains strong by any practical standard. So the asymmetric algorithms you use for key exchange and digital signatures are the critical exposure surface — not your bulk data encryption.

Nation-state adversaries and well-funded groups are believed to be recording encrypted TLS traffic today with the explicit intention of decrypting it once a cryptographically relevant quantum computer exists. If any data you transmit today must remain confidential for more than 5–10 years — healthcare records, financial contracts, classified communications — your current RSA/ECDH TLS sessions are already at risk. This threat model is sometimes called HNDL (Harvest Now, Decrypt Later) and it is the primary driver of the urgency behind the NIST timeline.

The following timeline places the NIST process in context so you can calibrate your own migration urgency:

2016

NIST opens the Post-Quantum Cryptography Standardization process. 69 algorithms submitted from researchers worldwide.

2022

NIST announces four finalists: CRYSTALS-Kyber (KEM), CRYSTALS-Dilithium, FALCON, and SPHINCS+ (signatures).

August 2024

FIPS 203 (ML-KEM / Kyber), FIPS 204 (ML-DSA / Dilithium), and FIPS 205 (SLH-DSA / SPHINCS+) finalized. These are the first post-quantum cryptographic standards in history.

2025 — JDK 24 / 25

JEP 496 (Quantum-Resistant Module-Lattice-Based Key Encapsulation) and JEP 497 (Quantum-Resistant Module-Lattice-Based Digital Signatures) integrated into the JCA provider in JDK 24 and 25 as preview / standard features.

2030 (estimated)

NIST plans to begin deprecating classical algorithms for federal use. Most compliance frameworks (FedRAMP, CMMC, PCI-DSS) expected to follow with mandatory PQC timelines.

2035 (estimated)

Cryptographically relevant quantum computers (CRQCs) possible according to multiple national intelligence assessments, including the US NSA and UK NCSC. Classical asymmetric algorithms considered at risk.

Security bit levels: classical vs post-quantum algorithms under quantum attack

Effective security in bits when attacked by a cryptographically relevant quantum computer (Grover / Shor). Higher is better. Source: NIST SP 800-57, FIPS 203–205. Quantum security estimates use Grover’s algorithm for symmetric and Shor’s algorithm for asymmetric schemes. PQC estimates based on NIST parameter set specifications.

2. The Three NIST Standards: What Each One Does and What It Replaces

Before diving into Java code, it is worth being precise about what each standard actually is — because the naming is inconsistent across documentation and the algorithms serve distinct purposes.

FIPS Standard	Algorithm name	Origin name	Type	Replaces	JDK 25 support
FIPS 203	ML-KEM	CRYSTALS-Kyber	Key Encapsulation Mechanism (KEM)	RSA-OAEP, ECDH key exchange in TLS	JEP 496 — standard
FIPS 204	ML-DSA	CRYSTALS-Dilithium	Digital signature	RSA-PSS, ECDSA in JWT, TLS cert signing	JEP 497 — standard
FIPS 205	SLH-DSA	SPHINCS+	Stateless hash-based signature	RSA-PSS, ECDSA (conservative alternative)	BouncyCastle 1.80+
FIPS 206 (draft)	FN-DSA	FALCON	Digital signature (compact)	ECDSA where small signature size matters	BouncyCastle 1.80+

The two algorithms with first-class JDK support — ML-KEM and ML-DSA — are both based on the hardness of the Module Learning With Errors (MLWE) problem, which is believed to resist attacks from both classical and quantum computers. ML-KEM handles key encapsulation (the process of establishing a shared secret over an untrusted channel, used in TLS), while ML-DSA handles digital signatures (used in JWT signing, TLS certificate verification, and code signing).

SLH-DSA (SPHINCS+) is the conservative choice if you distrust lattice-based cryptography — it is based entirely on hash functions, which have a longer and better-understood security history. Its downside is signature size: an SLH-DSA signature is roughly 8–50 KB depending on the parameter set, versus 2–4 KB for ML-DSA. That matters for JWT tokens in HTTP headers or for TLS certificate chains. Still, for signing artifacts, firmware, or code — where size is less critical — SLH-DSA is an excellent choice.

3. JDK 24 and 25 Support: What Is in the Box

JEP 496 landed in JDK 24 as a preview feature and was finalized in JDK 25, adding ML-KEM to the JCA provider under the algorithm name "ML-KEM" with parameter sets ML-KEM-512, ML-KEM-768, and ML-KEM-1024. JEP 497 follows the same track, adding ML-DSA with parameter sets ML-DSA-44, ML-DSA-65, and ML-DSA-87.

Critically, however, TLS 1.3 integration is not yet complete in the standard JDK TLS provider (JSSE). The SunJSSE provider does not yet support ML-KEM as a named group for TLS key exchange by default. You can negotiate it experimentally via the jdk.tls.namedGroups system property, but for production-grade hybrid TLS (a pattern we cover below), BouncyCastle’s JSSE provider is the more reliable path for now.

PQC feature availability by Java version

Support level across JDK versions for each algorithm and integration point. Data from OpenJDK JEP tracker and BouncyCastle changelog. Sources: JEP 496, JEP 497, BouncyCastle release notes.

For teams on JDK 17 or 21 (the current LTS releases as of writing), the practical path to PQC today runs through BouncyCastle 1.80+, which implements FIPS 203, 204, and 205 and integrates cleanly with the standard JCA KeyPairGenerator, Signature, and KeyGenerator APIs. The same code runs on JDK 25 with the native provider once you remove the BouncyCastle provider registration — the API surface is identical.

4. TLS: Hybrid Key Exchange and What to Configure

The recommended migration strategy for TLS is not to rip out ECDH and replace it wholesale with ML-KEM overnight. Instead, the cryptographic community — including the IETF TLS hybrid design draft — recommends a hybrid key exchange approach: combine a classical algorithm (ECDH P-256 or X25519) with a post-quantum KEM (ML-KEM-768) such that the resulting shared secret is secure unless both algorithms are simultaneously broken. This gives you quantum resistance against HNDL attacks while maintaining backward compatibility with classical infrastructure.

In practice, hybrid TLS in Java today requires BouncyCastle’s JSSE provider. Below is a working configuration using Spring Boot 3.x with the BC-JSSE provider, enabling the X25519MLKEM768 hybrid named group — the same group now supported in Chrome and Firefox:

<!-- pom.xml — add BouncyCastle TLS and FIPS providers -->
<dependency>
    <groupId>org.bouncycastle</groupId>
    <artifactId>bcprov-jdk18on</artifactId>
    <version>1.80</version>
</dependency>
<dependency>
    <groupId>org.bouncycastle</groupId>
    <artifactId>bctls-jdk18on</artifactId>
    <version>1.80</version>
</dependency>

import org.bouncycastle.jsse.provider.BouncyCastleJsseProvider;
import org.bouncycastle.jce.provider.BouncyCastleProvider;
import javax.net.ssl.*;
import java.security.Security;

public class PQCTlsConfig {

    public static SSLContext buildHybridTlsContext() throws Exception {
        // Register BC providers at the front of the provider list
        Security.insertProviderAt(new BouncyCastleProvider(), 1);
        Security.insertProviderAt(new BouncyCastleJsseProvider(), 2);

        SSLContext ctx = SSLContext.getInstance("TLSv1.3", "BCJSSE");

        // KeyManager and TrustManager loaded from your existing KeyStore
        KeyManagerFactory kmf = KeyManagerFactory.getInstance("PKIX", "BCJSSE");
        TrustManagerFactory tmf = TrustManagerFactory.getInstance("PKIX", "BCJSSE");
        // kmf.init(keyStore, password);  tmf.init(trustStore);
        ctx.init(kmf.getKeyManagers(), tmf.getTrustManagers(), null);

        // Enable the hybrid X25519 + ML-KEM-768 named group for key exchange
        SSLParameters params = ctx.getDefaultSSLParameters();
        params.setNamedGroups(new String[]{
            "X25519MLKEM768",   // hybrid PQC (recommended for transition)
            "x25519",           // classical fallback
            "secp256r1"         // classical fallback
        });
        ctx.getDefaultSSLParameters().setNamedGroups(params.getNamedGroups());

        return ctx;
    }
}

TLS has two distinct cryptographic operations: key exchange (establishing the session secret — this is where ML-KEM applies) and certificate signature verification (authenticating the server’s identity — this is where ML-DSA would apply). Today’s recommendation is to upgrade key exchange to hybrid PQC immediately, but continue using classical ECDSA or RSA for certificate signatures until browser trust stores and intermediate CA infrastructure catches up to ML-DSA certificates.

5. JWT Signing: ML-DSA Keys and What Changes in Your Token Pipeline

JSON Web Tokens signed with RS256 (RSA + SHA-256) or ES256 (ECDSA + P-256) are quantum-vulnerable — Shor’s algorithm can recover the private key from any captured signature. The post-quantum replacement is ML-DSA, which produces a different key type, a different signature format, and larger tokens.

The first thing to understand is that no major JWT library — Nimbus JOSE+JWT, jjwt, Auth0 java-jwt — natively supports ML-DSA algorithm identifiers yet, because the IANA “JSON Web Algorithms” registry has not yet assigned official algorithm names for FIPS 204. IETF drafts are in progress (draft-ietf-cose-dilithium), and the expected registered name is "ML-DSA-65". In the interim, you can use custom algorithm identifiers with Nimbus JOSE+JWT’s extensible algorithm framework:

import com.nimbusds.jose.*;
import com.nimbusds.jose.crypto.*;
import com.nimbusds.jwt.*;
import org.bouncycastle.jce.provider.BouncyCastleProvider;
import org.bouncycastle.pqc.jcajce.provider.BouncyCastlePQCProvider;
import java.security.*;
import java.util.Date;

public class PQCJwtExample {

    static {
        Security.addProvider(new BouncyCastleProvider());
        Security.addProvider(new BouncyCastlePQCProvider());
    }

    // Generate an ML-DSA-65 key pair using BouncyCastle (JDK 17/21 compatible)
    public static KeyPair generateMlDsaKeyPair() throws Exception {
        KeyPairGenerator kpg = KeyPairGenerator.getInstance("ML-DSA", "BCPQC");
        // ML-DSA-65 offers 128-bit quantum security — the recommended general-purpose parameter set
        kpg.initialize(new org.bouncycastle.pqc.jcajce.spec.MLDSAParameterSpec(
            org.bouncycastle.pqc.jcajce.spec.MLDSAParameterSpec.ml_dsa_65
        ));
        return kpg.generateKeyPair();
    }

    // Sign a JWT with ML-DSA-65 using a custom JWS algorithm identifier
    // Note: "ML-DSA-65" as alg header is a placeholder until IANA registration completes
    public static String signToken(KeyPair keyPair, String subject) throws Exception {
        JWSSigner signer = new Ed25519Signer((java.security.interfaces.EdECPrivateKey) null) {
            // Custom signer delegating to ML-DSA via JCA Signature API
            @Override
            public Base64URL sign(JWSHeader header, byte[] signingInput) throws JOSEException {
                try {
                    Signature sig = Signature.getInstance("ML-DSA", "BCPQC");
                    sig.initSign(keyPair.getPrivate());
                    sig.update(signingInput);
                    return Base64URL.encode(sig.sign());
                } catch (Exception e) { throw new JOSEException("ML-DSA signing failed", e); }
            }
            @Override
            public Set<JWSAlgorithm> supportedJWSAlgorithms() {
                return Collections.singleton(new JWSAlgorithm("ML-DSA-65"));
            }
        };

        JWSHeader header = new JWSHeader.Builder(new JWSAlgorithm("ML-DSA-65"))
            .type(JOSEObjectType.JWT).build();

        JWTClaimsSet claims = new JWTClaimsSet.Builder()
            .subject(subject)
            .issuer("https://auth.example.com")
            .expirationTime(new Date(System.currentTimeMillis() + 3_600_000))
            .build();

        SignedJWT jwt = new SignedJWT(header, claims);
        jwt.sign(signer);
        return jwt.serialize();
    }
}

An ML-DSA-65 signature is approximately 3,293 bytes, compared to 64 bytes for ES256 (ECDSA P-256). This has a direct impact on HTTP Authorization header sizes, cookie storage limits, and any system that stores or indexes JWT tokens. Plan for roughly a 4–5× increase in token payload size when using ML-DSA. If that is unacceptable, FN-DSA (FALCON) produces ~1,280-byte signatures — but at the cost of a more complex key generation procedure and no current IANA registration.

Signature and public key sizes: classical vs post-quantum algorithms (bytes)

Directly impacts JWT token sizes, TLS certificate chain sizes, and storage requirements. Logarithmic scale — each gridline is 10×. Sizes from FIPS 203, 204, 205 specifications and FALCON specification. Logarithmic scale used due to large range.

6. Key Management: KeyStore, KeyGenerator, and Storage Implications

Key management is where the practical friction of PQC migration is highest. The standard Java KeyStore formats — JKS, PKCS12, and JCE — support any key type that implements the java.security.Key interface, so ML-KEM and ML-DSA keys can be stored in an existing PKCS12 keystore without format changes. However, hardware security modules (HSMs), cloud KMS services, and PKCS#11 providers are a different story.

As of April 2026, most HSMs do not yet support ML-KEM or ML-DSA natively. AWS KMS, Google Cloud KMS, and Azure Key Vault have all announced PQC roadmaps but have not shipped GA support. The practical consequence is that for applications relying on an HSM-backed keystore, you will need to either generate and store PQC keys in a software keystore (with appropriate wrapping or protection strategy) or wait for HSM vendor support.

import org.bouncycastle.pqc.jcajce.provider.BouncyCastlePQCProvider;
import org.bouncycastle.pqc.jcajce.spec.MLKEMParameterSpec;
import java.security.*;
import java.security.KeyStore.*;
import java.io.*;

public class PQCKeyManagement {

    static {
        Security.addProvider(new BouncyCastleProvider());
        Security.addProvider(new BouncyCastlePQCProvider());
    }

    // Generate ML-KEM-768 key pair — recommended for general-purpose key encapsulation
    public static KeyPair generateMlKemKeyPair() throws Exception {
        KeyPairGenerator kpg = KeyPairGenerator.getInstance("ML-KEM", "BCPQC");
        kpg.initialize(MLKEMParameterSpec.ml_kem_768);
        return kpg.generateKeyPair();
    }

    // Store PQC keys in a standard PKCS12 keystore — no format change required
    public static void storePqcKeyPair(KeyPair keyPair, char[] password,
                                        String alias, String outputPath) throws Exception {
        KeyStore ks = KeyStore.getInstance("PKCS12");
        ks.load(null, password); // create new keystore

        // Self-signed certificate wrapper is needed for PKCS12 private key entries
        // In production, get this from your CA with an ML-DSA subject key
        java.security.cert.Certificate[] chain = generateSelfSignedCert(keyPair);

        ks.setKeyEntry(alias, keyPair.getPrivate(), password, chain);

        try (FileOutputStream fos = new FileOutputStream(outputPath)) {
            ks.store(fos, password);
        }
        System.out.println("Stored ML-KEM-768 key pair to: " + outputPath);
    }

    // Retrieve and use the stored ML-KEM key pair
    public static KeyPair loadPqcKeyPair(String keystorePath,
                                          char[] password, String alias) throws Exception {
        KeyStore ks = KeyStore.getInstance("PKCS12");
        try (FileInputStream fis = new FileInputStream(keystorePath)) {
            ks.load(fis, password);
        }
        PrivateKey privateKey = (PrivateKey) ks.getKey(alias, password);
        PublicKey publicKey   = ks.getCertificate(alias).getPublicKey();
        return new KeyPair(publicKey, privateKey);
    }

    private static java.security.cert.Certificate[] generateSelfSignedCert(KeyPair kp)
            throws Exception {
        // Use BouncyCastle X509 certificate generator for ML-DSA/ML-KEM subject keys
        // Omitted for brevity — see BouncyCastle X509v3CertificateBuilder docs
        return new java.security.cert.Certificate[]{};
    }
}

7. What Breaks in Your Existing Code and How to Fix It

Beyond the specific code changes above, there are several existing patterns that break or require adjustment when you introduce PQC algorithms. Each one is straightforward to address once you know to look for it.

Existing pattern	Problem	Fix
Hardcoded algorithm strings like `"RSA"`, `"EC"`	Will not resolve to PQC algorithms	Replace with `"ML-KEM"` / `"ML-DSA"` and add BC provider
JWT libraries with algorithm whitelist	Most libraries reject unknown algorithm identifiers	Use extensible custom algorithm framework (Nimbus) or wait for library updates
TLS cipher suite allow-lists	Static lists will block hybrid KEM named groups	Add `X25519MLKEM768` to named group list; keep classical fallbacks
Key size validation (e.g. “minimum 2048-bit RSA”)	ML-KEM/ML-DSA key sizes are not directly comparable to RSA key sizes	Validate by algorithm name and parameter set, not raw key size in bits
HTTP header size limits (load balancers, API gateways)	ML-DSA JWT tokens are 4–5× larger than ECDSA tokens	Increase header buffer limits; consider short-lived opaque token references for high-throughput APIs
HSM-backed private key operations	Most HSMs do not yet support PQC algorithms natively	Use software keystore for PQC keys now; migrate to HSM when vendor support lands
Certificate pinning with classical ECDSA pins	Pinned certificates will be invalid once you rotate to ML-DSA certs	Plan pin rotation as part of certificate migration; pin by SPKI hash, not algorithm
Serialised `PublicKey` objects in databases	PQC public keys use different DER/SubjectPublicKeyInfo OIDs	Re-encode keys in standard SPKI format; update OID-based lookups

8. Your Migration Checklist for 2026

PQC migration does not need to happen in a single sprint. The recommended approach is a phased transition that prioritises the highest-risk attack surface first — TLS key exchange, which is the vector for HNDL attacks — and defers less urgent changes like certificate authority migration to later phases.

Phase 1 — immediate (now)

1. Audit all services using RSA or ECDH for TLS key exchange. Add hybrid named groups (X25519MLKEM768) via BouncyCastle JSSE.
2. Upgrade BouncyCastle to 1.80+ in all projects.
3. Upgrade to JDK 21 LTS minimum; evaluate JDK 25 for services where you need native ML-KEM / ML-DSA support without BouncyCastle.
4. Ensure AES-256 (not AES-128) is used for all symmetric encryption at rest and in transit.

Phase 2 — near term (6–18 months)

5. Identify all JWT issuers and verifiers. Plan algorithm agility: store algorithm identifier alongside keys so you can rotate without code changes.
6. Increase HTTP header and response size limits to accommodate larger PQC signatures.
7. Engage your HSM vendor to confirm PQC roadmap timing.
8. Review certificate pinning implementations to ensure they are algorithm-agnostic.

Phase 3 — medium term (18–36 months)

9. Rotate JWT signing keys to ML-DSA-65 once IANA registration and library support is GA.
10. Request or issue ML-DSA TLS certificates from your CA once the CA/B Forum and browser trust stores support them.
11. Migrate HSM-backed key operations to PQC once your HSM vendor ships support.
12. Review all compliance requirements (FedRAMP, PCI-DSS, ISO 27001) for PQC migration mandates as standards bodies update their frameworks.

9. What We’ve Learned

The shift to post-quantum cryptography is not a distant theoretical concern — it is a concrete engineering project with a specific starting point, specific algorithms, and specific Java APIs you can use today. NIST’s finalization of FIPS 203, 204, and 205 in August 2024 gave the industry the stable target it needed. JDK 24 and 25 have made ML-KEM and ML-DSA first-class JCA citizens. BouncyCastle 1.80+ bridges the gap for teams on JDK 17 and 21.

The most urgent change is enabling hybrid TLS key exchange — because the HNDL threat means traffic recorded today can be decrypted in a future with quantum hardware. JWT signing and key management follow on a less urgent but still concrete timeline. The key lesson across all three areas is the same: build algorithm agility in now, before you are forced to make breaking changes under a compliance deadline. The algorithms change; the JCA API pattern stays the same.

Tags

Java Code Geeks

Level up your penetration testing skills with this 9-course bundle

What the curriculum covers

Thank you!

[FREE EBOOKS] Ransomware Protection Playbook, Job Architecture & Four More Best Selling Titles

Ransomware Protection Playbook ($28.00 Value) FREE for a Limited Time

Job Architecture: Building a Language for Workforce Intelligence ($35.00 Value) FREE for a Limited Time

Coexisting with AI: Work, Love, and Play in a Changing World ($28.00 Value) FREE for a Limited Time

The Art of Attack: Attacker Mindset for Security Professionals ($30.00 Value) FREE for a Limited Time

Creative Machines: AI, Art & Us ($35.00 Value) FREE for a Limited Time

Risky is the New Safe: The Rules Have Changed…($45.00 Value) FREE for a Limited Time

Thank you!

Recursion in Python – Introduction For Beginners

1. Understanding Recursion in Python

1.1 Core Rules of Recursive Functions

1.2 When Should You Use Recursion?

1.3 How Python Executes Recursive Calls

1.4 Recursion vs Iteration

1.5 Python Recursion Limit

2. Recursion Examples

2.1 Code Explanation

2.2 Code Output

3. Conclusion

Thank you!

The Halting Problem, Rice’s Theorem,and the Walls They Build

1. The Setup: What Does “Decidable” Actually Mean?

2. The Halting Problem: Turing’s Original Proof

3. Rice’s Theorem: The Full Generalisation

4. What This Means for Static Analysis Tools

5. The AI Problem: Why Larger Models Don’t Change the Math

6. Formal Verification: Escaping Undecidability Through Proof

7. Code Coverage and the Completeness Illusion

Demonstrating the limits: a halting program a simple checker gets wrong

8. What We’ve Learned

Thank you!

Jackson deserialization using a multi-parameter constructor

1. Introduction to Jackson Deserialization

1.1 Setup and Dependency Configuration

2. Complete Code Example

2.1 Code Explanation

2.2 Code Output

3. Conclusion

Thank you!

Probabilistic Data Structures: The Theory Behind Bloom Filters, HyperLogLog, and Count-Min Sketch

1. The Foundation: Why Hashing Makes This All Possible

2. Bloom Filters: Fast Membership Testing with a Built-In Caveat

How it works

3. HyperLogLog: Counting the Uncountable

The intuition: leading zeros as a signal

4. Count-Min Sketch: Frequency Estimation over Streaming Data

Error guarantees and sizing

5. The Math That Ties It Together: Linearity of Expectation

6. Putting It into Practice: When to Use Each

A minimal Bloom filter in Python

7. What We’ve Learned

Thank you!

Converting Between Byte Arrays and Short Arrays in Java

1. Understanding the Conversion Approach

2. Converting Byte Array to Short Array

3. Converting Short Array to Byte Array

4. Endianness Considerations

5. Conclusion

6. Download the Source Code

Thank you!

Understanding Database Triggers

1. Trigger Definition and Overview

1.1 Common Trigger Events in Databases

1.2 Internal Working of PostgreSQL Triggers

1.3 Types of Triggers in PostgreSQL

1.3.1 BEFORE Trigger (Pre-Execution Logic)

1.3.2 AFTER Trigger (Post-Execution Actions)

1.3.3 INSTEAD OF Trigger (View-Based Operations)

1.4 Row-Level vs Statement-Level Triggers

1.4.1 Row-Level Triggers (FOR EACH ROW)

1.4.2 Statement-Level Triggers (FOR EACH STATEMENT)

1.4.3 Key Differences

1.4.4 When to Use Which?

1.5 When to Use Database Triggers (Best Use Cases)

1.6 When to Avoid Database Triggers (Limitations and Trade-offs)

1.7 Managing Triggers in PostgreSQL