Forem: Mehuli Mukherjee

The Java PDF Table Extraction Library You’ve Been Waiting For..

Mehuli Mukherjee — Tue, 06 Jan 2026 22:31:32 +0000

Extracting structured data from PDFs has always been one of the most frustrating parts of working with document-centric data pipelines. Whether you’re automating financial reporting, processing invoices, auditing bank statements, or building analytics systems, the challenge is always the same:

How do you reliably get clean, structured tabular data out of PDFs — including scanned and image-based documents — in Java?

Today, I’am excited to introduce ExtractPDF4J 2.0, a major release that brings robust, hybrid PDF table extraction to the Java ecosystem — for both text-based and scanned PDFs — with enterprise-ready features, multiple parsing strategies, and a simple API.

GitHub Repo :

https://github.com/ExtractPDF4J/ExtractPDF4J

"Star the repo for more reach"

READMe for Details: How it works!

https://github.com/ExtractPDF4J/ExtractPDF4J/blob/main/README.md

Why PDF Table Extraction is Hard
PDF files are notoriously difficult to work with because they were never designed as data containers. In contrast to e.g. CSV or Excel, PDF:

Has no explicit table metadata.
Often stores text as independent glyphs without semantic structure.
May contain tables spread across pages, inconsistent formats, or mixed text + graphics.
Scanned PDFs have no text layer at all — requiring OCR.

Traditional Java tools like Apache PDFBox can extract text, and Tabula-Java can identify tables, but they struggle with scanned images, complex layouts, and multi-strategy extraction. ExtractPDF4J 2.0 addresses this gap natively in Java — no Python, no external wrappers.

What ExtractPDF4J Offers

ExtractPDF4J 2.0 is a production-grade Java library that brings together multiple extraction strategies under one roof:

StreamParser — For text-based PDFs, leveraging PDF text coordinates.
LatticeParser — For PDFs with grid lines or structured outlines.
OcrStreamParser — For image or scanned PDFs with OCR support.
HybridParser — Combines all approaches to maximize extraction quality. This hybrid strategy gives developers both accuracy and robustness regardless of PDF type.

Key Features in Version 2.0:

Hybrid Parsing Out of the Box ExtractPDF4J’s HybridParser intelligently combines:

Text analysis (for digital PDFs),
Structural grid detection (lattice),
OCR fallback for image PDFs. This is crucial for real-world workflows where documents often come in mixed forms.

Native OCR Support
Unlike many Java libraries, ExtractPDF4J includes native OCR integration (via Tesseract/OpenCV) — no separate Python service required. Configure the DPI and OCR mode and get accurate text from scanned documents.
Simple API & Annotation Configuration
Whether you prefer quick code snippets or declarative configuration, ExtractPDF4J supports both:

List<Table> tables = new HybridParser("scanned_invoice.pdf")
 .dpi(300f)
 .parse();

Or use annotated config classes for reusable parsers.

CLI and Microservice Support 2.0 also includes:

A command-line interface for bulk extraction jobs.
A Docker-ready microservice exposing a REST endpoint. This makes ExtractPDF4J a great choice for automation, batch processing, and cloud deployments.

How ExtractPDF4J Compares

That means if you need high-quality, reliable tabular extraction — including scans and mixed documents — Java developers finally have a tool built for the job.

Real-World Use Cases

ExtractPDF4J 2.0 serves a range of workflows:

Accounting & Finance Automation Extract tables from bank statements, invoices, balance sheets, and regulatory filings.
Data Engineering & ETL Pipelines Integrate structured PDF extraction directly into JVM-based processing systems.
Document Archiving and Analytics Convert historical scanned documents into structured CSV/JSON for analytics.
Compliance & Auditing Tools Extract evidence tables for audit trails, tax filings, and compliance reports.

What’s Next

2.0 lays a strong foundation. Going forward, ExtractPDF4J aims to expand on:

Enhanced machine-learning driven table layout detection
Improved integration with JVM microservices
More output formats (Excel, JSON/GraphQL directly)
Cloud-native serverless workflows

"Need Contribution for expansion"

Conclusion

If you’ve ever wrestled with extracting tables from PDFs — especially scanned or mixed documents — ExtractPDF4J 2.0 delivers the most comprehensive Java solution available today. With hybrid extraction strategies, OCR support, and flexible deployment options, it’s now easier than ever to convert messy PDFs into clean, structured data.

Try it today. Build faster. Ship reliable data pipelines.

Connect with me: https://www.linkedin.com/posts/mehulimukherjee_java-opensource-pdf-activity-7414116558110769152-ti6T?utm_source=share&utm_medium=member_desktop&rcm=ACoAACoHKyYBphUYH2QNjvFcwRhmqwXc3y9Yg5U

