Objenesis instantiates Java objects without running their constructors

The problem is the constructor, not the allocation

The repository description is the clearest statement of the motivation. It is okay to instantiate objects in Java through standard reflection, but there are many cases where you need to go beyond what reflection provides, for example when there is no public constructor and you want to bypass the constructor code, or when you need to set final fields. There are numerous clever but fiddly approaches to getting around this, and this library provides a simple way to get at them. The distinction that matters is between allocating memory and running code. Every object needs memory, and the JVM will happily give you an instance of almost any class through the standard allocation paths. What the JVM will not do is let you skip the constructor of a class whose constructor is private, absent, or takes arguments you cannot supply, and that is the specific wall this library pushes against.

It is a library, not a framework, and it is on Maven Central

Objenesis is deliberately narrow. The README describes it as a library dedicated to bypassing the constructor when creating an object, and says that on any JVM there is. The website and the user documentation are at objenesis.org, and the project is published to Maven Central under the group and artifact naming that the badge in the README shows. That single-artifact, small-surface shape is the reason it can sit underneath other tools. In practice you are likely to encounter it as a transitive dependency rather than choosing it directly, because the mocking libraries use it, and it is that arrangement that makes understanding it useful even if you never add it to a pom yourself. The repository also carries a SupportedJVMs.md file, which is the document to read before assuming a particular JVM will behave.

The source tree is split into a core library, a test kit and a compatibility layer

The top level of the repository shows a project with more going on than a single class. There is a main/ directory for the library itself, an exotic/ directory, a test/ directory and a module-test/ directory, a tck/ directory and a tck-android/ directory, a benchmark/ directory, a website/ directory for the documentation site, and a pom.xml at the root along with the Maven wrapper. The tck directories are the part worth understanding, because they are a technology compatibility kit, and the README documents a dedicated Android TCK run with its own Maven profile. Running it needs the Android SDK, platform-tools and build-tools, an ANDROID_HOME pointing at the SDK, and a device or emulator on API 26, because later API levels ask for a signature the project does not support yet. That constraint tells you the project treats different JVM implementations as a real compatibility surface rather than an afterthought.

Two build profiles, one plain and one that does the extra work

The build instructions describe two levels and the distinction is simple. A build without any active profile is a basic compilation of the application, and the full build additionally creates the source and javadoc jars and runs spotbugs. The other profiles are more specialised: one packages for the Android TCK, one runs the benchmarks, one generates the website, and an all profile groups the housekeeping tasks. The benchmark run is two commands, a Maven package with the benchmark profile followed by a script launch in the benchmark directory.

mvn package -Pbenchmark
cd benchmark
./launch.sh

The developer environment the README describes is Maven 3.9.11 with IntelliJ Ultimate, and it notes Eclipse should work as well, along with importing the shared formatting file so the code style matches the project. The repository also enforces a reproducible build policy,

# Checks that all plugins are compatible
mvn artifact:check-buildplan -Pfull,all
# Build and install the artifact
mvn clean install -Pfull,all
# Build and compare the artifact with the installed one

with the claim that a build always creates the same result from the same sources, following the Maven reproducible build guidelines.

Releasing is scripted, and rollback is documented

The release section is unusually detailed for a library, and it reads like a runbook. Release notes go into a file in the website content directory, and there is a shell snippet that reads the project version out of Maven, looks up the matching GitHub milestone through the API, and generates the version heading and an unordered list of the issues and pull requests attached to that milestone. The deploy script then asks questions, normally acknowledged with the proposed default, and the instructions are followed. What makes this section valuable is the rollback path that follows it,

<servers>
   <server>
      <id>ossrh</id>
      <username>sonatypeuser</username>
      <password>sonatypepassword</password>
   </server>
</servers>

since a failed release can be undone with a Maven rollback command, deleting the tag, pushing the tag deletion, and resetting the repository, and a staging repository can be dropped if it goes wrong further back. There is also a separate script for deploying the documentation site, with the instruction to confirm the pom is at the version you want to release first.

The honest limitation is that the object is not initialised

The design decision that makes Objenesis useful is also the one that constrains it. A bypassed constructor means the invariants the constructor would have established are absent: final fields hold whatever the JVM leaves in them, collections are null rather than empty, and any subclass initialisation never ran. That is precisely why the library is a tool for test and mocking contexts rather than a general purpose factory, and why a framework that uses it will normally set the fields it cares about immediately afterwards. The alternative approaches named in the repository description, the clever but fiddly ones, have the same property, so switching implementations of the bypass does not change the semantics. The second limitation is about the toolchain rather than the object: the project maintains compatibility across JVM implementations, including an Android run, and the README points to the SupportedJVMs document for the current scope, which is where you should look before relying on behaviour for a specific runtime.

Editorial conclusion

Objenesis suits a developer writing a mocking framework or a test that needs an instance of a class with no usable constructor, and who understands that the resulting object is uninitialised. It does not suit ordinary production code, because skipping a constructor skips the invariants that constructor establishes, and it does not replace Mockito, since the two are usually used together rather than against each other. Before adopting, read the SupportedJVMs.md file in the repository root for the JVM versions in scope, and note that the last push to the repository was on 2026-10-19 with release 3.6 from 2026-08-02.

Frequently asked questions

Official sources

1. easymock/objenesis on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases