Automatically Adding a Private Constructor with Sensei
Automatically Adding a Private Constructor with Sensei
In a utility class, when the fields and methods are static, there is no obvious reason why I would ever instantiate it.
e.g. UtilityClass utility = new UtilityClass();
The code below is a simple implementation of a Utility class.
public class UtilityClass {
public static final Boolean ULTIMATE_TRUTH = true;
public static boolean getTrue(){
return ULTIMATE_TRUTH;
}
}
This is the type of coding pattern that Static Analysis tools can pick up, but they often don't supply the ability to fix the issue.
I can use Sensei to identify the coding pattern, and automatically generate a private constructor to make it impossible for me to instantiate the class.
Searching for the Class
I will add a new recipe on the Utility class called:
- Static Classes: create private constructor.

And initially, I'll create a simple matcher to search for a class.
search:
class: {}
This will match any class, which is good enough to let me get started writing a Quick Fix. Once I have a Quick Fix that works, I'll refine the search to make it highlight when there is more likely to be a class that requires a private constructor.

Quick Fix
For the Quick Fix, I will want to generate a private constructor.
In the example class this would look like:
private UtilityClass(){}
To add the above code to my class, my Quick Fix will add a Method, and the name of the method will be a Mustache template that uses the name of the class.
availableFixes:
- name: "add private constructor"
actions:
- addMethod:
method: "private {{{ name }}}(){}"
In the GUI Editor, I use the Show Variables to create the Mustache template and then edit the field to add the private modifier, brackets, and braces to make it syntactically correct.

This would now allow me to add a private constructor to any class.
The QuickFix preview helps me because I can see the generated code as I write the Mustache template.

Now that I know I can fix the problem. I'll refine the search conditions to show the recipe when it is most appropriate.
Search for Missing Constructors
Ideally, I don't want to create a recipe that flags an error against every class. So I'll add some additional conditions in the search so that we only match on classes that do not have a constructor.
search:
class:
without:
child:
method:
constructor: true
The YAML is slightly different from the GUI.
In the GUI I configure it to look for a class without a child method which is a constructor 'yes'. We use 'yes' in the GUI instead of 'true' to make the GUI a little more human friendly.

This recipe will now only reveal itself for any class without a constructor.
Narrow Search for Likely Culprits
So I might want to go further and look for the presence of static methods or fields.
I look for any class without a constructor and which has either all public static fields or all public static methods.
search:
class:
with:
anyOf:
- child:
method:
allOf:
- modifier: "public"
- modifier: "static"
- child:
field:
allOf:
- modifier: "static"
- modifier: "public"
without:
child:
method:
constructor: true
Since Sensei is used to help me, as a programmer, in the IDE, rather than to statically analyze the code and report all errors, this filter is good enough to rule out most classes in my code base where I might have a good reason to have a default public constructor.
In some projects, this might be a step too far because the utility classes could have private methods, so I might choose to look for the presence of 'any' public static methods, rather than 'all'.
- child:
field:
anyOf:
- modifier: "static"
- modifier: "public"
Hints
Sensei is not designed to replace a Static Analysis tool. Sensei can augment a Static Analysis tool for common issues associated with your coding process, or technology. By replicating enough of the matching to highlight an issue, and supporting the development process by generating the QuickFix code.
What I'm trying to do is create a simple enough recipe that includes all the situations I need it, but filter it so that it doesn't get suggested in every class.
When working on recipes I try to de-risk them, in this case, I wasn't sure if I could create the private constructor so I created the QuickFix first. Then refactored the search conditions to make them more specific.
Sometimes when working on recipes I'm not sure how to perform the search, so I work on that first.
I find recipes easier to create when I build them incrementally, switching between refactoring of the QuickFix and the search.
---
You can install Sensei from within IntelliJ using "Preferences \ Plugins" (Mac) or "Settings \ Plugins" (Windows) then just search for "sensei secure code"
The source code and recipes for this can be found in the `sensei-blog-examples` repository in the Secure Code Warrior GitHub account, in the `pojoexamples` module.
https://github.com/securecodewarrior/sensei-blog-examples


