Skip to content

[OPENJPA-3012] some comments are addressed - #211

Merged
solomax merged 2 commits into
masterfrom
OPENJPA-3012
Oct 9, 2026
Merged

solomax merged 2 commits into
masterfrom
OPENJPA-3012

Conversation

@solomax

@solomax solomax commented Oct 9, 2026

Copy link
Copy Markdown
Contributor

PR was merged too fast :)))

I have addressed some comments
But I have difficulties with tests :(

class resolving is happening through ObjectStreamClass which I have no idea how to construct :(
ObjectStreamClass.lookup(Class) will make it available to local class loader

I would appreciate help here :)

@solomax
solomax requested review from cristof and rzo1 October 9, 2026 09:43
The resolution paths are reachable without constructing an ObjectStreamClass:
serializing int.class yields a descriptor whose name is "int", which
Class.forName rejects, so it is resolved only by the fallback to the stream's
own resolveClass; that test fails before this change and passes after it. A
class loader that redefines the classes of the test instead of delegating gives
a class reachable from one loader only, which pins that the thread context
loader is consulted and takes precedence. Array classes and an array instance
cover the descriptors that name a type rather than a class.
@rzo1

rzo1 commented Oct 9, 2026

Copy link
Copy Markdown
Contributor

@solomax I pushed a test to the branch: openjpa-kernel/.../util/TestSerializationClassResolving.

No ObjectStreamClass has to be built. Serializing with a plain ObjectOutputStream and reading back through Serialization.deserialize(in, null) drives resolveClass with whatever descriptor the stream carries, and the interesting descriptors are reachable that way:

  • int.class serializes to a descriptor whose name is int. Class.forName("int", true, loader) throws, so the class is resolvable only through the fallback to super.resolveClass. This one fails on the code before this branch (ClassNotFoundException: int) and passes with it.
  • int[].class, String[].class and an int[] instance give the descriptors [I and [Ljava.lang.String;, which do resolve by name; they are regression coverage.
  • For the context loader, a loader that redefines the test's own classes instead of delegating yields a class with the same name reachable from one loader only. The test serializes an instance of that copy, sets it as the context loader, deserializes, and asserts the result's class is the loader's copy. Since both copies come from the same bytes, the serial version matches.

ObjectStreamClass.lookup(Class) is indeed unusable for this, since it resolves against the local loader.

Four tests, all green on the branch; with Serialization.java reverted to the pre-branch version the primitive one errors, so it pins the change rather than the surroundings.

One small thing on the javadoc in 374edfa: the comment ends with "A comment would prevent a later simplification", which was my phrasing in the review rather than something to keep in the source. Everything above it describes the constraint correctly.

@solomax

solomax commented Oct 9, 2026

Copy link
Copy Markdown
Contributor Author

Thanks! :)))

@solomax
solomax merged commit 248c653 into master Oct 9, 2026
4 checks passed
@solomax
solomax deleted the OPENJPA-3012 branch October 9, 2026 11:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants