VERSION.txt

Java ClassMate project: licensed under Apache License 2.0
(http://www.apache.org/licenses/LICENSE-2.0.txt)

Release notes:

1.8.1 (not yet released)

- Upgrade to JUnit 5

1.8.0 (10-Oct-2026)

#125: Generic array types compare equal and collide in the resolver cache
 (reported, fix contributed by 박재홍, @PHJ2000)
- Array types no longer retain type bindings of the enclosing type; equality
  of `ResolvedArrayType` now includes element type (self-referential element
  types are compared by erased type and type bindings)
- Raw types (like raw `Map` field, or raw supertype) no longer retain type bindings
  of the enclosing type: type parameters resolve to their bounds instead
  (f.ex raw `Map` within `Holder<String>` is now `Map<Object,Object>`, not `Map<String>`)
- `TypeResolver.resolve(TypeBindings, Type)` no longer applies given bindings
  to a `Class` passed as `Type` (f.ex bindings of `List<String>` with `List.class`
  now result in `List<Object>`); use `resolve(Type, Type...)` instead
- Array types are cached by `TypeResolver` using element type as part of the key
- Types with `TypePlaceHolder`s (from `resolveSubtype()`) or self-references
  (`ResolvedRecursiveType`) in their type parameters (at any level of nesting,
  including array element types) are no longer cached
#127: `resolveSubtype()` does not verify or resolve array element types
- `resolveSubtype()` now rejects type variable bound to conflicting types
  (like `E` in `Dup<E> extends Pair<E[], E>`; except that `Object`, which may
  come from wildcard or raw type, is compatible with more specific type at any
  level of nesting, like `List<?>` with `List<String>`) and primitive types bound
  to type variables (like `int` for `E` in `E[]`)
- Self-references (`ResolvedRecursiveType`) only valid within their original
  resolution context (like ones in type parameters of `getParentClass()`) are no
  longer included in types returned by `resolveSubtype()`: raw self-references
  resolve to their bounds, others to the referenced type (self-references to
  enclosing type, like in raw `Enum`, are retained as-is)
- `TypeResolver.resolve(Type, Type...)` and `TypeBindings.create()` now fail with
  `IllegalArgumentException` if any of type parameters is a primitive type
  (like `resolve(List.class, int.class)`)
 (fix by @cowtowncoder w/ Claude code)
#128: Self-references via supertypes still cached; self-references not equal
  to fully resolved types
- Types containing self-references to types still being resolved (like `B` in
  `B extends Base<A>` when resolving `A extends Base<B>`) are no longer cached,
  and are re-resolved when used later (like for member types)
- Self-references (`ResolvedRecursiveType`) nested in type parameters or array
  element types are equal to fully resolved types with same type bindings
  (so f.ex raw `Enum` is now equal to `Enum<Enum<Object>>`)
- Raw self-references have type parameters resolved to bounds, like other raw types
  (except ones created while resolving bounds of the type itself, like `T` in
  `RawBound<T extends RawBound>`; types containing those may also be shared)
- Self-references with bindings different from referenced type (like raw `Mid`
  within `Mid<String>`, or `N<N<T>>` within `N<T>`) now represent type with own
  bindings: see new `ResolvedRecursiveType.getActualType()` (also used for
  `getParentClass()`, members and `resolveSubtype()`)
 (fix by @cowtowncoder w/ Claude code)
#130: `resolveSubtype()` does not verify bounds of type variables
- `resolveSubtype()` now rejects type variable bound to type that can not satisfy
  its bounds (like `String` for `E extends Number`); check is lenient since bindings
  from wildcards and raw types are not distinguished from exact ones: only types that
  can not have a common subtype with bound (as per Java casting rules) are rejected
 (fix by @cowtowncoder w/ Claude code)
#132: `MemberResolver` misses members inherited via self-referential interface
  (`ResolvedRecursiveType` as implemented interface)
- `getImplementedInterfaces()` returns types self-referential interfaces represent
  (same as `getParentClass()`): for expanding generic types (like `D<T>` for
  `C<T> extends Base<D<T>>`, `D<T> extends C<List<T>>`), following supertypes and
  their type parameters may yield ever deeper types
- `ResolvedRecursiveType.getActualType()` returns stand-alone type if referenced
  type is only valid within its resolution context (like `B` in `B extends Base<A>`,
  when resolving `A extends Base<B>`)
 (fix by @cowtowncoder w/ Claude code)
#133: Member type of bare type variable bound to self-reference is `ResolvedRecursiveType`
  (unlike `T[]` or `List<T>`)
- `TypeResolver.resolve(TypeBindings, Type)` (used by `MemberResolver`) and
  `resolve(Type, Type...)` now return type self-reference represents (instead of
  `ResolvedRecursiveType`) when given type resolves to a self-reference: f.ex type of
  field `X value` of `Base<X>`, inherited by `Sym<T extends Sym<T>> extends Base<T>`
- Same for element type of array constructed with `TypeResolver.arrayType(Type)`
- NOTE: potentially incompatible change: member types (and results of above methods)
  are never `ResolvedRecursiveType`s now, so code that relies on
  `TypeResolver.isSelfReference()` (or `getSelfReferencedType()`) of member types
  to detect cycles needs to use other means (like tracking types already visited)
 (fix by @cowtowncoder w/ Claude code)
#137: Supertype lookups (`findSupertype()`) on a self-reference (`ResolvedRecursiveType`)
  return `null`
- `ResolvedRecursiveType.findSupertype()` (and so `typeParametersFor()`) now looks up
  supertypes from type self-reference represents (`getActualType()`); `getParentClass()`
  and `getImplementedInterfaces()` of self-references still return no supertypes
- NOTE: `findSupertype()` with erased type of self-reference itself now returns the
  type it represents, instead of the self-reference (so it is no longer
  `ResolvedRecursiveType`)
 (fix by @cowtowncoder w/ Claude code)

1.7.3 (02-Jan-2026)

#117: Regression in 1.7.2 (wrt #53) causes `StackOverflowError` for some recursive types
 (reported by Marcin E)

1.7.2 (27-Dec-2025)

#53: Allow for subtype resolution with unknown generics
 (reported by Carsten W, @CarstenWickner)
- Update to `oss-parent` v74

1.7.1 (26-Sep-2025)

- Branch "master" renamed as "main"
- Update to `oss-parent` v69 to switch to Central Portal publishing

1.7.0 (02-Jan-2024)

#51: `TypeResolver.resolve(Long[].class)` should not return a `ResolvedType`
  whose parent type is null
 (reported by @ljnelson)
#75: Move JDK baseline to Java 8
 (contributed by Dave B, @mebigfatguy)
#83: Simplify code by not calling `Set.contains()` before `add()`
- Remove `Automatic-Module-Name` since we provide proper module-info

1.6.0 (10-Oct-2023)

#70: Remove dead allocation
 (reported by Dave B, @mebigfatguy)
#73: Make `GenericType` not implement `Serializable`
- Oss-parent to version 55 (junit version, javadoc links, jacoco)

1.5.1 (20-Oct-2019)

- Patch release to satisfy odd metadata requirements of a security tool
  (wrt https/http for `url` in pom.xml)

1.5.0 (23-Mar-2019)

#43: Missing synchronization on `ResolvedObjectType#getConstructors`
 (reported by pkwarren@github)
- Add JDK9+ module-info using Moditect plugin

1.4.0 (27-Mar-2018)

#41: Make cache used by `TypeResolver` pluggable; offer concurrent
  variant in addition to LRU

1.3.4 (09-Sep-2017)

#38: Add `Automatic-Module-Name` for JDK9 interoperability

1.3.3 (28-Sep-2016)

#33: "ghost" type parameter in field
 (reported, fix contributed by web-online@github)

1.3.2 (25-Sep-2016)

#30: ArrayIndexOutOfBoundsException when resolving Object.class
 (reported by meszibalu@github)

1.3.1 (25-Oct-2015)

- Fix a problem with caching of subtype-extended types, causing problems
  due to mutable `TypePlaceHolder`

1.3.0 (16-Sep-2015)

#28: Parametrised classes does not resolve method types properly
 (reported by dawrut@github)

1.2.0 (22-May-2015)

#22: ResolvedTypeWithMembers should expose static fields as well
 (proposed by arikkfir@github)
- Made `ResolvedMethod`, `ResolvedField` sortable to simplify tests
- More unit tests, from Jackson type resolver fails

1.1.0 (19-Aug-2014)

#16: ClassCastException in TypeResolver (ResolvedRecursiveType cannot be cast to ResolvedObjectType)
 (reported by deki@github)

1.0.0 (15-Oct-2013)

The official Big One-Oh version!

(no functional changes since 0.9.0)

0.9.0:

#14: Fixed 2 unit tests that failed with JDK 1.7 (due to addition of members to 'java.lang.Object`
  and `java.util.ArrayList`)
#15: ClassMate jar should include LICENSE file

0.8.0:

* Combine various ResolvedType.resolve(...) methods, using `java.lang.reflect.Type`
  as common super type
* Changed order arguments for "resolve" that takes TypeBindings and Type, to prevent
  problems with overloading: now TypeBindings is the first argument, not second

0.7.0:

#11: ResolvedType uses `java.lang.reflect.Type` to allow combination
  of Class<?>, GenericType and ResolvedType.
#12: ResolvedType now implements `java.lang.reflect.Type`

0.6.0:

#5: Make `GenericType` Serializable
 (suggested by Yuri S)
#8: Add additional pass-through methods in RawMember for all modifiers
 (requested by Phillip S)

0.5.4:

* #4: problems with self-referential type variables