DEV Community: Sumit

Elegance Was Never Dead: The Return of Perfectionism

Sumit — Tue, 22 Apr 2025 18:32:49 +0000

“Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away.” — Antoine de Saint-Exupéry

This isn’t a technical guide, or a tutorial on prompts, or a love letter to the latest framework. It’s something quieter. A reflection on a mindset. On how, as technology accelerates especially with AI we’re beginning to rediscover old ideas under new light.

There was a time when writing code felt like sculpting. Every line held intention. Every decision carried the weight of future maintainability, readability, and pride. Maybe you’ve known someone who’d refactor a function not because it was broken, but because it could be clearer. Maybe you’ve been that someone. And while others rushed ahead, you stayed behind naming things well, splitting methods with care, shaping the invisible structure with the same reverence an architect might shape a quiet, sturdy home.

That wasn’t wasted effort. That was a kind of poetry. We didn’t call it over-engineering we called it love for the craft.

But something has shifted. Not for the worse, not for the better just… algorithmically different. Today, with AI tools like GPT, Claude, Copilot, Cursor, Amazon CodeWhisperer, Tabnine, and the ever-mysterious "vibe coding" mood board that is Twitter dev threads, more and more of our code is being drafted by something that doesn’t sleep, doesn’t snack, and definitely doesn’t understand context.

We’re no longer just authors we’re editors, reviewers, damage control. We’re the second pair of eyes that needs to see what the first pair a well-meaning, overconfident autocomplete engine might have hallucinated into existence.

Perfectionism, once feared as a productivity sinkhole, is quietly reclaiming its space. But not as pixel-pushing or infinite refactoring. Now, it shows up as thoughtful inspection. As a pause. As a second thought. It’s less about elegance, more about integrity.

Aristotle spoke of the Golden Mean the virtue that lives between two extremes. For many years, we believed the middle path in software was shipping fast, keeping things simple, and avoiding the rabbit hole of over design. But maybe that balance is shifting. Maybe, in the age of AI-assisted development, a little more scrutiny, a little more intention, is what brings us back to the center.

In this new world, being a perfectionist doesn’t mean resisting change or clinging to old ways. It means adapting without forgetting why we cared about quality in the first place. It means knowing that while AI might take the wheel, we’re still the ones reading the road.

Between Autopilot and Paranoia: The Mindful Path of Perfectionism

In practice, balance today looks like mindful development. The kind that asks you to slow down, even when the machine speeds up. It’s less about resisting AI and more about learning how to work alongside it without losing your own sense of judgment.

It’s a bit like the mindset from Zen Buddhism: be present, be deliberate. When the AI spits out a chunk of code, I don’t react with blind trust (too lax) or with immediate rejection (too rigid). I try to sit with it. Ask questions. Is it readable? Is it safe? Does it actually solve the right problem?

There’s a Zen saying: “Before enlightenment, chop wood, carry water. After enlightenment, chop wood, carry water.” For us, it’s: Before AI, write code, debug code. After AI… write code, debug code. The work hasn’t disappeared it’s just shapeshifted. The same rituals remain. I still have to carry water, so to speak. Just now, I carry it in a review comment, a test case, a rewritten function.

If Marcus Aurelius were a tech lead, he might remind us to “love the framework of fate” not to curse the tools for what they get wrong, but to treat their flaws as part of the job. We don’t get to choose the wave, but we do get to learn how to surf it.

Finding that balance isn’t formulaic. It’s an instinct built over time. It’s noticing when the AI starts hallucinating confidence into broken logic. It’s choosing to simplify a generated solution instead of praising its complexity. And sometimes, it’s about trusting your own discomfort when something looks right but doesn’t feel right.

The Golden Mean isn’t static. It shifts with context. And in 2025, it just might live somewhere between accepting every AI suggestion and rewriting everything by hand.

The Return of Thoughtful Perfectionism

I find it ironic and exciting that a thoughtful form of perfectionism is making a comeback in software engineering. No, we’re not back to obsessing over whether to name a variable tempData or intermediateResult for hours, nor are we adding pointless abstractions for theoretical use cases.
This new perfectionism is different: it’s human-guided, principle-driven, and focused on safety and clarity. It’s a recognition that in an age where code can be machine-generated in an instant, the real value a seasoned developer adds is thoughtfulness the kind of careful thinking that machines can’t (yet) do.

In practical terms, this means we care about things like correctness, security, and transparency of code more than ever. We double-check that the AI’s code doesn’t have hidden pitfalls. We enforce coding standards so that the next human (or next AI) reading the code can understand it without psychic powers. We pay attention to performance implications and edge cases that an auto-generated solution might miss. We treat code not as an ephemeral throwaway just because it was easy come, easy go, but as an artifact that will live on and needs to be trustworthy.

Ultimately, this is leading us to a more balanced engineering culture. Speed and efficiency from AI plus careful human oversight can coexist. We are learning to harness the brute-force productivity of our silicon sidekicks while applying the nuanced judgment that comes from experience and yes, from our human sense of craftsmanship. The goal is no longer perfection for perfection’s sake (it never really should have been), but a kind of perfectionism with purpose: making the software better in ways that truly matter more robust, more secure, more understandable. It’s almost like we’re channeling that old perfectionist energy, but instead of pouring it into gold-plating the design, we’re pouring it into fortifying the code’s integrity.

So, is perfectionism in software engineering dead now that AI is writing code? Far from it. It’s evolving. We’ve gone from lovingly hand-carving every solution, to sometimes accepting quick and dirty code, and now to lovingly cleaning up quick code. In this journey, we may have rediscovered why we cared about “perfect” code in the first place. Not to satisfy some OCD impulse or to impress others with cleverness, but to ensure our software works well and can be maintained by real people. In the end, the “perfect code” was never about having zero flaws that’s impossible but about striving for excellence where it counts.

The quest for quality has come full circle. The tools and techniques have changed, but the heart of the matter is the same.

this is the beginning of a new era not where machines replace our standards, but where they challenge us to uphold them with even greater clarity.

Squeezing the Most Out of Every Byte: Go's Memory Packing Secrets Unpacked!

Sumit — Sun, 14 Apr 2024 10:34:24 +0000

Go is renowned for its straightforward design, favored for cloud-native applications. It boasts unique flair and special features, often tipping the scales toward favoritism thanks to its engineering marvels under the hood.

Why Discuss Padding in Structs?

In the fast-paced world of software development, where generative AI can churn out articles in minutes, it's crucial to dive deeper into topics that AI might gloss over. This blog aims to shed light on a seemingly niche yet critical aspect of Go—struct padding. This clever feature optimizes memory usage so efficiently that it might just tip the scales for Java developers considering a switch. It’s like Go is saying, “Come for the simplicity, stay for the memory management!”

In Go, a struct is a fundamental building block for data organization. A struct is a user-defined type that groups elements of various data types under a single name, similar to a record in a database. This makes it incredibly useful for data transfer and managing related data together, much like a custom toolkit where each tool has a specific role.