Learn how Sensei can identify a coding pattern, and automatically generate a private constructor to make it impossible to instantiate the class.
Alan Richardson has more than twenty years of professional IT experience, working as a developer and at every level of the testing hierarchy from Tester through to Head of Testing. Head of Developer Relations at Secure Code Warrior, he works directly with teams, to improve the development of quality secure code. Alan is the author of four books including “Dear Evil Tester”, and “Java For Testers”. Alan has also created online training courses to help people learn Technical Web Testing and Selenium WebDriver with Java. Alan posts his writing and training videos on SeleniumSimplified.com, EvilTester.com, JavaForTesters.com, and CompendiumDev.co.uk.

Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoAlan Richardson has more than twenty years of professional IT experience, working as a developer and at every level of the testing hierarchy from Tester through to Head of Testing. Head of Developer Relations at Secure Code Warrior, he works directly with teams, to improve the development of quality secure code. Alan is the author of four books including “Dear Evil Tester”, and “Java For Testers”. Alan has also created online training courses to help people learn Technical Web Testing and Selenium WebDriver with Java. Alan posts his writing and training videos on SeleniumSimplified.com, EvilTester.com, JavaForTesters.com, and CompendiumDev.co.uk.


Automatically Adding a Private Constructor with Sensei
In a utility class, when the fields and methods are static, there is no obvious reason why I would ever instantiate it.
e.g. UtilityClass utility = new UtilityClass();
The code below is a simple implementation of a Utility class.
public class UtilityClass {
public static final Boolean ULTIMATE_TRUTH = true;
public static boolean getTrue(){
return ULTIMATE_TRUTH;
}
}
This is the type of coding pattern that Static Analysis tools can pick up, but they often don't supply the ability to fix the issue.
I can use Sensei to identify the coding pattern, and automatically generate a private constructor to make it impossible for me to instantiate the class.
Searching for the Class
I will add a new recipe on the Utility class called:
- Static Classes: create private constructor.

And initially, I'll create a simple matcher to search for a class.
search:
class: {}
This will match any class, which is good enough to let me get started writing a Quick Fix. Once I have a Quick Fix that works, I'll refine the search to make it highlight when there is more likely to be a class that requires a private constructor.

Quick Fix
For the Quick Fix, I will want to generate a private constructor.
In the example class this would look like:
private UtilityClass(){}
To add the above code to my class, my Quick Fix will add a Method, and the name of the method will be a Mustache template that uses the name of the class.
availableFixes:
- name: "add private constructor"
actions:
- addMethod:
method: "private {{{ name }}}(){}"
In the GUI Editor, I use the Show Variables to create the Mustache template and then edit the field to add the private modifier, brackets, and braces to make it syntactically correct.

This would now allow me to add a private constructor to any class.
The QuickFix preview helps me because I can see the generated code as I write the Mustache template.

Now that I know I can fix the problem. I'll refine the search conditions to show the recipe when it is most appropriate.
Search for Missing Constructors
Ideally, I don't want to create a recipe that flags an error against every class. So I'll add some additional conditions in the search so that we only match on classes that do not have a constructor.
search:
class:
without:
child:
method:
constructor: true
The YAML is slightly different from the GUI.
In the GUI I configure it to look for a class without a child method which is a constructor 'yes'. We use 'yes' in the GUI instead of 'true' to make the GUI a little more human friendly.

This recipe will now only reveal itself for any class without a constructor.
Narrow Search for Likely Culprits
So I might want to go further and look for the presence of static methods or fields.
I look for any class without a constructor and which has either all public static fields or all public static methods.
search:
class:
with:
anyOf:
- child:
method:
allOf:
- modifier: "public"
- modifier: "static"
- child:
field:
allOf:
- modifier: "static"
- modifier: "public"
without:
child:
method:
constructor: true
Since Sensei is used to help me, as a programmer, in the IDE, rather than to statically analyze the code and report all errors, this filter is good enough to rule out most classes in my code base where I might have a good reason to have a default public constructor.
In some projects, this might be a step too far because the utility classes could have private methods, so I might choose to look for the presence of 'any' public static methods, rather than 'all'.
- child:
field:
anyOf:
- modifier: "static"
- modifier: "public"
Hints
Sensei is not designed to replace a Static Analysis tool. Sensei can augment a Static Analysis tool for common issues associated with your coding process, or technology. By replicating enough of the matching to highlight an issue, and supporting the development process by generating the QuickFix code.
What I'm trying to do is create a simple enough recipe that includes all the situations I need it, but filter it so that it doesn't get suggested in every class.
When working on recipes I try to de-risk them, in this case, I wasn't sure if I could create the private constructor so I created the QuickFix first. Then refactored the search conditions to make them more specific.
Sometimes when working on recipes I'm not sure how to perform the search, so I work on that first.
I find recipes easier to create when I build them incrementally, switching between refactoring of the QuickFix and the search.
---
You can install Sensei from within IntelliJ using "Preferences \ Plugins" (Mac) or "Settings \ Plugins" (Windows) then just search for "sensei secure code"
The source code and recipes for this can be found in the `sensei-blog-examples` repository in the Secure Code Warrior GitHub account, in the `pojoexamples` module.
https://github.com/securecodewarrior/sensei-blog-examples