Why Should Python have all the fun? Meet my new Java Library..

Mehuli Mukherjee — Wed, 20 Aug 2025 05:00:28 +0000

I built ExtractPDF4J — a pure-Java library to pull clean tables from messy PDFs (even scanned ones)

ExtractPDF4J is a Java library that finds and extracts tabular data from both text-based and scanned PDFs using stream (layout/text) and lattice (line/vision) parsing—plus OCR. It’s on Maven Central, designed for server-side use (Spring Boot, microservices), and aims for Camelot-style features in the JVM ecosystem.

Maven Central: io.github.mehulimukherjee:extractpdf4j-parser:0.1.0

Repo: ExtractPDF4J

What Java had before

Apache PDFBox (and earlier iText):
These are general PDF libraries. They let you parse page text, metadata, and sometimes low-level drawing instructions. But they don’t provide high-level table extraction APIs. You’d have to implement your own heuristics for columns, bounding boxes, etc.

Tabula Java:
The Tabula desktop tool (originally Java + JRuby) could extract tables, but it wasn’t built as a clean, embeddable Java library. Most devs ended up using Tabula’s command-line wrapper or calling the Python-based Camelot instead.

Commercial SDKs (e.g., ABBYY, Aspose):
Paid libraries offered OCR + table recognition, but they’re proprietary and heavy. For open source Java projects, that’s not ideal.

Why I built it?

Most robust PDF table extractors are Python-first. In fintech/banking backends running on the JVM, pulling Python into prod creates friction (containers, ops, warm-up). I wanted a native Java option with strong accuracy on real-world documents like bank statements, invoices, and reports—without shelling out.

The gap ExtractPDF4J fills

A Camelot-like API in pure Java, with both stream (text-based layout) and lattice (grid/vision) parsing.

What it does (today)

Two parsing modes:

Stream: infers columns from text layout—great for digital PDFs.
Lattice: uses OpenCV-like line and joint detection + OCR—great for scanned PDFs.

OCR support (Tesseract): assigns text to detected grid cells for image-based PDFs.
Multi-page & multi-table: parse page ranges; detect multiple tables per page.
Merged cell handling: rowSpan / colSpan support in lattice mode.
Export helpers: get tables as CSV/JSON (and access cell-wise metadata).
Production-friendly: built for Java 17+ services (e.g., Spring Boot, AWS/EKS, microservices where Python dependencies aren’t welcome).

Quick start

1) Add the dependency
Maven

<dependency>
  <groupId>io.github.mehulimukherjee</groupId>
  <artifactId>extractpdf4j-parser</artifactId>
  <version>0.1.0</version>
</dependency>

Gradle (Kotlin)

implementation("io.github.mehulimukherjee:extractpdf4j-parser:0.1.0")

Optional (for OCR features): install Tesseract OCR and ensure it’s on your PATH.

Minimal examples

A) Text-based PDF (Stream mode)

import com.extractpdf4j.*;

public class StreamExample {
  public static void main(String[] args) throws Exception {
    PdfHandler pdf = PdfHandler.from("samples/statement.pdf");
    StreamParser parser = StreamParser.builder()
        .pages("1-3")               // or "all"
        .detectHeaders(true)        // heuristics for Date/Description/Amount etc.
        .build();

    TableResult result = parser.parse(pdf);
    result.tables().forEach(t -> {
      System.out.println("---- TABLE ----");
      System.out.println(t.toCsv());     // or t.toJson()
    });
  }
}

B) Scanned PDF (Lattice + OCR)

import com.extractpdf4j.*;

public class LatticeExample {
  public static void main(String[] args) throws Exception {
    PdfHandler pdf = PdfHandler.from("samples/scanned_statement.pdf");
    LatticeParser parser = LatticeParser.builder()
        .pages("1-2")
        .enableOcr(true)            // assigns OCR text into grid cells
        .exportDebug(false)         // set true to dump grid/joints as images
        .build();

    TableResult result = parser.parse(pdf);
    result.tables().forEach(t -> {
      // Access structured cells, spans, and metadata
      System.out.println(t.toJson());
    });
  }
}

C) Not sure which mode? Auto-detect

AutoParser auto = AutoParser.builder()
    .pages("all")
    .enableOcr(true)
    .build();

TableResult result = auto.parse(PdfHandler.from("samples/mixed.pdf"));

The rule of thumb:

Use Stream for digital PDFs (selectable text).
Use Lattice for scanned/image PDFs or documents with strong ruling lines.
Use Auto if you want the library to decide per page/table.

Real-world: bank statement extraction

Detects transaction tables across pages

Heuristically identifies headers like Date, Description, Amount

Handles multi-line descriptions and merged cells

Exports clean CSV/JSON ready for downstream reconciliation or analytics

Roadmap

✅ Multi-page, multi-table, spans, OCR assignment

🚧 Hybrid parser: combine Stream output with Lattice boundaries

🚧 Better automatic header detection across global bank formats

🚧 Optional ML table detection backends (e.g., PubTabNet/Donut-style)

🚧 CLI & Docker image for batch pipelines

(If you’d like any of these faster, open an issue or PR!)

Performance notes

Designed to run in containerized Java services alongside your other microservices.

For OCR workloads, consider caching, concurrency limits, and page-selection to control runtime.

Contributing

Try it on a tricky PDF (bank statements, invoices) and share a redacted sample.

File issues for false positives/negatives, header detection edge cases, and speedups.

Feedbacks and PRs welcome for new detectors, exporters, and language packs. Help me make it stronger and sharper tool for JVM..

License & credits

Open source (see LICENSE in the repo).

Inspired by the ideas behind Camelot/Tabula; implemented natively for the Java ecosystem.

Call to action

⭐ Star the repo and try 0.1.0 from Maven Central.

Comment with PDFs you want to handle better—I’ll prioritize those use cases.

P.S. If you write in Python but deploy on JVM, this might save you a few containers and some ops headaches.

[Boost]

Mehuli Mukherjee — Sun, 17 Aug 2025 22:58:15 +0000

Mehuli Mukherjee

Aug 11 '25

Stop Deploying AI Models Like It’s 2010 — Meet GitOps for ML

#ai #git #github #aiops

Comments

3 min read

Stop Deploying AI Models Like It’s 2010 — Meet GitOps for ML

Mehuli Mukherjee — Mon, 11 Aug 2025 05:11:24 +0000

We’ve all been there.

You train a shiny new AI model. It predicts cats, stock prices, or coffee orders with 98% accuracy (according to your very scientific local tests). You push it to production and...boom!!! it starts predicting… something else entirely.
Suddenly, your “future of AI” project is now the “future of why did I trust my laptop.”

This is where GitOps for AI models comes in - the magical combo of version control, automation, and reproducibility that makes “it works on my laptop” a quaint relic of the past.

Wait, GitOps… for ML?
If GitOps and MLOps had a baby, it’d be this.

In plain English:
You manage your AI models like you manage your code — with Git as the single source of truth, and automation doing the heavy lifting.

No more:
“Which model version is live?”
“Why did accuracy drop 10% last night?”
“Who deployed this model? And why is it predicting everything as a banana?”

Why Should You Care?

Reproducibility – Roll back to a previous working model in minutes.
Auditability – Every change is tracked.
Consistency – No more “dev, staging, and prod” being completely different universes.
Automated Deployment – No more FTP-ing to prod at 3 a.m. like it’s 2005.

How It Works (Without Melting Your Brain)

Everything in Git
Model weights, configs, training scripts, Dockerfiles.
Tag commits with model versions (v1.2.0-cat-classifier).
Define Deployment in Code
Kubernetes manifests or Helm charts describe how the model runs.
Use Seldon Core or KFServing for model serving.
Automate Rollouts
ArgoCD or Flux watches the Git repo.
When a new model version is committed, it’s auto-deployed to Kubernetes.
Monitor Like a Hawk
Prometheus + Grafana for inference latency, request counts, accuracy drift.
Alerts for “accuracy below X%” so you don’t learn about failures from angry tweets.

A Real-Life Example (with made-up names)

ML Alice trains “MochaNet” to recommend coffee sizes.
She commits the model + configs to Git.
ArgoCD sees the update and deploys it.
Two days later, Data Bob notices accuracy drift (everyone’s getting Venti instead of Tall).
He rolls back with git revert. Caffeine crisis averted.

Example GitOps Pipeline for AI Models

GitHub Actions Workflow

# .github/workflows/deploy-model.yml
name: Deploy AI Model via GitOps

on:
  push:
    branches:
      - main
    paths:
      - "models/**"
      - "deployment/**"