Let's look at a more contemporary and relevant example than the classic Car struct—consider a User Authentication Module:

type UserSession struct {
    userID    uint64  // 8 bytes
    timestamp uint64  // 8 bytes
    isActive  bool    // 1 byte
    isLoggedIn bool   // 1 byte
}

Struct Padding Explained

Now, let's delve into struct padding. Struct padding in Go ensures that the fields within structs are aligned according to the CPU's word size to facilitate faster access. But what does this mean? Let’s break it down:

Word Size: This refers to the number of bytes the CPU can process at one time. On a 64-bit system, the word size is 8 bytes, meaning the CPU can handle 8 bytes of data in a single operation.
Alignment: For the CPU to process data most efficiently, the data needs to be aligned in memory according to the word size. This means that data types should ideally begin at memory addresses that are multiples of their size, up to the word size.

For example, on a 64-bit system:

A 1-byte bool field should be aligned to a 1-byte boundary (any address).
A 4-byte int32 field should be aligned to a 4-byte boundary (address divisible by 4).
An 8-byte uint64 field should be aligned to an 8-byte boundary (address divisible by 8).

When struct fields are not naturally aligned with these boundaries, the Go compiler will automatically insert "padding" — extra space — between fields. This padding ensures that each field starts at an address that aligns with its size, optimizing memory access during runtime.

For instance, consider an imaginary application High-Performance User Session Manager

type UserSession struct {
    isActive  bool    // 1 byte
    // 7 bytes of padding here to align the next field
    userID    uint64  // 8 bytes
    isAdmin   bool    // 1 byte
    // 7 bytes of padding here to align the next field
    timestamp uint64  // 8 bytes
}

In this example, the isActive and isAdmin fields are 1 byte each, but they are followed by 8-byte uint64 fields (userID and timestamp).
To ensure that the userID and timestamp fields are properly aligned, the Go compiler adds 7 bytes of padding after the isActive and isAdmin fields, respectively.
This padding ensures that the CPU can access the 8-byte fields efficiently, as they are now aligned to 8-byte boundaries in memory. While the padding may seem like a waste of memory, it's a trade-off that the Go compiler makes to optimize the performance of memory access.

Initial Analysis with Unsafe Package

Using the unsafe package, we can inspect the size and alignment of this struct:

package main

import (
    "fmt"
    "unsafe"
)

func main() {
    var s UserSession
    fmt.Println("Size of Session struct:", unsafe.Sizeof(s))
    fmt.Println("Alignment of Session struct:", unsafe.Alignof(s))
    fmt.Println("Offset of isActive:", unsafe.Offsetof(s.isActive))
    fmt.Println("Offset of userID:", unsafe.Offsetof(s.userID))
    fmt.Println("Offset of isAdmin:", unsafe.Offsetof(s.isAdmin))
    fmt.Println("Offset of timestamp:", unsafe.Offsetof(s.timestamp))

}