Automatically Adding a Private Constructor with Sensei
In a utility class, when the fields and methods are static, there is no obvious reason why I would ever instantiate it.
e.g. UtilityClass utility = new UtilityClass();
The code below is a simple implementation of a Utility class.
public class UtilityClass {
public static final Boolean ULTIMATE_TRUTH = true;
public static boolean getTrue(){
return ULTIMATE_TRUTH;
}
}
This is the type of coding pattern that Static Analysis tools can pick up, but they often don't supply the ability to fix the issue.
I can use Sensei to identify the coding pattern, and automatically generate a private constructor to make it impossible for me to instantiate the class.
Searching for the Class
I will add a new recipe on the Utility class called:
- Static Classes: create private constructor.

And initially, I'll create a simple matcher to search for a class.
search:
class: {}
This will match any class, which is good enough to let me get started writing a Quick Fix. Once I have a Quick Fix that works, I'll refine the search to make it highlight when there is more likely to be a class that requires a private constructor.

Quick Fix
For the Quick Fix, I will want to generate a private constructor.
In the example class this would look like:
private UtilityClass(){}
To add the above code to my class, my Quick Fix will add a Method, and the name of the method will be a Mustache template that uses the name of the class.
availableFixes:
- name: "add private constructor"
actions:
- addMethod:
method: "private {{{ name }}}(){}"
In the GUI Editor, I use the Show Variables to create the Mustache template and then edit the field to add the private modifier, brackets, and braces to make it syntactically correct.

This would now allow me to add a private constructor to any class.
The QuickFix preview helps me because I can see the generated code as I write the Mustache template.

Now that I know I can fix the problem. I'll refine the search conditions to show the recipe when it is most appropriate.
Search for Missing Constructors
Ideally, I don't want to create a recipe that flags an error against every class. So I'll add some additional conditions in the search so that we only match on classes that do not have a constructor.
search:
class:
without:
child:
method:
constructor: true
The YAML is slightly different from the GUI.
In the GUI I configure it to look for a class without a child method which is a constructor 'yes'. We use 'yes' in the GUI instead of 'true' to make the GUI a little more human friendly.

This recipe will now only reveal itself for any class without a constructor.
Narrow Search for Likely Culprits
So I might want to go further and look for the presence of static methods or fields.
I look for any class without a constructor and which has either all public static fields or all public static methods.
search:
class:
with:
anyOf:
- child:
method:
allOf:
- modifier: "public"
- modifier: "static"
- child:
field:
allOf:
- modifier: "static"
- modifier: "public"
without:
child:
method:
constructor: true
Since Sensei is used to help me, as a programmer, in the IDE, rather than to statically analyze the code and report all errors, this filter is good enough to rule out most classes in my code base where I might have a good reason to have a default public constructor.
In some projects, this might be a step too far because the utility classes could have private methods, so I might choose to look for the presence of 'any' public static methods, rather than 'all'.
- child:
field:
anyOf:
- modifier: "static"
- modifier: "public"
Hints
Sensei is not designed to replace a Static Analysis tool. Sensei can augment a Static Analysis tool for common issues associated with your coding process, or technology. By replicating enough of the matching to highlight an issue, and supporting the development process by generating the QuickFix code.
What I'm trying to do is create a simple enough recipe that includes all the situations I need it, but filter it so that it doesn't get suggested in every class.
When working on recipes I try to de-risk them, in this case, I wasn't sure if I could create the private constructor so I created the QuickFix first. Then refactored the search conditions to make them more specific.
Sometimes when working on recipes I'm not sure how to perform the search, so I work on that first.
I find recipes easier to create when I build them incrementally, switching between refactoring of the QuickFix and the search.
---
You can install Sensei from within IntelliJ using "Preferences \ Plugins" (Mac) or "Settings \ Plugins" (Windows) then just search for "sensei secure code"
The source code and recipes for this can be found in the `sensei-blog-examples` repository in the Secure Code Warrior GitHub account, in the `pojoexamples` module.
https://github.com/securecodewarrior/sensei-blog-examples

