New API usecase request => enhancement.

Issue 132217 is use case. Can we either do this or can you close this as wontfix and I'll close 132217 the same way?

It will require change of the API, the platform's Specification which contains the type has nothing like display type. Unfortunately I will have no time to do this 
into 7.0 as I am fully assigned to java core and parsing api.
If you think it's not important feel free to close it.

I agree, but if we close it, we will get it reported back in a few days.
JavaFX has already two reports on this issue, both low priority.
Feel free to decide, I'll follow.

See suggested resolution in issue 101486.  Need to test it, but it should work for some other module (or java.project)
to define the J2ME folder and localize it to "Java ME", then have a kit module hide the folder.  When the first mobility
platform is added, the folder is unhidden, but it should (?) still have the localization attributes from the original layer.

At worst this could be handled with an ugly but easy-to-do, reliable hack:  java.platform notices if a folder called
J2ME is created (the UI must be listening for file changes already);  if so, it immediately sets its localizing bundle
attribute so the name is correct.  Not pretty, but no reason it wouldn't work forever.

Suggestion won't work.  Need Specification.getDisplayName().

Created attachment 84898 [details]
Patch for this issue

The attached patch adds a trivial API class
public class SpecificationLocalizer {
  ...
  public String getName (String specificationName);
}

and adds one instance to the default lookup which converts J2SE -> Java SE and J2ME -> Java ME

It is a compatible addition, and solves the problem with minimal code changes.

[JG01] SpecificationLocalizer should be in an SPI package.


[JG02] getName and hence SpecificationLocalizer should be abstract. Impls should be in java.j2seplatform, mobility.*, etc.


[JG03] Would also need @since, apichanges.xml.


[JG04] Would want to see the code using this new method in the UI as part of the patch.


[JG04, to supersede JG01 and JG02] I'm not sure I even see the purpose of a separate service interface. Why not just add
an optional displayName parameter to the Specification constructors, and a getDisplayName getter? Certainly whatever
code is creating the Specification, generally the code creating the JavaPlatform, should know how to localize it. Seems
simpler and more consistent with the existing API.


BTW pay attention to your diffs and keep them clean:

-        public @Override String getDisplayName() {
+        public @Override String getDisplayName() {            /* gratuitous whitespace added here */

Created attachment 85728 [details]
Jesse is correct, this can be done with compatible addition to Specification

Attached patch adds constructors w/ display name parameter to Specification, and Specification.getDisplayName(); also
makes use of it for SE, ME, CDC and JavaCard projects;  and updates those modules dependencies to require v1.14 of
java.platform.  Testing it now.

Looks simpler & better.


[JG06] displayName should follow, not precede, name in the constructor arg list. (For consistency with Node.Property,
Sources.genericGroup, and many other APIs.)


[JG07] The dep update should have been in mobility.cldcplatform, not mobility.project.


[JG08] For ease of analysis by source code traversal tools, please use constant strings for the key param to
NbBundle.getMessage.


[JG09] <summary></summary> should not be empty.

> [JG08] For ease of analysis by source code traversal tools, please use constant strings for 
> the key param to NbBundle.getMessage.

@Jesse:  Do you really mean "please use", or "please do not use"?  Probably 98% of calls to NbBundle in NetBeans use
hardcoded strings, not constants, and if something is searching for missing bundle keys, that is certainly easier to
analyze.  Did you really mean that I *should* use constants?

I meant "please use" but I should have specified that I meant hardcoded strings, i.e. constant values rather than Java
expressions. I.e. in place of

NbBundle.getMessage(J2MEPlatform.class, SPECIFICATION_NAME)

use

NbBundle.getMessage(J2MEPlatform.class, "j2me")

This makes it easier for analysis tools to look for missing or unused keys, etc., and also means that pelmel.kenai.com
can display the localized string inline in the editor.

Still active?

JG08 should be revised to suggest @NbBundle.Messages.

Already fixed but forgotten to close.
b86a6b8f9108