Skip to content

Conversation

@HannesWell
Copy link
Member

This avoids a compiler warning if an explicit array of a sub-type of Object[] is passed as last argument:
NLS.bind("message: {0} {1}", new String[] { "Hello", "World" })

The byte-code generated for the NLS.bind() method and for all its callers is not changed by this adjustment. It just avoids what looks like a source-compatibility issues with the previous introduction of var-args in NLS.bind(). Although the example above works the same in all three states.

Follow-up on:

@HannesWell
Copy link
Member Author

This should avoid the warnings fixed in:

and I have also checked that the errors (which are actually just elevated compiler-warnings) from eclipse-platform/eclipse.platform#1854, would not have occurred with this.

In general these changes should still be applied as they simplify code that is currently needlessly verbose, but I think it's better without warnings/errors to keep existing callers more comfortable.

@github-actions
Copy link

github-actions bot commented May 5, 2025

Test Results

  669 files  ±0    669 suites  ±0   1h 16m 28s ⏱️ + 1m 58s
2 224 tests ±0  2 177 ✅ ±0   47 💤 ±0  0 ❌ ±0 
6 816 runs  ±0  6 673 ✅ ±0  143 💤 ±0  0 ❌ ±0 

Results for commit cf999b2. ± Comparison against base commit 71d1fa5.

♻️ This comment has been updated with latest results.

@HannesWell
Copy link
Member Author

The failing quality-gate was indeed relevant as some calling projects that now get slight different byte-code generated because the var-args array generated by the compiler now can have a more specific type than Object[], common for all passed arguments.

This avoids a compiler warning if an explicit array of a sub-type of
Object[] is passed as last argument:
NLS.bind("message: {0} {1}", new String[] { "Hello", "World" })

The byte-code generated for the NLS.bind() method and for all its
callers is not changed by this adjustment. It just avoids what looks
like a source-compatibility issues with the previous introduction of
var-args in NLS.bind(). Although the example above works the same in all
three states.

Follow-up on:
- eclipse-equinox#936

Also touch calling projects that now get slight different byte-code
generated because the var-args array generated by the compiler now can
have a more specific type than Object[], common for all passed
arguments.
@HannesWell HannesWell merged commit 8a0d0c1 into eclipse-equinox:master May 5, 2025
29 of 30 checks passed
@HannesWell HannesWell deleted the generic-NLS.bind branch May 5, 2025 20:05
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.

2 participants