Skip to content

Refactor NLS messages#612

Open
awisniew90 wants to merge 6 commits intoOpenLiberty:mainfrom
awisniew90:message-props
Open

Refactor NLS messages#612
awisniew90 wants to merge 6 commits intoOpenLiberty:mainfrom
awisniew90:message-props

Conversation

@awisniew90
Copy link
Contributor

@awisniew90 awisniew90 commented Jan 5, 2026

This PR:

  1. Refactors the NLS message structure
  2. Moves all hardcoded UI messages to the Messages.properties file
  3. Combines duplicate trace and UI messages into one message
  4. Fixes typos for various messages

Signed-off-by: Adam Wisniewski <awisniew@us.ibm.com>
Signed-off-by: Adam Wisniewski <awisniew@us.ibm.com>
Signed-off-by: Adam Wisniewski <awisniew@us.ibm.com>
Signed-off-by: Adam Wisniewski <awisniew@us.ibm.com>
Signed-off-by: Adam Wisniewski <awisniew@us.ibm.com>
msg = key;
}

return msg;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think this could be null - if msg = NLS_BUNDLE.getString(key); on line 55 gets a null back - could that cause an issue in the caller?

Copy link
Contributor Author

@awisniew90 awisniew90 Jan 8, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at the NLS_BUNDLE.getString() method, we actually should never get a null back. If the String object is null, that method throws an exception which we will catch and set the msg to the provided key. Given that, we probably dont need the null check afterwards either.

if (msg != null && args != null) {
msg = MessageFormat.format(msg, args);
}
} catch (Exception e) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we catch more specific exceptions here to give a finer grained reason for failure?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think in all cases, the reason is pretty much that there is an issue with that particular message property. Either the key being used is wrong, or the value in the properties file is wrong. In either case, it's a bug in our code and the failed message lookup should be enough to indicate that.

try {
NLS_BUNDLE = ResourceBundle.getBundle("io.openliberty.tools.eclipse.messages.Messages", Locale.getDefault());
} catch (Exception e) {
NLS_BUNDLE = ResourceBundle.getBundle("io.openliberty.tools.eclipse.messages.Messages");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there a chance that both of these inti's could fail? at that point NLS_BUNDLE would be null - should we initialize it to an empty ResourceBundle?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, there shouldnt be a chance of that since we are using the fully qualified classname for this class. If the class is running within the bundle, we should be able to lookup the bundle based on the class.

Signed-off-by: Adam Wisniewski <awisniew@us.ibm.com>
Copy link
Contributor

@ajm01 ajm01 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

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