jobs:
  build-and-push-model:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repo
        uses: actions/checkout@v3

      - name: Log in to DockerHub
        uses: docker/login-action@v2
        with:
          username: ${{ secrets.DOCKER_USER }}
          password: ${{ secrets.DOCKER_PASS }}

      - name: Build Model Image
        run: |
          docker build -t myorg/cat-classifier:${{ github.sha }} .
          docker push myorg/cat-classifier:${{ github.sha }}

      - name: Update K8s Manifests
        run: |
          sed -i "s|image: myorg/cat-classifier:.*|image: myorg/cat-classifier:${{ github.sha }}|" deployment/model-deployment.yaml
          git config user.email "bot@github.com"
          git config user.name "GitOps Bot"
          git commit -am "Deploy model ${{ github.sha }}"
          git push

Kubernetes Deployment (Watched by ArgoCD)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cat-classifier
spec:
  replicas: 2
  selector:
    matchLabels:
      app: cat-classifier
  template:
    metadata:
      labels:
        app: cat-classifier
    spec:
      containers:
      - name: cat-classifier
        image: myorg/cat-classifier:latest
        ports:
        - containerPort: 8080

Common Gotchas

Large files: Don’t commit 500MB model files directly — use Git LFS or an artifact store (MLflow, DVC, S3).
Secrets: Keep API keys and DB creds out of Git — use Vault or Kubernetes Secrets.
Model drift: GitOps can’t stop your model from slowly becoming useless if the world changes.

Why This is the Future

With GitOps for AI models:

Deployments are boring (in the best way).
Rollbacks are one commit away.
Your weekends stay yours.

It’s like DevOps for code… but for those big .pt or .h5 files we keep pretending we fully understand.

Final Words
If you’re building AI models in 2025 and still deploying them manually, you’re basically sending faxes in the age of Slack.

Make Git your single source of truth, automate the boring stuff, and sleep better knowing your model won’t suddenly think every image is a banana.

Now go forth and GitOps your AI — because the future of MLOps is hands-free, fully versioned, and just a git push away.

https://dev.to/mehulimukherjee/how-to-boil-potatoes-i-thought-i-knew-until-i-didnt-1b64

Mehuli Mukherjee — Mon, 05 May 2025 04:42:29 +0000

How to Boil Potatoes? I Thought I Knew — Until I Didn't.

Mehuli Mukherjee — Mon, 05 May 2025 04:34:47 +0000

From Potatoes to Threads: A Real-World Journey Into Java Concurrency Optimization

I thought I knew how to boil potatoes.

You put them in a pot, add water, wait for it to boil, and eventually they soften up. Simple, right?

But recently, I visited a friend to help brainstorm his startup idea. While chatting in the kitchen, he tossed a couple of potatoes into a bowl with a splash of water, popped it in the microwave, and seven minutes later, they were done. No mess. No babysitting the stove. Just... done.

I was amazed.

It wasn’t just about potatoes. It was a perfect metaphor for something I face every day in software development: Optimization.

Old Habits Die Hard

In code, we often stick to what works. We rely on familiar patterns and tools. They may not be the fastest, cleanest, or safest, but hey, they get the job done. Just like the stovetop potato.

But what if there's a better way — one that saves time, reduces complexity, and delivers the same result?

That’s what optimization is all about.

A Real-World Concurrency Mess

Not long after my potato revelation, I faced a hairy Java concurrency problem at work.

We had a multi-threaded task scheduler in our enterprise application that processed transactional data across shared resources. Under pressure, the system began to crack: deadlocks, inconsistent states, unpredictable behaviors.

The original solution was layered with:

Deeply nested ReentrantLocks
Shared mutable maps guarded with synchronized
Ad-hoc retry loops and timeouts

It worked on paper. But it was complex, fragile, and hard to reason about. Performance was tanking. Debugging it felt like boiling a potato with a candle.

The Microwave Approach: Think Simpler

I paused and asked myself: Are we overcomplicating this?

Here’s what we did instead:

ExecutorService (fixed or scalable thread pool)
ConcurrentHashMap < String, AtomicReference < ResourceState > > — immutable transactional state updates
Lock-free atomic updates using compareAndSet
CompletableFuture for chaining + timeout/failure handling
Backoff with retry scheduler (ScheduledExecutorService)

Here's a simplified example:

import java.util.concurrent.*;
import java.util.concurrent.atomic.*;
import java.util.function.UnaryOperator;

class TransactionProcessor {

    // Represents an immutable transactional state for a resource
    static class ResourceState {
        final int transactionCount;
        final long lastUpdated;

        ResourceState(int transactionCount, long lastUpdated) {
            this.transactionCount = transactionCount;
            this.lastUpdated = lastUpdated;
        }

        ResourceState applyTransaction() {
            return new ResourceState(transactionCount + 1, System.currentTimeMillis());
        }

        @Override
        public String toString() {
            return "count=" + transactionCount + ", time=" + lastUpdated;
        }
    }

    private final ConcurrentHashMap<String, AtomicReference<ResourceState>> resourceMap = new ConcurrentHashMap<>();
    private final ExecutorService executor = Executors.newFixedThreadPool(8);
    private final ScheduledExecutorService retryScheduler = Executors.newScheduledThreadPool(2);

    private static final int MAX_RETRIES = 3;
    private static final int BACKOFF_MS = 200;

    public void processTransaction(String resourceKey) {
        submitWithRetry(resourceKey, 0);
    }

    private void submitWithRetry(String resourceKey, int attempt) {
        executor.submit(() -> {
            try {
                AtomicReference<ResourceState> ref = resourceMap.computeIfAbsent(
                        resourceKey, k -> new AtomicReference<>(new ResourceState(0, System.currentTimeMillis()))
                );

                boolean updated = false;
                for (int i = 0; i < 5; i++) { // CAS retry loop
                    ResourceState current = ref.get();
                    ResourceState updatedState = current.applyTransaction();
                    if (ref.compareAndSet(current, updatedState)) {
                        System.out.printf("Updated: %s (attempt %d)%n", resourceKey, updatedState, attempt);
                        updated = true;
                        break;
                    }
                }

                if (!updated) throw new RuntimeException("CAS failed after multiple retries");

            } catch (Exception e) {
                if (attempt < MAX_RETRIES) {
                    int delay = BACKOFF_MS * (attempt + 1);
                    System.out.printf("Retry attempt %d after %dms due to: %s%n",
                            resourceKey, attempt + 1, delay, e.getMessage());
                    retryScheduler.schedule(() -> submitWithRetry(resourceKey, attempt + 1),
                            delay, TimeUnit.MILLISECONDS);
                } else {
                    System.err.printf("Failed after %d attempts: %s%n",
                            resourceKey, attempt + 1, e.getMessage());
                }
            }
        });
    }

    public void shutdown() throws InterruptedException {
        executor.shutdown();
        retryScheduler.shutdown();
        executor.awaitTermination(5, TimeUnit.SECONDS);
        retryScheduler.awaitTermination(5, TimeUnit.SECONDS);
        System.out.println("Shutdown complete.");
    }

    public void printFinalStates() {
        System.out.println("\n=== Final Resource States ===");
        resourceMap.forEach((key, ref) -> System.out.println(key + " => " + ref.get()));
    }

    public static void main(String[] args) throws InterruptedException {
        TransactionProcessor processor = new TransactionProcessor();
        for (int i = 0; i < 50; i++) {
            String resourceKey = "resource-" + (i % 5); // 5 shared resources
            processor.processTransaction(resourceKey);
        }

        Thread.sleep(3000); // allow processing time
        processor.printFinalStates();
        processor.shutdown();
    }
}

It wasn’t fancy, but it was faster, safer, and a whole lot easier to maintain.

What Makes This Optimized?

Can Scale To:

Millions of resources using sharded maps or local caches.
Async I/O or DB commits with CompletableFuture chaining.
Resilience features like circuit breakers or observability tools (Prometheus, Micrometer).

The Real Lesson

Optimization isn’t always about clever hacks or tuning JVM settings. It’s often about rethinking the whole process.

Ask yourself:

Am I doing this the hard way just because it’s what I know?
Is there a tool, pattern, or paradigm that simplifies this?

Sometimes the solution is already in the kitchen. You just need someone to show you the microwave.

Final Thoughts

Whether it's potatoes or production code, the goal is the same: get the job done well, with as little pain as possible.

Next time you’re stuck in complex, boilerplate-heavy code, step back and ask:

Am I using a stove when I could be using a microwave?

Can We Create a Self-Destructing NFT for Privacy?

Mehuli Mukherjee — Mon, 05 May 2025 04:27:19 +0000

Exploring the Idea of Expiry-Driven Smart Contracts (in Simple Terms)

What if your digital stuff could expire — just like in real life?

Let me ask you something simple.

When you buy a movie ticket, it works until the showtime ends.
When you rent a scooter, it’s yours for the next 30 minutes.
When you share a document, sometimes you only want someone to view it once.

Now think about this:
On the internet — especially on the blockchain — things don’t expire.

They stay forever.
And that’s… not always a good thing.

So here’s the question I’ve been asking myself:

Can we create digital things that are meant to disappear?
Like:

A digital pass that deletes itself after one use
A smart contract that vanishes after 24 hours
An NFT that self-destructs once it’s fulfilled its purpose

Not as a bug — but by design.

Why would we want that?

Because not everything needs to live forever.