Click on the link below and download the PDF of this resource.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
View reportBook a demoAlan Richardson has more than twenty years of professional IT experience, working as a developer and at every level of the testing hierarchy from Tester through to Head of Testing. Head of Developer Relations at Secure Code Warrior, he works directly with teams, to improve the development of quality secure code. Alan is the author of four books including “Dear Evil Tester”, and “Java For Testers”. Alan has also created online training courses to help people learn Technical Web Testing and Selenium WebDriver with Java. Alan posts his writing and training videos on SeleniumSimplified.com, EvilTester.com, JavaForTesters.com, and CompendiumDev.co.uk.
Automatically Adding a Private Constructor with Sensei
In a utility class, when the fields and methods are static, there is no obvious reason why I would ever instantiate it.
e.g. UtilityClass utility = new UtilityClass();
The code below is a simple implementation of a Utility class.
public class UtilityClass {
public static final Boolean ULTIMATE_TRUTH = true;
public static boolean getTrue(){
return ULTIMATE_TRUTH;
}
}
This is the type of coding pattern that Static Analysis tools can pick up, but they often don't supply the ability to fix the issue.
I can use Sensei to identify the coding pattern, and automatically generate a private constructor to make it impossible for me to instantiate the class.
Searching for the Class
I will add a new recipe on the Utility class called:
- Static Classes: create private constructor.

And initially, I'll create a simple matcher to search for a class.
search:
class: {}
This will match any class, which is good enough to let me get started writing a Quick Fix. Once I have a Quick Fix that works, I'll refine the search to make it highlight when there is more likely to be a class that requires a private constructor.

Quick Fix
For the Quick Fix, I will want to generate a private constructor.
In the example class this would look like:
private UtilityClass(){}
To add the above code to my class, my Quick Fix will add a Method, and the name of the method will be a Mustache template that uses the name of the class.
availableFixes:
- name: "add private constructor"
actions:
- addMethod:
method: "private {{{ name }}}(){}"
In the GUI Editor, I use the Show Variables to create the Mustache template and then edit the field to add the private modifier, brackets, and braces to make it syntactically correct.

This would now allow me to add a private constructor to any class.
The QuickFix preview helps me because I can see the generated code as I write the Mustache template.

Now that I know I can fix the problem. I'll refine the search conditions to show the recipe when it is most appropriate.
Search for Missing Constructors
Ideally, I don't want to create a recipe that flags an error against every class. So I'll add some additional conditions in the search so that we only match on classes that do not have a constructor.
search:
class:
without:
child:
method:
constructor: true
The YAML is slightly different from the GUI.
In the GUI I configure it to look for a class without a child method which is a constructor 'yes'. We use 'yes' in the GUI instead of 'true' to make the GUI a little more human friendly.