This script will output the size of the Session struct as well as the offsets of each field. Initially, we might find that the struct uses more memory than necessary due to padding added after the bool fields to align the struct to 8 bytes (since it's the largest alignment requirement in the struct).

Here's what each function call in the provided code snippet does:

unsafe.Sizeof(s): This function returns the total size in bytes of the struct s, including any padding added by Go to align the fields in memory.
unsafe.Alignof(s): This function returns the alignment of the struct s. Alignment dictates how the start of the struct should be positioned in memory. Typically, this is the largest alignment of any field within the struct, which helps ensure that all fields meet their alignment requirements.
unsafe.Offsetof(s.userID): This function returns the byte offset of the field userID within the struct s. The offset is the distance from the start of the struct to the start of the field.
unsafe.Offsetof(s.timestamp): Similar to the offset for userID, this gives the distance from the start of the struct to the timestamp field.

These functions are particularly useful for understanding the memory layout of your structs, which can help in optimizing performance, especially in systems programming, or when interfacing with hardware or operating system APIs where precise control over memory layout is necessary.

Go Tooling for Struct Layout Analysis

While the unsafe package provides a low-level way to inspect struct layout, Go offers a more convenient tool specifically designed for this purpose: go tool structlayout. This tool can be used to visualize the memory layout of your structs, including field offsets and padding bytes. Here's an example of using go tool structlayout:

go tool structlayout -layout UserSession

This command will print a detailed breakdown of the UserSession struct layout, making it easier to identify any padding introduced by the compiler.

Optimizing the Struct Layout

To minimize memory usage, we can reorder the fields to place all 8-byte fields first, followed by smaller fields, reducing the need for padding:

type OptimizedSession struct {
    userID    uint64  // 8 bytes
    timestamp uint64  // 8 bytes
    isActive  bool    // 1 byte
    isAdmin   bool    // 1 byte
    // Padding of 6 bytes here to align to 8 bytes
}

Alternative Optimization: Using Pointers for Small Fields

In some cases, depending on how these fields are accessed, an alternative optimization technique might be to use pointers for the smaller fields (isActive and isAdmin) if they are frequently accessed together with the larger fields. This can help reduce the overall memory footprint, especially when dealing with a large number of structs. However, it's important to consider the trade-offs between memory usage and code complexity when making this decision.

Profiling Memory Impact

We can compare the memory usage before and after the optimization using a benchmark test in Go. This test will create a large number of session structs and measure the total memory used:

package main

import (
    "testing"
    "unsafe"
)

func BenchmarkOriginalSession(b *testing.B) {
    for i := 0; i < b.N; i++ {
        _ = UserSession{
            isActive:  true,
            userID:    123456789012345,
            isAdmin:   false,
            timestamp: 1609459200,
        }
    }
}

func BenchmarkOptimizedSession(b *testing.B) {
    for i := 0; i < b.N; i++ {
        _ = OptimizedSession{
            userID:    123456789012345,
            timestamp: 1609459200,
            isActive:  true,
            isAdmin:   false,
        }
    }
}

func main() {
    var originalSize = unsafe.Sizeof(UserSession{})
    var optimizedSize = unsafe.Sizeof(OptimizedSession{})
    println("Original Session size:", originalSize)
    println("Optimized Session size:", optimizedSize)
}

This benchmarking will help demonstrate the memory savings achieved by simply reordering struct fields.

The memory savings from switching from the non-optimized to the optimized layout are:
32 bytes (non-optimized) - 24 bytes (optimized) = 8 bytes saved

Although each individual struct might only save a few bytes, in a high-load scenario where millions of these structs could be in memory at once, the overall memory savings can be significant.

A Critical Note on Optimization

Although the Go compiler is quite adept at handling most memory optimization tasks, many developers, myself included, often strive for perfection in optimizing every byte of memory usage. This can be seen as a kind of compulsion to make everything as efficient as possible—a common trait among developers.

However, it's important to note that such detailed optimization isn't always necessary, especially in environments where the cost of hardware or computing resources (like your AWS bill) isn't a constraint. In these cases, the default optimizations performed by the Go compiler should be more than sufficient. Over-optimizing can lead to more complex and harder-to-maintain code without significant benefits in many practical applications.

So, while it's great to know how to squeeze every byte for performance-critical applications, remember that sometimes throwing more hardware at a problem is a perfectly valid solution too!

Trade-offs of Struct Padding

It's important to acknowledge that while struct padding improves performance by aligning memory access, it can also affect cache locality in some cases. Cache locality refers to the principle that data likely to be accessed together should be stored close together in memory to minimize the time it takes to retrieve it. When padding increases the distance between frequently accessed fields, it can lead to more cache misses, potentially negating some of the performance benefits of alignment.

This trade-off between alignment and cache locality is a more advanced topic, but it's worth keeping in mind when considering struct padding optimizations. In most cases, the performance benefits of alignment outweigh the potential drawbacks for cache locality. However, for highly performance-critical scenarios, it might be necessary to delve deeper into cache behavior and profiling to make informed decisions.

I hope this comprehensive explanation clarifies struct padding in Go and provides valuable insights for optimizing your data structures!

API security Part-1

Sumit — Sat, 27 Feb 2021 15:37:50 +0000

Today, most modern web applications are running on browsers, and most of you know how it works HTML, CSS, javascript, etc.

Let's consider a simple web application that shows some reviews on a user's post a simple, crud app.

Once the application loaded on a browser first time, nothing excited because there is no data. The application will load some data from a server with some API, performing operations and the security pitfalls that you might encounter at this level, and that's the point of this blog.

As you know, it is not just about web apps, and it refers to mobile apps, electron apps, etc. All these types of applications use APIs.

Every day, we hear about APIs being exposed and having their security compromised—not an uncommon story. Therefore, it's essential to have best practices in place to be successful.

Today everybody has to consider API security whether you are a user of an API or provider. In this blog, we will look at some pitfalls and some pointers where to look at your application and where to look at when using other's APIs to improve the security of the application.

OWASP Top Ten inspires this blog, A awareness document related to the most dangerous web security vulnerabilities published by the OWASP organization. Every developer should be aware of this document.

We will specifically be focusing on OWASP 2017 A10 – Underprotected APIs section.

First, let's discuss some incidents that cause too much damage to particular companies' reputations and businesses because of neglecting API security.

In 2017, Germany banned children's smartwatches, which means the device meant to be secure for children providing the location to their parents has some significant security flaws.

Some smartwatch providers are API backed, and these APIs allow an attacker to make it appear that the child was somewhere else but watch location pointing somewhere, and that's the whole point of the device.

Here we are not making fun of any company, but we can evaluate our application standards based on their mistakes.

What happens after this? The watch company has worked hard, updated its system, fixed that issue, and returned to the market after one year. Security researchers took another look at their APIs, and they discovered something interesting !!

In one of the API, there was a parameter called user grade.

If this parameter's value is 2, it works fine, no issues, but they figured out if the value change to 1, you become the Admin !!

![user grade admin image ](https://dev-to-uploads.s3.amazonaws.com/i/d8zeankidwirql02lqm1.png)

So this is the kind of fundamental issue, let us see one more relevant and common one.

Facebook has one beta version of its website [mbasic.facebook.com(https://mbasic.facebook.com/)for testing all new features and stuff; in March 2016, one bug bounty hunter reported missing rate-limiting for forget password endpoint. It means anybody can try every possible combination to get the password of a user. It is not too tricky also even there is already one HTTP status available.

This point brings us our first security pitfall lack of rate-limiting.

No RATE LIMITING

Rate limiting prevents malicious code from abusing legitimate/ illegitimate access to your API.

Surprisingly enough, so many APIs have rate-limiting as a business feature because they use it for their freemium model, which means you can do some number of calls for some time and get a premium or paid account for some time further access. To prevent active abuse and data exploitation of your APIs, you should have rate-limiting as a security measure. Lack of API rate limiting can also expose other points of a system to access data.

In Aug 2018, Hackers Stole the Personal Data of 2.3 Million T-Mobile Customers through one of the leaky APIs.

T-mobile has used customer phone numbers as an identifier for their accounts, which makes sense to a phone company because phone numbers are supposed to be unique in the whole system and easy to work with then; why not !!

However, the problem is not the access data with a phone number, but the problem is insecure direct object reference, which has been around for ages in web applications now; it just takes a new form with APIs.

This point brings us to our next security pitfall lack of proper authorization.

Lack OF PROPER AUTHORIZATION

Insecure direct object reference issue is if you are accessing something and the system is not verifying that you are allowed to access that particular object yes or no.

So in T-mobile's case system endpoint has verified that you are authenticated or not, and if not, you are not allowed to access the resource fair enough. Once you are authenticated, then the magic starts; provide the phone number get the data boom!!, they have never checked whether you are the owner of the account or not.

This is a very, very common authorization problem, and the reason why these problems exist because of tutorials like this

I am going to assure you in 10 min there is no security involved in it and which is ok because the tutorial doesn't focus on security, but it teaches how Rest API works, for example, there is an endpoint that takes an Id for reading a task or same goes to delete the task, etc.

Easy way to start right, no issues at all, but when you move this small todo app to production, you have to think about authentication. Next, step most of us will learn about how authentication works, and then we implement the check is user authenticate or not ??.

Unless we react to thinking about, hey we not only have to worry about user authentication but also we need to think about whether this user has access to modify or delete this task, we have an authorization problem.

The authorization problem is not that easy to solve. The application needs to know who the user and every API of the application should be aware of the user access.

To solve the Authorization problem first, we need to know who the user is; I know it is a part of the authentication process. Still, it is imperative to propagate the user information to every API of the application in one way or another.

Understanding authentication or some heading

Back in the days, we had PHP applications like this.

We have client, server, and session saved on the server, so as the application grows, we have multiple clients, servers and this architecture refer as a stateful application.

As the technology evolved, rest API-based systems became the trend, and people started moving towards stateless application sessions no longer stored on servers. Stateless systems are making sense if you building applications for thousands or millions of users.

Server-side session data is not compatible with the REST stateless paradigm but still works well with small to medium-scale applications.

The whole point of the above discussion is where you keep the user information, whether authentication or authorization.

Where you keep this info is does matter, why because saving state on the server-side is a traditional way of doing and the server is considered charming, secure environment, attackers cannot easily reach to the server and change the information its like authentication valid for name Jhon changing it to something else it's complicated and if you can change this info, then you have breached the security. You can do whatever you want, not only changing the authentication property.

However, movings things to the client-side is a bit tricky; that's precisely the point of stateless applications.

It does not just take the state from the server and move it to the client, and you are done.

In your applications, it has many impacts. It depends on how you handle this information on the client-side. The user state moved from a very secure, isolated environment to an easily accessible place where anybody can change whatever they want.

You have no idea about the data which comes back it's trustworthy or not, before you make an authorization decision.

In modern web applications, we often use JSON WEB TOKENS to solve this issue.

Usually, we use them in combination with OAuth and OIDC, not as a basic token. Here we will not discuss in detail JSON WEB TOKENS only brief.

As you can see in the image left side is the actual token, and the right side purple color is the data that we can use later, and this data protected by a signature that ensures the integrity of the data. So once you receive the data, it can be verified by a server-side secret key, and you can decide because you have reliable data.

To match the signature and other stuff will again fall back on us a developer, which can lead to several other issues.

MISHANDLING CLIENT-SIDE SESSION DATA

Client-side session data is easy to read and manipulate. You need to ensure confidentiality and integrity before using any of the session data.

If you are a Java developer, you might write code like this from a prevalent library Auth0 java-jwt easy to use, but if you know how to.

This example is not the correct way to use it here the step

DecodeJWT jwt = JWT.decode(token);

will take out the payload and will return your claim as an object to get user-related data, id, etc.

The above can be if you have missed reading the library documentation or in your IDE you got the suggestion ohh, Decode, that is what I need to do which can lead to this type of critical issues. This issue will never be caught in testing unless you feed some malicious signature, so you have to think about security in the testing phase.

Instead of just this simple code which only decodes the data, it could be implemented like this. You can also encrypt JWT before sending it to the client; more advanced libraries are available to support JWT encryption and can be a good idea.

Things are not going to end here, so; please bear with me for some time; let's see how the JWT signature can be misused.

MISUSING THE JWT SIGNATURE SCHEME

HMAC stands for Hashed or Hash-based Message Authentication Code. So it's not a signature; it is a checksum that is used to generate the signature.

You have the data, header, and payload (JWT), and the library will push this data to the HMAC function and provide a secret HMAC key, and the output comes as a random base64 encoded string doesn't mean anything. This is the key that we have to send to the client as data.

When it comes back to the server, you do the same thing, push it to the HMAC function with the same secret key and match the output string.

If it is the same, you know that the message has been signed before it is the same, coming back now.

If they don't match, something has changed because the secret key is the same, then it must have been the modified data.

We don't care what is changed; whether space is added or something else, throw it out because it is an invalid token.

Let's continue this in the next blog API security Part-2 publishing soon.

I did nothing for a day

Sumit — Sun, 13 Sep 2020 08:21:17 +0000

What I have observed

I was able to breathe more deeply.
I was able to notice things around me which usually I don't.
This is the pic which I took from my bathroom wall, from years which I didn't notice(sry for bad image quality 😇)
My intensity of workout got increased and I was able to focus more, reason was no meetings to attend, no emails to reply to , the most important thing, no coding ☺️ !!
Played with my cat
Planned to write this blog

I felt so much change only in a day, I will try to do this more frequently and for a longer time.

Comment down your nothing day story or if you have a plan to do the same !!

Thank you for reading :) :)

Performance matters

Sumit — Tue, 05 May 2020 11:39:26 +0000

Good performance starts with good code.

Sometimes a small change in your code can make a significant amount of performance improvement.
So let not your code stink, be careful next time while you write code.

The API of Optional typically has two methods that can cause confusion: orElse() and orElseGet().

1.  public T orElse(T other)
2.  public T orElseGet(Supplier<? extends T> other)

Clearly, orElse() takes any parameter of a type T whereas orElseGet() accepts a functional interface of type Supplier that returns an object of type T.

Now, based on their Javadocs:

. orElse(): returns the value if present, otherwise return other
. orElseGet(): returns the value if present, otherwise invoke other and return the result of its invocation

orElse()

orElse() is evaluated even when having a non-empty Optional.
For example,

String name = Optional.of("dev.to")
  .orElse(processData());

public String processData() {
    LOG.info("process data method - start");
     
    // DB process/update complex business logic 
     
    LOG.info("processData method - end");
    return "processed string";
}

On executing our code, we'll find below messages printed in the console:

process data method - start
processData method - end

The variable name will hold dev.to at the end of the code execution.

With it, we can easily infer that the parameter of orElse() is evaluated even when having a non-empty Optional. It can easily cause Hugh performance downgrade if else part is having some DB processing or complex business logic.

orElseGet()

Now, let's try writing similar code using orElseGet()

String name = Optional.of("dev.to")
  .orElseGet(() -> processData());

public String processData() {
    LOG.info("process data method - start");

    // DB process/update heavy processing 

    LOG.info("processData method - end");
    return "processed string";
}

The above code will not invoke processData() method.

Using orElseGet() for our case will, therefore, save us some time involved in computing.

So to summarize this blog we can considering factors involve.

What if the method would execute some additional logic? E.g. making some DB inserts or updates
Even when we assign an object to orElse() parameter

String name = Optional.of("dev.to")
.orElse("Other");

we're still creating “Other” object for no reason

And that's why it is important for us to make a careful decision among orElse() and orElseGet() depending on our needs – by default, it makes more sense to use orElseGet() every time unless the default object is already constructed and accessible directly.

Let's revisit Java in 2019

Sumit — Sat, 19 Oct 2019 15:25:03 +0000

It's been 6 years from now since Java 8 was released and people are still not able to digest the features of it, wasn’t Java 8 a fantastic update to the language?

Lambdas and streams were a huge change and have helped to improve Java developers’ productivity and introduce some functional ideas to the language.

Then the new guy came into the town Java 9, and although the module system is really interesting for certain types of applications, but uncertainty around how painful it might be to migrate to Java 9 left many applications taking a wait-and-see approach, happy with Java 8 and some are still living with the old buddies Java 5-7.

But now Java has a new version every six months, and suddenly Java 13 is here. We’re all still on Java 8, wondering whether we should move to a later version, which one to choose, and how painful it might be to upgrade.

In this blog we’ll look at:

Why upgrade from Java 8, including language features from Java 9, 10, 11, 12, 13?
What sorts of issues might we run into if we do choose to upgrade?
How the support and license changes that came in with Java 11 might impact us?

Since Java 11, there have been a few concerns around, I don't want to pay for Java.

I want to discuss a bit about this, because a lot of people are super happy with Java 8, thank you very much. I think I'll just stay here. I've got lambdas and streams. It's all I ever wanted from my language. I don't need modularity, so I'm not going to go beyond Java 8.

This is what I am hearing and finding everywhere from people who are at least some concern about their tech stack. This doesn't even represent the people who are using 7, 6, or even, heaven forbid, earlier than 6.

Lot's of changes that happened in the last couple of years news-wise that you need to be aware of if you're running Java inside your organizations.

Releases

Firstly, Java has moved to a six-month release cycle.
In the old days, we would get Java every two years, three years or sometimes six or seven years between versions of Java, which is one of the reasons why I think enterprises loved it so much because it's nice and stable.

But now, since Java 9, we have releases every March and every September like clockwork, and this is a much better way of working.

We know this from doing continuous delivery and continuous deployment. If we say we're going to release on a specific date, we just release the features that were ready then. And then if they're not ready at that point, we release them in the next release. We just have this nice, predictable release cadence.

As a developer, we know it's a pain in the neck to support something, more than one version of something, at the same time. Same thing applicable to Oracle also and obviously Oracle didn't want to support every one of these releases for three years because, at some point, they'll be supporting like six or seven different versions of Java.

Instead, with the six-monthly releases, each release will be supported for the six months of their life.

By support, I mean having updates available, so updates for 9, 10, and so on and so forth for six months, until the next release comes out.

Obviously, not everyone wants to upgrade their version of Java every six months. So here is a catch, every three years one of these releases will be designated a long term support release, specifically Java 11 and I assume Java 17.

Java 8 is also a long term support release. You get sort of mini releases every six months, 9, 10, and then you get long term support releases every three years, so 11. And that explains people are on either 8 or 11. Because if you are using 9, you should have migrated to 10. And if you are on 10 you should have gone to 11, because now 9 and 10 are no longer supported.

The OpenJDK is the same as the Oracle JDK, and that includes the commercial features that you used to have to pay for in the Oracle JDK.

There are a bunch of different Open JDK vendors to choose from some of them are Zulu, AdoptOpenJDK, Amazon Corretto, etc. So Oracle is not the only game in town.

Because of these different options, it lets you slowly migrate from 8 to 11, to 17 with a bit of overlap. You can actually see it says the end of availability for Java 8 is at least September 2023. So some of you are going to take away from this blog, We don't need to upgrade from Java 8 until 2023. Fine, but you're going to have a lot of pain in a few years' time.
So the question is now that sounds scary and complicated.

Why should I bother migrating from Java 8?

We are developers and technical people, and what we care about is the language features.

People who are using versions of Java later than 8, which are the features they use the most? Which ones are the most interesting?
Here we are not going to discuss detail about these features, that we can plan for some other time.

JShell

With the help of JShell, you can able to run small snippets of Java from the command line, which we could never do before because we had to have a whole class with public static void main(), blah, blah. But now we can do, including tab completion, we can just run stuff from the command line. And you see, you get all your nice tab completion there. And you don't need semicolons, progress. You could do a bunch of other stuff. You can, obviously, define variables.

One of the nice things about using JShell is you can mess around with the new features without having to create a whole class or testing framework.

You can run scripts and things like that. So it's kind of nice. I'm not really sure how many people are really using effectively scripting for Java. But it turns out that a lot of people are finding it quite useful. People were happy to see that JShell is built into the language. You can just kind of use it to try stuff out as early as possible.

One of the nice things about JShell, as you saw, it's like an independent command line thing. You don't actually need to do anything with your existing applications to start using it. You can just download Java 11, or Java 12,13 if you want, and use JShell completely independently from anything with the rest of your application. It allows you to sort of get started, get up and running early on and quickly without impacting anything that you have at the moment.

Most of you probably know of, or have used var.Now, with var, it's going to use the type information obviously on the right to determine what the type is. Var doesn't mean dynamic typing, by the way; it just means you don't have to type the types on both sides of the equal sign.

Var is not like a magic keyword, you just put it everywhere and say, "Let's just get rid of all the types on the left hand side." It's something to think about. You use it when it makes your code easier.

The use of var also makes your code concise by reducing duplication, e.g. the name of the Class that comes in both right and left-hand side of assignments as shown in the following code snippet:

ByteArrayOutputStream bos = new ByteArrayOutputStream();

Here, ByteArrayOutputStream repeats twice. We can eliminate that by using the var feature of Java 10 as shown below:

var bos = new ByteArrayOutputStream();

Factory methods for collections

My favorite feature from Java 9 is the convenience factory methods for collections. This is one of the things that gets used by a bunch of people.

We're going to look for Java 9. Obviously, this came into Java 9. For all of you using Java 8, in the olden days, we would declare a list, a set of values like this. Your Arrays.asList(), and you sort of use it as if it was an immutable, unmodifiable list. But actually it's not, because you can't add to that list, but you can change the individual elements on that list. So it's actually not unmodifiable, but we all used it as if it was. We have to wrap it inside an unmodifiable list to make it unmodifiable. In Java 9, you don't have to do that. You call List.of() , and it's much more readable.

It's kind of nice for a list. It's really nice for a set because creating a set was a bit of a pain. You have a list, and then you put it in a set, and then you wrap it in an unmodifiable set. I don't understand why this feature wasn't in the language earlier. Now, you just say Set.of() and you will get an unmodifiable set.

Set<String> set = Collections.unmodifiableSet(new HashSet<String>() {{
     add("foo"); add("bar"); add("baz");
}});

can be used now as

Set<String> set = Set.of("foo", "bar", "baz");

Same thing is applicable to Map also.

In Java 10, one of the things that came in is the ability to collect into these unmodifiable lists. That's really useful. You can just straight away change your streams to collect into unmodifiable lists, sets, etc.

Another new feature that came in in Java 9, is new methods on the Stream API. This was a feature that I thought was a little bit missing from Java 8, the ability to do things like process this stream until some condition is met. This is .takeWhile(), the other example is .dropWhile(), so ignore this stream until some condition is met. So it's just a nice little addition to the language for working with streams.

Stream<String> stream = Stream.of("sam", "sumit", "jhon","nancy");
 List<String> list = stream.takeWhile(name -> (name.charAt(0) == 's'))

                  .collect(Collectors.toList());

the output of this code will be [sam,sumit].

Stream<String> stream = Stream.of("sam", "sumit", "jhon","nancy");
    List<String> list = stream.dropWhile(name -> (name.charAt(0) == 's'))

                  .collect(Collectors.toList());

the output of this code will be [jhon, nancy].

Optional methods

Then over the course of Java 9, 10, and 11, we've been getting additional methods on optional. I actually think this is one of the most interesting things about the most recent versions of Java.

Java 8 had optional. Optional is good. It's a really nice way of saying, as a return type from an method, saying, "You might get something. You might not."

Don't misuse it in terms of having it for fields, and for parameters, and all the rest of it. It's really there just for when you ask for something like, "Find me something." Optional can say, "You got something," or, "You didn't." With Java 8, you can work with it in a fairly simple way. You can say .ifPresent(), or .isPresent, and .get(). And it's kind of fine, but the recent methods that have been added on 9, 10, and 11 make it a little bit even easier to use.

For example, when you have to use Optional.isPresent(), and you have to do a .get(), and then an else- which you don't have to, because you could have done a .ifPresent() there, but you still have the else hanging around which is a bit clumsy. I found that optional was a bit difficult to work within 8.

But now, you can just give two lambda expressions. So you either do that if it's present, or you do something else if it's not present. That's one of the nice things. That's Java 9. You’ve got .or() on Java 9 as well, which gives you an alternate optional. So you either return this optional value or return a different optional value.

 blog.ifPresentOrElse(  
  this::publish,  
  this::notifyThatNothingWasPublished
 );

HTTP client

Java 11 comes with a built in HTTP client. Built in HTTP client will solve our headaches, so you don't have to use any dependencies. But also, it's non-blocking reactive streams, HTTP 1 and 2. So this is something that a lot of people are interested in from a Java 11 point of view, especially in this current world of asynchronous reactive programming.

Project Jigsaw

Java 9 had Jigsaw, which everyone is very excited about it or not. And of course, we're supposed to call it the Java Module System, not Jigsaw. So it is useful for a bunch of people specifically, again, for library developers because they can encapsulate stuff that you're not supposed to be able to touch. That's the point. But it also can be useful for enterprise developers who want an excuse or a mechanism to actually properly separate the concerns inside their applications.

JLink

The most interesting thing to me I think about the module system is it allows us to do things like have JLink. I think, is very interesting. This allows you to package up your application and just the bits of Java that you want, and create a much smaller deployable, and deploy it into the cloud. For example, with the JDK being modularized, there's a whole bunch of modules you could be using. But if you're just using java.util or java.logging, like two or three of those modules, you use JLink to create a single deployable with your application and just the bits of Java that you want. They can be much, much smaller.

This is not the end of the world it is just I don't want to make this blog a marathon 😌.

Reason to upgrade

The business doesn't care about language features. We care about language features because it makes our job easier.

I say we- I'm assuming that we're all developers, or developer-minded. So you can't sell the business on upgrading to Java 13 because of var, for example, they just don't care. But what they do care about is things like performance.

So generally speaking, each version of Java is generally faster for a number of different reasons. Anytime you upgrade, even if you don't make any changes, even if you don't make use of anything, you generally find that the performance of your application is better

Obviously, test, measure, see if it's true or not, but often you get free performance improvements.

Specifically, in the last few versions, there's been a lot of optimization, some memory use. For example - that's garbage collectors, and we used things like the way that strings are represented. Particularly if you're running in the cloud and you care about memory use.

There have been a lot of changes to the garbage collector. In Java 9, the default garbage collector is G1. And then a bunch of changes went in to help improve the performance of G1 even further.

If you care about the garbage collection, obviously, people tend to go, "Performance equals garbage collection in Java." It's an element of it, but it's not the only aspect of performance. But there are a lot of changes there. Coming in later, we have even more different types of garbage collectors, more improvements to those garbage collectors, and so on. So, again, these are the sorts of things that if these garbage collectors and these changes work for you, you get some free performance improvements moving forward.

Obviously, what the business really cares about is cost. Now, I believe that moving forward to a later version of Java can help reduce costs of the company, by which I mean actual money type costs, in terms of things like using JLink, in terms of things like better performance, lower memory usage, and so forth.

So you can reduce costs. But there's also another cost which I think is important. If your organization is trying to hire Java developers, which most organizations are at any point in time if they have a big Java shop, and if you're going to be stuck on an older version of Java for a long period of time, it will be more difficult to attract developers going forward. At the moment it's fine because they're probably fine working on Java 8. But going forward, people are not going to be interested in working on legacy systems going forward. So I guess that's kind of a personal thing from the developer's point of view.

The other reason which I think is really interesting to move on and migrate now is to get yourself on the six-month release train before it gets away from us. Because we may be worried about getting over the hump of Java 9 to Java 10. But if we leave it much longer, it's just going to get worse and worse. That big difference between Java 8 and Java 17 is just going to be a very difficult bridge to span, a gap to bridge.

So I think it's worth trying to get onto 11 now so that then we can start thinking about testing against each of these six-monthly releases. Even if we stick on 11 and we don't plan to migrate to 12, 13, 14, we plan to migrate to 17, we can be running each of these six-monthly releases in CI to make sure that we stay up to date for as long as possible.

If you try and migrate to Java 17, it's going to be very painful, particularly since Oracle has said they are going to start deleting stuff. Deprecated means deprecated. There may only be a year's worth of notice between deprecating something, and actually removing it from the language. So we need to get onto this release train now and do it more frequently.

In Summary

Java is changing and it's changing much faster than it used to. It's no longer the nice, slow, and stable enterprise type language that we're used to. Modern Java can help you. This is a good thing. The recent versions of Java have focused on things like reducing boilerplate, increasing readability, but also, of course, things like performance is always improved with each release of Java.

Take a walk with OAuth 2.0

Sumit — Sun, 25 Aug 2019 12:48:02 +0000

Recently I got a chance to work on OAuth 2.0 and I have noticed that there is so much complexity and confusion about OAuth 2.0 and OpenID connect over the internet.

The reason behind it is that it's a difficult protocol to understand, tons of jargons and terminologies and there is a lot of confusion about it online.

When I have started to learn about OAuth 2.0 and OpenId connect I didn't find a single source of truth and there is a plethora of blogs and everybody on StackOverflow seems to be explaining it in their own way to implement it.

If you have ever felt confused, overwhelmed then you are not the only one, pretty much everybody has. In this blog, I will try to make things a little bit less intimidating and in the comments, you can let me know if it makes sense.

Why when we have a concrete spec but so many different interpretations about how to use it? that doesn't happen with a protocol like HTTP and there is a pretty correct and concrete way to use but with OAuth, there is some fuzziness in the implementation which makes it more difficult and creates confusion on how to use it.

So before explaining about OAuth and OpenId, I just want to set a stage for simple login and forms authentication which is the most basic type of authentication on the web where user enters username/email and password, the request goes to the server and the server talks to the database and verifies the username and password hopefully, hashed one 😉.

If the verification was successful then the server sends a cookie to the web browser to keep track of the user.

Now the industry is moving away from this kind of homegrown solution, this simple form authentication has nothing to do with OAuth but I just want to let you know that this is what we are going to compare with.

So there are a couple of downsides of this approach like

Security
Maintenance

Because you are responsible for maintaining the authentication system there is only your server-side code which will talk to the database and verify the password and all. You should be always aware of new security standards and best practices like hashing, encryption and storing user information securely, etc.

Let's go back in time 2006-07, Applications and websites back then also had several use cases such as Login, Authentication, Authorization, etc
so we can combine these cases and call it Identity use cases.

Identity use cases(pre-2010)

Simple login (forms and cookies)
Single sign-on across sites (SAML)
Mobile login (user should stay logged in if the app is closed also long living sessions)
Delegated authorization (????)

Here the term Delegated authorization is the Genesys of OAuth protocol.
Despite sounding very boring this is the thing I am going to focus on.

You might be aware of delegated authorization and which is something you interact every day, without actually knowing what it is. It is a common pattern now but it was not 10 years back.

Delegated authorization is the process where we let sepecific websites access our data without actually giving away the credentials.

So back then there was no good way to solve this problem and one company called Yelp tried to solve this problem but in a really bad way
at the end of registration Yelp asked users hey you want to share Yelp with your Gmail or Yahoo contacts for sign up or promotions etc,
for this, they want user's actual Gmail email address and password it means its like Yelp login to user's Gmail account grab user's contacts sends email to them, then logout and throw away the password and promise not to do anything evil 😱

For many people, their Gmail or Yahoo account was their main email accounts and key for everything they have like bank details, finances, password resets, etc. So it is a really bad idea to give their password randomly to any app or website.

Here I am not targeting Yelp to design this type of solution it's just a good example to illustrate what was the problem then how they didn't have the proper way to solving the problem.

Today we are having a better way to solve this problem using OAuth protocol like the image above where Gitlab wants to access Github user information.

Now we will see how Yelp should have been solved this problem using OAuth.

Nowadays we are having one link/button mostly on every application something like connect with google, what happens when user will click on this button user will put into OAuth flow and ultimate result of this, the application can access the user's authorized information.

User can ensure that the application which wants the contact access can only be able to access contacts not like delete the contact, send an email or view the photos on google photos and drive information, etc.

When user will click on connect with google button browser will redirect to a google login page like account.google.com this is a little bit better than the previous solution because the user is providing the password to google though not to Yelp or somebody else.

Assume now the user logged in successfully, then one prompt will appear as this application Yelp wants to access your list of information which includes your public profile or contact details etc, are you sure you want to allow to access Yelp this information.

Now User explicitly has consent to whatever they're granting access to, that's important so he doesn't get tricked into like agreed to something that he doesn't know.

So if the user clicks No, then we are done nothing interesting happens here and flow will restart again but suppose if the user clicks on Yes then the browser one more time redirect back to the application, back to where it started to a special place in the application called a callback or a redirect callback or redirect URI that again we will discuss later in the blog.

Then with a little bit of magic that application which is Yelp in our case allowed to talk to some other API say like google contacts API and Yelp usually don't have access to this API but now it has something(access_token) which this application got when the user clicks on Yes button.

Now, below are the things which go into this magic.

OAuth 2.0 terminology

Resource Owner
Client
Authorization Server
Resource Server
Authorization Grant
Redirect URI
Access Token

A resource Owner is a fancy way of talking about you and me as a user who is clicking on Yes button and sitting in front of computer who owns the data which application Yelp wants to access, in this context I am the resource owner who is having Gmail account and contacts and Yelp is want to access my Gmail contacts.

A client is just a way to refer to the application in this case Yelp is the client, the application that wants the resource owner data basically.

An authorization server is a system which resource owner can use to say yes, I authorized this permission and I authorized this to happen in this case authorization Server is accounts.google.com.
If you search on google term authorization server this is what you will get 😧 !! and this why I am writing this blog to make things a little bit more clear.

A resource server is different from the authorization server, resource server is the API server which holds the data that the client wants to get access, in this case, Google contact API is the system which holds my contact.

Sometimes authorization server and resource server together kind of melded into the same system but many time they separate.

The whole point of OAuth flow is going over to the authorization server, coming back to the client is just to get something called authorization grant and the authorization grant is the thing that proves that I have clicked on Yes or I consent to this level of permission or I allow you to have to access of my Gmail contacts.

When the authorization server redirects back to the client application it kind of needs to know where to redirect back this is called callback or sometimes it is called redirect URI, it is just where should I end up at the end of this flow if the users click on Yes where they need to go next.

I mentioned above the authorization grant is the point of this whole flow well but at an even higher level, the thing the client really needs is something called access token.
An access token is going to be the way the key that the client uses to get into whatever the data user has granted access to or granted permission to on the resource server.

Pheww so much information, I think you are getting confused and overwhelmed till this time if you are reading till now and if you are ready to show little bit patience your all doubts and confusion will clear in a bit.

Let's see the diagram above which I have described earlier with all these jargons.

Now we will start the flow again with me the resource owner who is sitting on the client website Yelp and I clicked on the connect with google button and then what happens is I will redirect to this authorization server which is accounts.google.com in this case but it could be the Facebook authorization server or authorization server hosted by Octa or it could be somebody else .

Right at the beginning of this flow when the client is redirecting over the authorization server its already passing some kind of the configuration information that the authorization server needs, so it's saying hey when you are done assuming everything is successful here is the URI where I want you to redirect back at the end. So we have to pass the redirect URI at the very beginning and we also have to provide some other information such as what type of authorization grant do we want.

There are actually few different types of an authorization grant, in this case, we will be going to use a most simple type of authorization grant called code grant or authorization code grant because we are requesting a code and it is called authorization code flow.

So now the authorization server prompts the login, consent to that permission all that good stuff then redirects back to the place specified at the beginning the redirect URI and redirect with something called authorization code because that's what we ask for at the beginning.

Now the client can't do a whole lot with that authorization code, in fact, there's only one thing that the client can do at all with authorization code which is to go back to the authorization server one more time and exchange this authorization code with access token.

After getting the access token, now the client Yelp can do what they actually want us to do in the first place which is going to the resource server contacts.google.com and ask for the user contacts.

Normally resource server will not allow to accessing the user's contacts but in this case, the client is attaching the access token in the request and this proves that user said that it is ok for the resource server to access contact information.

Now if the client tried to do something else say not retrieve my contacts but delete all my contacts, in this case, resource server says ok you have an access token but it doesn't mean that you can do just anything, the user has given you only read-only access to the contacts.

So access token grants access to the client to do specific things but how does the client specify what are the things it wants to do??

Let's add some more terminologies.

Scope
Consent

An authorization server is having a list of scopes based on the client needs, for example, read-only access to contact.

Too much, ok I got it, let's continue about scopes and consent in the next blog.

Follow me on Medium and Dev.to to know more about tech.

Dev to Production Part -1

Sumit — Sun, 28 Apr 2019 09:49:31 +0000

The other day I was just lying down in my office chair and pretending to be super busy 😉, I was building a Jenkins release for one of our Spring-Boot application. My colleague was just passing from there and to spend some time I asked him, do you know what I am doing right now? he told you are making a plan to get Iron man to earth.

As you know this is not real. I asked him what will happen after you push your code?. I got to know that he was not aware of the process after pushing the code. I thought why not write a blog and explain to my innocent colleague, friends and the other people who just push the code and waiting to get the ticket for the end game. So folks just take a chair and grab a beer here is the start of the end game.

Soon I will update the source code at GitHub

The whole life cycle of developing something and get a release to a production environment is called CI/CD pipeline that stands for Continuous Integration and Continuous Delivery.

Continuous Integration (CI)

CI is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.

Continuous Delivery (CD)

CD is the natural extension of Continuous Integration: an approach in which teams ensure that every change to the system is releasable and we can release any version at the push of a button. Continuous Delivery aims to make releases faster and boring, so we can deliver frequently and get fast feedback on what users care about.

A continuous integration and deployment (CI/CD) pipeline is such an important aspect of a software project that it saves a ton of manual, error-prone deployment work. It results in higher quality software for continuous integration, automated tests, and code metrics. Ultimately this facilitates better software that can be released more frequently.

There are a plethora of CI/CD products available out there, such as ones you can use in the cloud via software as a service (SaaS) or self-hosted ones. Some examples of hosted solutions are CodeShip.io and TravisCI, and self-hosted examples are TeamCity,Jenkins and Thoughtworks Go.

To get to know more about this topic you can read this article.

As this article will be huge, I will explain everything here in a series of the blogs where we will be configuring Jenkins in Windows and Ubuntu Operating Systems and create pipelines for Spring Boot and Angular Apps or maybe for React if you guys are interested.

We will discuss the whole process from scratch and discuss each step in detail so you will have a clear picture of the process.

That’s all folks!

Thanks to Mohana Krishna for the feedback.

I hope this article helped you with an overview of CI/CD Pipeline.

Stay tuned for the next article.

Follow me on Medium and Dev.to to get an update about tech.

Spring Boot with Redis conversion service and custom key converter

Sumit — Fri, 05 Apr 2019 02:34:58 +0000

This article is all about Spring-boot and Redis integration with using spring-data-redis.Spring Data Redis is the abstractions of the Spring Data platform to Redis the popular in-memory data structure store. The full source code for this project is available on GitHub. Let’s straight come to the point.

I am assuming that you are already familiar with spring boot and redis and you have chosen redis as a cache store for your project.

In some scenarios where we have to deal with multitenant application or we want to cache multiple user data in Redis, then to avoid data conflicts and for better app arcitecture we can take advantage of spring redis data conversion service.

Below logic is fine when we have to save the data which is common across all the users.

String cacheKey = “user-data”; 
   Cache cache = cacheManager.getCache(cacheKey);
   Cache.ValueWrapper result = cache != null ? cache.get(cacheKey) : null;
   if(result.get()!=null){
        // get the data and proceed 
    }else{
        cache.put(cacheKey, userData);
    }

But what if when you want to save individual user data then the above logic will not work. Then we can use conversion service with a custom key converter which allows us to add a dynamic prefix to user data like user id.

# Steps to integrate spring data redis

add following dependencies into your build.gradle file or if it is maven then in pom.xml

compile group: ‘org.springframework.data’, name: ‘spring-data-redis’, version: ‘2.1.5.RELEASE’ compile group: ‘org.apache.commons’, name: ‘commons-pool2’, version: ‘2.0’ compile group: ‘redis.clients’, name: ‘jedis’, version: ‘2.9.3’

Create a custom key and converter class like.

 @AllArgsConstructor
 public class UserCacheKey {
 private String key;
}

@Getter and @AllArgsConstructor annotations are part of Lombok project which we can cover in some other article. If you are not aware of Lombok then add default setter getter methods and constructor with a key argument.

 public class UserCacheKeyConverter implements Converter<UserCacheKey, String> {
  private UserServive userService;
  public UserCacheKeyConverter(UserServive userService) {
   this.userService = userService;
 }
 @Nullable
 @Override
 public String convert(UserCacheKey userCacheKey) {
 String userId = userService.getUserId(userCacheKey);
 return String.format(“%s_%s”, userId , userCacheKey.getKey());
 }
}

Create a Redis configuration file.

@Bean(name = “userCacheManager”)
 public RedisCacheManager userCacheManager(RedisConnectionFactory 
 connectionFactory, UserService userService) {
 RedisCacheConfiguration redisCacheConfiguration = RedisCacheConfiguration.defaultCacheConfig();
 DefaultFormattingConversionService conversionService = (DefaultFormattingConversionService) redisCacheConfiguration.getConversionService();
 conversionService.addConverter(UserCacheKey.class, String.class, new UserCacheKeyConverter(userService));
 redisCacheConfiguration
 .entryTtl(Duration.ofSeconds(1800)).withConversionService(conversionService)
 .disableCachingNullValues();
 return RedisCacheManager.builder(connectionFactory)
 .cacheDefaults(redisCacheConfiguration)
 .withInitialCacheConfigurations(Collections.singletonMap(“user-cache”, redisCacheConfiguration))
 .build();
 }

so here we are creating a RedisCacheManager which will handle only user cache related operations. Anywhere we can inject this RedisCacheManager as a named bean userCacheManager (@Qualifier(userCacheManager)) and perform the relevant operations like

Cache cache = userCacheManager.getCache(“user-cache”);
 UserCacheKey cacheKey = new UserCacheKey(“some-user-data”);
 Cache.ValueWrapper result = cache != null ? cache.get(cacheKey) : null;
 if(result.get()!=null){
 // get the data and proceed 
 }else{
 cache.put(cacheKey, userData);
 }

So whenever you will call cache.get method first it will call cache converter and convert the key. It will help us to abstract the cache logic and reduce complexity.

If you found this helpful or would like to chat about anything related to web or mobile development; drop a comment below. I’d love to discuss. Stay tuned for more content.

Clash Of ClassLoaders

Sumit — Sun, 03 Mar 2019 05:56:36 +0000

In the world of code sometimes situations are like you are trying to build a Burj Khalifa but stuck at first basement only recently I came across with a similar situation where I was working on an OAuth project where I was dealing with all complex security-related stuff and assuming that soon I will inaugurate my Burj Khalifa but I was stuck between Clash of ClassLoaders .

In this article, I will explain about spring boot and apache ignite integration and how spring will override default java class loaders.
you can find spring-boot ignite implementation code on GitHub
I was caching one of the user object and its properties like roles in ignite cache as an object, so at the time of retrieval I am getting an exception like

java.lang.IllegalStateException: Cached value is not of required type [cacheName=boot_ignite_cache, key=user_data, val=com.boot.ignite.bootignite.dto.User@1ae2cec9, requiredType=class com.boot.ignite.bootignite.dto.User] at org.apache.ignite.cache.spring.SpringCache.get(SpringCache.java:77) ~[ignite-spring-2.7.0.jar:2.7.0]

After spending ample amount of time I realized there is something serious problem and I have forgotten my basics and started reading about classloaders and soon I diagnosed the problem that spring is way more friendly then we thought . Spring is using something called restart classloaders The restart technology provided by Spring Boot works by using two classloaders.

Classes that do not change (for example, those from third-party jars) are loaded into a base classloader.Classes that you are actively developing are loaded into a restart classloader . When the application is restarted, the restart classloader is thrown away and a new one is created. This approach means that application restarts are typically much faster than “cold starts”, since the base classloader is already available and populated.

So my user object loaded by spring boot restart class loader and ignite object is loaded by default class loader both the class are different.
The solution is either not to use spring dev tools which nobody wants or either create a spring-devtools.properties file and exclude the classes.

Thanks for reading !!! Keep growing Keep Going !!!