There are plenty of moments where we need temporary access, not permanent records:

Sharing a medical file with your doctor for just a day
Giving someone a one-time access token to a private video
Issuing an event ticket that’s useless after the show

In the real world, these things expire naturally.
But in the blockchain world? Once it’s there, it’s there forever.

That might sound cool — but it can also cause problems for privacy, data control, and cleanup.

Okay, but… how would that even work?

That’s what I’ve been trying to figure out.

Imagine creating a smart contract (which is just a fancy way of saying “code on the blockchain”) that comes with a timer.

It could say:

“This token only works for 7 days.”
“After this date, automatically delete or disable this.”
“If it hasn’t been used in 24 hours, burn it.”

Kinda like a digital version of Mission Impossible:

“This message will self-destruct in 5… 4… 3…”

I’m still learning, but here’s what I’ve found:

There are already tools and platforms that can help:

Smart contracts on Ethereum or Polygon
Automated bots that check time and run actions
“Burn” functions that can delete tokens

I’m not a blockchain expert yet — but I’m curious.
This is the kind of project I’d love to explore further as a personal build.

Because I think it matters.

Why? Because we deserve digital control.

Think about how much of your life is now online.

Wouldn’t it be nice to:

Share something temporarily
Own something just for now
Delete something when it’s no longer useful?

The internet remembers everything. But maybe it doesn’t always have to.

Maybe Web3 can help us forget — when we want to.

Just a thought (for now)

I haven’t built this yet.
No startup, no funding, no flashy pitch deck. Just a developer’s brain going: “Hmm… what if?”

So if you’ve ever thought about digital privacy, NFTs, or weird ideas that might not be that weird, let’s talk. Maybe we’ll build it. Maybe we’ll inspire someone who will.

Until then… this blog won’t self-destruct. 😄
But if it did, that’d be kinda cool, wouldn’t it?

What If Land Ownership Was Secured on Blockchain? A Thought Experiment from a Developer’s Desk

Mehuli Mukherjee — Mon, 05 May 2025 04:21:40 +0000

The Problem That Got Me Thinking

Property ownership is one of those things we assume is settled — until it’s not.
Across countries, land disputes, forged documents, unclear titles, and bureaucratic opacity make property transfers a slow, error-prone, and in many cases, corruptible process.

What struck me recently was this question:

What if property records were stored on an immutable, decentralized ledger — visible to all, editable by none?

Why I’m Thinking About It

As someone exploring Blockchain through side projects and POCs, I’ve always been fascinated by the idea of “programmable trust.”
We’ve seen its impact in finance and NFTs. But what about real-world systems that desperately need transparency?

Property registries are perfect candidates:

They deal with high-value assets

They require long-term record integrity

They suffer from manual inefficiencies and fraud risks

The Global Relevance

This isn’t just a developer’s fantasy.

Countries like India, Sweden, and Ghana have explored or piloted blockchain-based land registries.
But most implementations hit roadblocks — either technical, legal, or political.

Still, the idea sticks with me:

What if individuals could verify ownership with a public key, transfer property with on-chain smart contracts, and eliminate forgery using hash-based notarization?

The Development Path (In My Head)

Here’s what I’ve been sketching out:

Ethereum-based Smart Contract to track land parcels, ownership history, and transfer requests.

Each parcel would have:
a. A unique ID
b. Document hashes (stored on IPFS?)
c. Public address of the verified owner

Ownership transfers would trigger:
a. Verification of identities
b. Digital signature of both parties
c. Approval (possibly multisig for government authority)

Optional: a private blockchain fork if public chain costs become a barrier.

Still early. Still messy in my head. But possible.

The Challenges I Know I’ll Face

How do you verify land documents before putting them on-chain?

Who gets to act as the final evaluator of ownership?

How do you build trust in the system before the system can be trusted?

But that’s the thrill of it — thinking about how technology might reshape something as fundamental as property rights.

Why This Could Matter

Because in many parts of the world:

Land is the most valuable asset most people own.

Yet ownership is ambiguous, fragile, and easily manipulated.

Blockchain won’t fix all that. But maybe it can offer a neutral, auditable, and incorruptible foundation for the future.

What’s Next?

I haven’t built this yet.
But it’s simmering. Sketching. Slowly forming into something real.

If I do take this forward, I’ll start with a prototype on a testnet. Maybe a small UI. Maybe even simulate a digital deed registry for a fictional city.

Would Love to Hear From You

If you’ve worked on anything like this — or know of resources, examples, or projects — I’d love to hear your thoughts.

This is the kind of idea that only becomes great when many minds think it through.

Let’s build better systems — starting with better questions.

How I Went From Googling “What Is Solidity?” to Writing Smart Contracts for Fun

Mehuli Mukherjee — Mon, 28 Apr 2025 22:52:21 +0000

A personal adventure into Blockchain, Smart Contracts, and why securing them is harder than securing my weekend plans.

Introduction: The Accidental Blockchain Enthusiast
I’ll be honest — my first thought when I heard about Blockchain was:
“Isn’t that the thing they keep talking about on the news whenever Bitcoin crashes?”

But curiosity (and a healthy dose of FOMO) got the better of me.
Somewhere between late-night YouTube rabbit holes and realizing the future of finance was heading toward decentralization, I decided:

“I’m going to build a Smart Contract. From scratch. Like a grown-up.”

And thus began my personal journey into the weird and wonderful world of Ethereum, Solidity, and trying very hard not to create the next DAO hack by accident ;-)
And I ended up getting a Postgraduate Diploma specializing in Blockchain Technology.

Having completed the diploma,
I had a solid theoretical understanding of distributed systems, consensus algorithms, and smart contract basics.

But let’s be real — no amount of diagrams in textbooks truly prepares you for the moment when you deploy your first smart contract… and accidentally spend all your test Ether on a single typo.

This project was my way of making the theory real. A hands-on journey to move beyond paper knowledge — and actually build something that works (and survives a few bugs along the way).

The Plan: Make It Real (But Not Risky)
Since I work in banking and love secure systems, I wanted my POC to not just work —
but to be secure, scalable, and not accidentally send imaginary millions to strangers.

My personal mission:

Build a Smart Contract for simple asset tokenization — safely.

Bonus mission:

Actually understand what I’m doing, not just copy-paste from Stack Overflow.

Tools I Used (and Googled a Lot)
Solidity (the magical programming language of Ethereum)
Remix IDE (because setting up a local dev chain at first felt like fighting a Kraken)
Ganache (for my personal fake Ethereum playground)
Truffle (testing smart contracts without crying too much)
MetaMask (the wallet that gave me more test Ether than my real bank account had)

How I Built It (and How I Almost Gave Up)
Step 1: Write the Smart Contract
At first, my code looked something like this (during the course):

pragma solidity ^0.8.0;

contract AssetToken {
    string public assetName;
    address public owner;

    constructor(string memory _name) {
        assetName = _name;
        owner = msg.sender;
    }
}

Translation:
I basically made a Hello World for Blockchain.
Victory dance? Not yet.

Step 2: Secure the Contract (So It Doesn’t Explode)
Once I wrote a few more functions (transfer ownership, view details, etc.),
I started reading horror stories about reentrancy attacks, overflows, and hackers smarter than me.

I used SafeMath to avoid overflow issues.
I added modifiers like onlyOwner to sensitive functions.
I practiced defensive coding like it was cybersecurity finals week.

_Step 3: _Testing, Testing… and More Testing
Deployed to Ganache (local fake blockchain).
Ran unit tests using Truffle.
Found hilarious bugs like:
a. “Anyone can transfer ownership if they spell their name backward.”
b. “Contract thinks 0 is a valid new owner.”
Moral of the story:
Never trust your first deployment. Or your second.

Key Challenges (aka Lessons in Humility)
Understanding Gas Optimization:
I accidentally wrote a function so expensive, it would’ve cost more than my Netflix subscription to run.

Managing Wallets and Private Keys:
Lost one test wallet. Still having a moment of silence for it.

Deploying to Real Testnets:
Turns out, testnets are real networks, with real delays, and real lessons in patience.

What I Built in the End
a. A working, secure-ish Asset Tokenization Smart Contract
b. A deeper understanding of Blockchain security principles
c. A strong desire to always audit your contracts before touching anything live

[User Interface (MetaMask Wallet)]
⬇️
Smart Contract (Deployed on Testnet)
⬇️
Blockchain Ledger (Ethereum Public Chain)

Conclusion: Why This Journey Mattered
I didn’t just build a Smart Contract —
I built a new set of skills:
Security-first coding mindset.
Blockchain architecture fundamentals.
Courage to dive into complex, emerging tech without fear.

Today, I can confidently say I understand how Blockchain fits into real-world financial systems — combining my formal Postgraduate Diploma in Blockchain Technology with real hands-on learning and how small mistakes can become million-dollar news headlines.

And the best part?

It all started with a random late-night decision to learn something new.

How I Tamed a Wild AI to Answer Banking Questions Without Making Things Up: A Spring Boot + OpenAI Story

Mehuli Mukherjee — Mon, 28 Apr 2025 22:42:22 +0000

Banking info should be easier to find than car keys on a Monday morning. Sadly, it isn’t. So we built a chatbot to fix that. A behind-the-scenes look at designing an AI-driven chatbot for the future of banking — And My first encounter with Open AI.

Introduction: The Spark Behind the Idea
In today’s digital-first world, banks and financial institutions face an ongoing challenge: how to provide quick, reliable, and accessible information to both customers and employees.
Whether it’s finding the nearest branch, understanding service policies, or accessing executive contacts — information is often buried across multiple systems, leading to inefficiencies.

While working as a Senior Full Stack Developer specializing in innovation projects, I set out to tackle this challenge.
My mission was clear: build a smart, intuitive banking chatbot powered by AI — a solution that could instantly answer banking queries using the capabilities of Azure OpenAI Service and the robustness of a Spring Boot backend.

Why Azure OpenAI + Spring Boot?
While OpenAI’s GPT models have demonstrated powerful natural language capabilities, enterprise financial services demand stricter compliance, security, and privacy standards.
This made Azure OpenAI a natural choice — offering both powerful models and enterprise-grade security.

For backend development, Spring Boot offered the flexibility and reliability needed to create a secure API service layer around the AI model.

Solution Overview
Here’s the high-level system architecture of the solution:

How the Solution Works
Users interact with the chatbot via a simple web UI or mobile app.
They authenticate via OAuth2 or Single Sign-On (SSO).
The query passes through the Chatbot API built using Spring Boot.
The API securely communicates with Azure OpenAI’s fine-tuned endpoint.
Responses are generated based on curated internal banking knowledge.
The answer is sent back to the user — fast, accurate, and secure.

Implementation Journey: Step-by-Step
Step 1: Curating the Data
The first step was to build a high-quality, domain-specific dataset.
Collected internal documentation: branch locations, services, executives, operational policies.
Structured the information into Q&A pairs for fine-tuning.
Ensured that sensitive customer data was excluded.

Step 2: Fine-tuning the Azure OpenAI Model
Azure allowed for secure fine-tuning of GPT-3 with financial service-specific data:
Uploaded the curated dataset.
Tuned parameters (e.g., temperature, frequency penalty) for better factual reliability.
Deployed the fine-tuned model under private, secure access environments.

Step 3: Building the Spring Boot Backend
To securely interface with Azure OpenAI:
Created a Spring Boot REST API.
Implemented user authentication middleware.
Built secure, scalable APIs to handle communication with Azure services.
Applied rate limiting and exception handling for better fault tolerance.

Step 4: Deployment on Cloud Infrastructure
To ensure scalability and compliance:
Deployed the backend service in a cloud-native environment (using Kubernetes services like AWS EKS).
Applied API Gateway security layers.
Monitored performance with centralized logging and alerting systems.

Key Challenges Faced:
Challenge 1: Data Security Compliance
Building an AI for banking is like inviting a dragon to dinner — cool, but you need a lot of safety rules. Financial institutions demand tight compliance standards.
Solution: All data flows were secured within virtual private clouds (VPCs) and encrypted in transit.

Challenge 2: Managing Hallucinations in AI
Large language models sometimes “hallucinate” facts.
Solution: Continuous feedback loops and retraining were established to improve accuracy over time.

Challenge 3: API Latency Optimization
External API calls to Azure AI introduced slight latencies.
Solution: We optimized critical paths by implementing query caching for frequent questions.

Impact: What Changed?
Response time for internal banking queries improved dramatically.
Operational efficiency increased, freeing up staff from manual lookups.
Provided a foundation for customer-facing AI-driven banking initiatives.
Demonstrated that enterprise-grade AI solutions can be securely and responsibly implemented in regulated industries.

Conclusion: What I Learned
Turns out, AI can answer your branch location faster than your colleague in the next cubicle. If AI can book your travel, recommend your next song, and now answer your banking questions — maybe it’s time we stop fearing it will steal our lunch. One chatbot at a time, we’re making banking conversations a little smarter — and a lot more human.

Building an AI-powered chatbot was not just about leveraging APIs — it was about building trust.
Trust that the system would deliver accurate answers, keep information secure, and be reliably available when needed.
This project strengthened my expertise in:

AI integration into real-world systems.
Cloud-native API development.
Enterprise AI compliance and security.
It reaffirmed my belief that true innovation happens at the intersection of cutting-edge technology and real-world business challenges.

And the journey is just beginning.

Final Note
Are you exploring how AI can transform banking or enterprise systems?
Let’s connect — I’m always excited to exchange ideas and build the future together!