Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Allow package-private planning domain classes and methods

Abierto
  • ¿Algo no está bien?
#2,160 6 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

  • #1 de @theoema — cerrado sin fusionar
  • #2168 de @theoema — cerrado sin fusionar

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
java
Área
backend

Línea de trabajo

Start by reading MemberAccessorValidator and ReflectionHelper to trace where non-public classes and methods are rejected or missed. Then inspect ReflectionBeanPropertyMemberAccessor and GizmoMemberAccessorImplementor to understand the existing fallback constraints. Done means package-private planning classes, getters, and setters are discoverable and usable without changing behavior for public classes.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Problem

Timefold requires all planning domain classes, getters, and setters to be public. This is enforced by MemberAccessorValidator, but the underlying accessor layer already handles non-public access — making this restriction unnecessary.

The contradiction

The reflection-based accessor already calls setAccessible(true) and creates a MethodHandle that works fine with non-public methods:

// ReflectionBeanPropertyMemberAccessor.java
public ReflectionBeanPropertyMemberAccessor(Method getterMethod, AnnotatedElement annotatedElement, boolean getterOnly) {
    this.getterMethod = getterMethod;
    MethodHandles.Lookup lookup = MethodHandles.lookup();
    this.getterMethod.setAccessible(true);                          // ← handles non-public
    this.getherMethodHandle = lookup.unreflect(getterMethod)        // ← creates fast MethodHandle
            .asFixedArity();
    // ...
}

At runtime, it invokes via MethodHandle, not raw Method.invoke():

public Object executeGetter(Object bean) {
    return getherMethodHandle.invoke(bean);  // MethodHandle — JIT-optimized to direct call
}

But MemberAccessorValidator rejects non-public members before the accessor ever gets a chance:

// MemberAccessorValidator.java — declaring class gate
private static void verifyDeclaringClassIsAccessible(Member member, String messagePrefix) {
    var declaringClass = member.getDeclaringClass();
    if (!Modifier.isPublic(declaringClass.getModifiers())) {
        throw new IllegalArgumentException(
                "%s is not accessible because its declaring class (%s) is not public."
                    .formatted(messagePrefix, declaringClass.getCanonicalName()));
    }
}

// MemberAccessorValidator.java — repeated across verifyFieldOrGetter, verifyIsVoidMethod,
// verifyIsPublicFieldOrHasReadMethod, verifyGetterSetterProperties
if (!Modifier.isPublic(method.getModifiers())) {
    throw new IllegalArgumentException(
            "%s is a getter method, but it is not public."
                .formatted(messagePrefix));
}

There's also a discovery-layer issue — ReflectionHelper uses Class.getMethod() which only returns public methods, so package-private getters are invisible before validation even runs.

What about Gizmo performance?

The Gizmo path generates bytecode with direct invokeVirtual instructions, which requires public access. However, the reflection path already uses MethodHandle — which the JVM JIT-compiles to the same direct call after warmup:

Path Runtime execution After JIT
Gizmo invokeVirtual bytecode direct call
Reflection (MethodHandle) MethodHandle.invoke() direct call (inlined)

For non-public members, falling back to the MethodHandle-based reflection path carries no meaningful performance penalty. The Gizmo implementor itself documents this constraint:

// GizmoMemberAccessorImplementor.java (line 353)
// The member MUST be public if not called in Quarkus
// (i.e. we don't delegate to the field getter/setter).
Why this matters

Package-private domain models are a standard Java encapsulation pattern. In modular codebases, it's common to keep domain classes package-private and expose only the API boundary publicly. Today you're forced to write:

// Everything must be public even though nothing outside this package needs access
public class Lesson {
    public Timeslot getTimeslot() { ... }
    public void setTimeslot(Timeslot timeslot) { ... }
}

This would enable:

class Lesson {
    Timeslot getTimeslot() { ... }
    void setTimeslot(Timeslot timeslot) { ... }
}
Scope

This is a small change — no behavior change for existing public classes, no performance impact, and the accessor infrastructure already supports it.

Lenguaje dominante
Java
Estrellas
1.8k
Forks
238
Merge medio
3 d 2 h
PR fusionados (30 d)
59

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de TimefoldAI/timefold-solver

Todos los issues de TimefoldAI/timefold-solver

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.