Gradle build: bootstrap class path not set in conjunction with -source 1.7

Published by Tomas Zezula on

Building of a Gradle project yields the following warning:

:compileJavawarning: [options] bootstrap class path not set in conjunction with -source 1.7
1 warning

That happens whenever the project is compiled to be compatible with an older Java version compared to the installed JDK (Java 8 in my case).

build.gradle
apply plugin: 'java'
sourceCompatibility = 1.7
...

The warning indicates that Gradle has no access to the legacy JDK (1.7). The issue is in fact with the Java compiler. According to the javac docs you are supposed to provide path to the bootstrap classes rt.jar.

You can easily verify the issue is not with Gradle. Let’s pick any of your source files and try to compile them.

Check the installed JDK

$ java -version java version "1.8.0_51" Java(TM) SE Runtime Environment (build 1.8.0_51-b16) Java HotSpot(TM) 64-Bit Server VM (build 25.51-b03, mixed mode)

Compile the source code with default settings

$ javac src/main/java/Library.java

No warnings, all is good. Now specify the -source flag, which is equivalent to the souceCompatibility property in your build file.

$ javac -source 1.7 src/main/java/Library.java warning: [options] bootstrap class path not set in conjunction with -source 1.7 1 warning

See? You get the same warning you were getting when running gradle build. Now add the -target flag, which maps to targetCompatibility in Gradle’s Java plugin.

$ javac -source 1.7 -target 1.7 src/main/java/Library.java warning: [options] bootstrap class path not set in conjunction with -source 1.7

That change had no effect, because … let me quote the javac docs:

You must specify the -bootclasspath option to specify the correct version of the bootstrap classes (the rt.jar library). If not, then the compiler generates a warning:

javac -source 1.7 OldCode.java
warning: [options] bootstrap class path not set in conjunction with -source 1.7

Categories: Build AutomationTips & Tricks

Tomas Zezula

Hello! I'm a technology enthusiast with a knack for solving problems and a passion for making complex concepts accessible. My journey spans across software development, project management, and technical writing. I specialise in transforming rough sketches of ideas to fully launched products, all the while breaking down complex processes into understandable language. I believe a well-designed software development process is key to driving business growth. My focus as a leader and technical writer aims to bridge the tech-business divide, ensuring that intricate concepts are available and understandable to all. As a consultant, I'm eager to bring my versatile skills and extensive experience to help businesses navigate their software integration needs. Whether you're seeking bespoke software solutions, well-coordinated product launches, or easily digestible tech content, I'm here to make it happen. Ready to turn your vision into reality? Let's connect and explore the possibilities together.

Related Posts

Failed Gradle build
Kotlin

Gradle Multi-Module Builds: Setting Up Shared Dependencies

When you are managing a multi-module Gradle project, more often than not you'd want to share certain dependencies across different modules. This is particularly true for test dependencies. You can achieve this by defining common dependencies in the root build file and applying them to all subprojects. However, a problem often encountered is the dreaded Unresolved reference: testImplementation error. This blog post suggests a simple trick that resolves the issue. Give it a go and happy testing ever after!

Kotlin

Keep Data Safe in Multi-Tenant Systems: A Case for Supabase and Row Level Security

When managing multi-tenant systems, one common anxiety is that a coding error can unintentionally expose user data. Incorrectly routing a user's data to the wrong tenant, or even distributing it to another user within the same tenant, is a very real fear. Additional precautions are necessary to safeguard against human errors. Supabase is an open-source platform that offers a viable alternative to Firebase. Similar to Firebase, it provides a frictionless user authentication process. Due to its integration with Postgres, it supports sophisticated access controls at a row level, aptly referred to as Row-Level Security (RLS). In this article, we'll explore a concrete example of leveraging this feature and provide step-by-step implementation guidelines.

Featured image
Stripe

Stripe Payment Links and Custom Parameters

As of now, Stripe's Payment Links don't offer the flexibility of adding custom fields beyond those available in the API. The fields that you can directly pass into the Payment Links endpoint are complementary identifiers like prefilled_email or client_reference_id. This post shows some of the workarounds you can use to enrich your payment links with additional custom parameters.