Java/more thread safe initialisers

[yoff]

When a field is assigned a safe type in a constructor, that field is not exposed.

[Copilot]

Pull request overview

This PR enhances Java thread safety analysis to recognize when fields are initialized with thread-safe types inside constructors, not just in field initializer expressions. This reduces false positives when fields are assigned thread-safe collections (like ConcurrentHashMap or synchronized maps) in constructors.

Key Changes:

• Added initialValue predicate to check both field initializers and constructor assignments
• Modified ExposedField class to use the new predicate for more comprehensive thread-safety checking
• Added comprehensive test coverage for the new functionality

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
java/ql/lib/semmle/code/java/ConflictingAccess.qll	Implements the core logic by adding initialValue predicate and updating ExposedField to check constructor assignments
java/ql/test/query-tests/ThreadSafe/examples/ThreadSafeInitializers.java	Adds test cases demonstrating thread-safe initialization patterns in constructors
java/ql/test/query-tests/ThreadSafe/ThreadSafe.expected	Updates expected test results to include the new test case alert
java/ql/src/change-notes/2025-11-25-thread-safe-initializers.md	Documents the enhancement in the release notes

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The documentation says "This is either a static initializer or an assignment in a constructor" but should say "field initializer" instead of "static initializer". A static initializer is a method (<clinit>), whereas this predicate returns the field's initializer expression.

Suggested change

	* This is either a static initializer or an assignment in a constructor.
	* This is either a field initializer or an assignment in a constructor.

[aschackmull]

I agree here. Let's fix the qldoc.

[yoff]

The performance run shows something on palatable/lambda both overall and in a stage related to dataflow. However, the changed code is not evaluated until later and not at all during the highlighted stage or indeed query (it is specific to the concurrency queries). I am leaning towards just accepting the performance run...

[aschackmull]

dca looks fairly uneventful to me.

[yoff]

dca looks fairly uneventful to me.

Cool, then I feel ready to merge. I have fixed the QLDoc and rebased (to make CI happy).