This recipe will now only reveal itself for any class without a constructor.
Narrow Search for Likely Culprits
So I might want to go further and look for the presence of static methods or fields.
I look for any class without a constructor and which has either all public static fields or all public static methods.
search:
class:
with:
anyOf:
- child:
method:
allOf:
- modifier: "public"
- modifier: "static"
- child:
field:
allOf:
- modifier: "static"
- modifier: "public"
without:
child:
method:
constructor: true
Since Sensei is used to help me, as a programmer, in the IDE, rather than to statically analyze the code and report all errors, this filter is good enough to rule out most classes in my code base where I might have a good reason to have a default public constructor.
In some projects, this might be a step too far because the utility classes could have private methods, so I might choose to look for the presence of 'any' public static methods, rather than 'all'.
- child:
field:
anyOf:
- modifier: "static"
- modifier: "public"
Hints
Sensei is not designed to replace a Static Analysis tool. Sensei can augment a Static Analysis tool for common issues associated with your coding process, or technology. By replicating enough of the matching to highlight an issue, and supporting the development process by generating the QuickFix code.
What I'm trying to do is create a simple enough recipe that includes all the situations I need it, but filter it so that it doesn't get suggested in every class.
When working on recipes I try to de-risk them, in this case, I wasn't sure if I could create the private constructor so I created the QuickFix first. Then refactored the search conditions to make them more specific.
Sometimes when working on recipes I'm not sure how to perform the search, so I work on that first.
I find recipes easier to create when I build them incrementally, switching between refactoring of the QuickFix and the search.
---
You can install Sensei from within IntelliJ using "Preferences \ Plugins" (Mac) or "Settings \ Plugins" (Windows) then just search for "sensei secure code"
The source code and recipes for this can be found in the `sensei-blog-examples` repository in the Secure Code Warrior GitHub account, in the `pojoexamples` module.
https://github.com/securecodewarrior/sensei-blog-examples
Table of contents
Alan Richardson has more than twenty years of professional IT experience, working as a developer and at every level of the testing hierarchy from Tester through to Head of Testing. Head of Developer Relations at Secure Code Warrior, he works directly with teams, to improve the development of quality secure code. Alan is the author of four books including “Dear Evil Tester”, and “Java For Testers”. Alan has also created online training courses to help people learn Technical Web Testing and Selenium WebDriver with Java. Alan posts his writing and training videos on SeleniumSimplified.com, EvilTester.com, JavaForTesters.com, and CompendiumDev.co.uk.

Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoDownloadResources to get you started
Secure by Design: Defining Best Practices, Enabling Developers and Benchmarking Preventative Security Outcomes
In this research paper, Secure Code Warrior co-founders, Pieter Danhieux and Dr. Matias Madou, Ph.D., along with expert contributors, Chris Inglis, Former US National Cyber Director (now Strategic Advisor to Paladin Capital Group), and Devin Lynch, Senior Director, Paladin Global Institute, will reveal key findings from over twenty in-depth interviews with enterprise security leaders including CISOs, a VP of Application Security, and software security professionals.
Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise
Finding meaningful data on the success of Secure-by-Design initiatives is notoriously difficult. CISOs are often challenged when attempting to prove the return on investment (ROI) and business value of security program activities at both the people and company levels. Not to mention, it’s particularly difficult for enterprises to gain insights into how their organizations are benchmarked against current industry standards. The President’s National Cybersecurity Strategy challenged stakeholders to “embrace security and resilience by design.” The key to making Secure-by-Design initiatives work is not only giving developers the skills to ensure secure code, but also assuring the regulators that those skills are in place. In this presentation, we share a myriad of qualitative and quantitative data, derived from multiple primary sources, including internal data points collected from over 250,000 developers, data-driven customer insights, and public studies. Leveraging this aggregation of data points, we aim to communicate a vision of the current state of Secure-by-Design initiatives across multiple verticals. The report details why this space is currently underutilized, the significant impact a successful upskilling program can have on cybersecurity risk mitigation, and the potential to eliminate categories of vulnerabilities from a codebase.
Secure code training topics & content
Our industry-leading content is always evolving to fit the ever changing software development landscape with your role in mind. Topics covering everything from AI to XQuery Injection, offered for a variety of roles from Architects and Engineers to Product Managers and QA. Get a sneak peak of what our content catalog has to offer by topic and role.
Resources to get you started
Revealed: How the Cyber Industry Defines Secure by Design
In our latest white paper, our Co-Founders, Pieter Danhieux and Dr. Matias Madou, Ph.D., sat down with over twenty enterprise security leaders, including CISOs, AppSec leaders and security professionals, to figure out the key pieces of this puzzle and uncover the reality behind the Secure by Design movement. It’s a shared ambition across the security teams, but no shared playbook.
Is Vibe Coding Going to Turn Your Codebase Into a Frat Party?
Vibe coding is like a college frat party, and AI is the centerpiece of all the festivities, the keg. It’s a lot of fun to let loose, get creative, and see where your imagination can take you, but after a few keg stands, drinking (or, using AI) in moderation is undoubtedly the safer long-term solution.