Blankj/AndroidUtilCode · info · UnsupportedOperationException

u can't instantiate me...

Error message

u can't instantiate me...

What it means

ColorUtils is a final utility class whose only constructor is private and throws UnsupportedOperationException("u can't instantiate me..."). All functionality is exposed as static methods, so no instance is ever needed. The constructor exists purely to block subclassing/instantiation; the message is the library's standard guard across all *Utils classes.

Source

Thrown at lib/utilcode/src/main/java/com/blankj/utilcode/util/ColorUtils.java:22

import androidx.annotation.ColorInt;
import androidx.annotation.ColorRes;
import androidx.annotation.FloatRange;
import androidx.annotation.IntRange;
import androidx.annotation.NonNull;
import androidx.core.content.ContextCompat;

/**
 * <pre>
 *     author: Blankj
 *     blog  : http://blankj.com
 *     time  : 2019/01/15
 *     desc  : utils about color
 * </pre>
 */
public final class ColorUtils {

    private ColorUtils() {
        throw new UnsupportedOperationException("u can't instantiate me...");
    }

    /**
     * Returns a color associated with a particular resource ID.
     *
     * @param id The desired resource identifier.
     * @return a color associated with a particular resource ID
     */
    public static int getColor(@ColorRes int id) {
        return ContextCompat.getColor(Utils.getApp(), id);
    }

    /**
     * Set the alpha component of {@code color} to be {@code alpha}.
     *
     * @param color The color.
     * @param alpha Alpha component \([0..255]\) of the color.
     * @return the {@code color} with {@code alpha} component

View on GitHub (pinned to 7b4caf9e54)

Solutions

  1. Stop trying to construct an instance: every ColorUtils method is static, call them as ColorUtils.getColor(...) etc.
  2. If a tool/framework forces instantiation, configure it to skip final utility classes or add an exclusion for ColorUtils.
  3. For a test asserting the contract, expect UnsupportedOperationException (or AssertionError if you use AssertJ's assertThatThrownBy) rather than trying to use the instance.

Example fix

// before (fails via reflection)
ColorUtils cu = ColorUtils.class.getDeclaredConstructor().newInstance();

// after
int color = ColorUtils.getColor(R.color.my_color);
Defensive patterns

Strategy: validation

Validate before calling

// Never construct ColorUtils; it is static-only.
// If a framework forces instantiation, skip final utility classes:
if (clazz == ColorUtils.class || Modifier.isFinal(clazz.getModifiers())) {
    // skip instantiation; call static methods instead
}

Type guard

// Reflection should not target final *Utils classes
if (clazz.getName().endsWith("Utils") && Modifier.isFinal(clazz.getModifiers())) {
    // do not attempt newInstance(); use static API
}

Try / catch

try {
    Constructor<?> c = ColorUtils.class.getDeclaredConstructor();
    c.setAccessible(true);
    c.newInstance();
} catch (UnsupportedOperationException e) {
    // expected: class is static-only. Use ColorUtils.xxx() instead.
}

Prevention

When it happens

Trigger: Reflection-based instantiation: getDeclaredConstructor().setAccessible(true).newInstance(), or passing the Class to a reflection utility. Direct `new ColorUtils()` will not compile because the constructor is private, so this only surfaces at runtime via reflection.

Common situations: Code-coverage/quality tools that walk all classes and instantiate them; test harnesses verifying the no-instantiation contract; a developer wrongly assuming instance methods are required; dependency-injection containers that scan and instantiate classes reflectively.

Related errors

AI-assisted analysis of Blankj/AndroidUtilCode@7b4caf9e54 (2026-08-14). Data as JSON: /api/errors/6e38aa2116626e68. Report an issue: GitHub.