Bug 20736 - Provide a transition plan for users of deprecated editors
Provide a transition plan for users of deprecated editors
Product: platform
Classification: Unclassified
Component: Property Editors
All All
: P3 (vote)
: 6.x
Assigned To: Jiri Rechtacek
Depends on: 29447
Blocks: 5278
  Show dependency treegraph
Reported: 2002-02-21 00:06 UTC by Rochelle Raccah
Modified: 2008-12-22 09:52 UTC (History)
2 users (show)

See Also:

Patch adding new hintable, internationalizable editors for primitive boolean and int types (11.59 KB, patch)
2003-02-28 17:33 UTC, _ tboudreau
Details | Diff
Patch revised per Jesse's comments & including unit test (23.82 KB, patch)
2003-03-10 17:13 UTC, _ tboudreau
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Rochelle Raccah 2002-02-21 00:06:03 UTC
According to David, the property editors in the openide jars are deprecated. 
Users of those editors should be converting to the core ones.  However, there is
no core editor corresponding to ChoicePropertyEditor.  As part of the conversion
guide, there should be a plan for users of this (and other) deprecated editors,
and if necessary, a new corresponding editor in the core.
Comment 1 Jiri Rechtacek 2002-03-04 09:01:50 UTC
Ales, please add this to a editors transition's plan. Thanks
Comment 2 Marek Grummich 2002-07-22 11:29:58 UTC
Set target milestone to TBD
Comment 3 Marek Grummich 2002-07-22 11:32:00 UTC
Set target milestone to TBD
Comment 4 Jesse Glick 2003-01-20 18:18:53 UTC
IMHO could be WONTFIX - this property editor is so trivial it's
stupid. In fact it is written much more verbosely than is really
needed. Should suffice to have e.g.:

public final class MyEd extends SimplePropertyEditor {
    private final Map const2Name = new HashMap();
    private final Map name2Const = new HashMap();
        const2Name.put(new Integer(CONST1), "CONST1");
        // etc.
        Iterator it = const2Name.entrySet().iterator();
        while (it.hasNext()) {
            Map.Entry e = (Map.Entry)it.next();
            name2Const.put(e.getValue(), e.getKey());
    public String[] getTags() {
        return name2Const.keySet().toArray(new String[0]);
    public String getAsText() {
        return const2Name.get(getValue());
    public void setAsText(String s) {

Good 'nuff.

But if desired, the prop ed for Integer.TYPE could indeed have a pair
of hints in the form of an int[] and String[] to display as constants;
not very hard to do.
Comment 5 Rochelle Raccah 2003-02-25 21:05:33 UTC
Sorry, what is SimplePropertyEditor and where is it defined?  Does it
handle the listeners?
Comment 6 Jesse Glick 2003-02-25 21:21:22 UTC
Sorry, PropertyEditorSupport.

Re. listeners - I think calling setValue is all you need.
Comment 7 Rochelle Raccah 2003-02-26 21:17:12 UTC
I just noticed that the java module now has a private copy of the
ChoicePropertyEditor class which looks mostly like the deprecated
version but has a few simplications similar to the ones mentioned
below (extends PropertyEditorSupport, no separate listener handling,
etc.).  So, should we all have private copies of this class?  Doesn't
that defeat the purpose?  And if they are slightly different they each
need to be tested separately.
Comment 8 Jesse Glick 2003-02-26 22:15:03 UTC
IMHO it is too trivial to bother having a global convenience impl of,
but as I wrote on 1/20/03, feel free to file an RFE for the editor for
int to handle tags with hints.
Comment 9 _ tboudreau 2003-02-27 02:11:58 UTC
Rochelle, let me know if the improvements to the integer
editor Jesse suggets would do the trick for you, and if the endless
parade of P1 and P2 bugs that is my existence slacks off for 24
hours I will implement it.

BTW, int or Integer editor? - I could fix another enhancement 
request by replacing the int editor (should manage whitespace 
in setAsText reasonably - the default sun.beans... editor doesn't).
Comment 10 Rochelle Raccah 2003-02-27 18:28:12 UTC
Yes, that would help although I still have at least one place where I
subclass the editor, so I'm not sure it would entirely solve the
problem.  I think the reason I do it is so I can show an invalid value
with property marking even if the int is not in the list of constants,
so if you can include that too, I'm set.
Comment 11 Jesse Glick 2003-02-27 21:17:39 UTC
While you're at it Tim, the JRE's boolean editor is not correctly
I18N'd and you can't replace the strings "True" and "False" with e.g.
"No jo" and "Ba ne". :-)
Comment 12 Rochelle Raccah 2003-02-28 03:07:15 UTC
I've tried a version of Jesse's solution and found a problem - I
expected the tags to be in the order I supply them in the String[],
but HashMap doesn't guarantee any such thing =).  The old editor
worked that way, so in implementing a new one, please keep that in
Comment 13 _ tboudreau 2003-02-28 16:02:48 UTC
Working on replacement int and bool editors (the Integer and 
Boolean editors which wrap these will inherit their behavior).
This will also allow me to solve issue 5278, the oldest issue
I currently own.
Comment 14 _ tboudreau 2003-02-28 17:33:18 UTC
Created attachment 9227 [details]
Patch adding new hintable, internationalizable editors for primitive boolean and int types
Comment 15 _ tboudreau 2003-02-28 17:39:31 UTC
Rochelle, please try out this patch and let me know if it meets
your needs.  The patch includes an update to the Explorer API 
documentation to document the new hints for int/Integer and
boolean/Boolean types.

To save you some trouble:

For the Integer editor, you want to provide the following hints:
String[] "stringKeys" - a set of keys you want the user to see
int[] "intKeyValues" - the set of values corresponding to those keys

Both arrays must be the same length and the length must be >= 1.

For the Boolean editor (the only handling difference is case
insensitivity), you can pass the following hint:
String[] stringValues
with the array ordered false, true (e.g. new String[] {"off","on"}).

Let me know if this helps.  I can commit it sometime next week
if there are no problems (although it won't make it into 3.5 unless
you find a way to make this issue a P2, I'm afraid).
Comment 16 Jesse Glick 2003-02-28 20:14:15 UTC
Re. patch:

- suggest "intValues" not "intKeyValues"

- behavior of javaInitializationString is debatable: if you are using
e.g. constants like WindowConstants.EXIT_ON_CLOSE etc., then you want
to use those actual strings: e.g. stringKeys={"EXIT_ON_CLOSE", ...},
intValues={WindowConstants.EXIT_ON_CLOSE, ...}, and you maybe also
want some javaValues={"javax.swing.WindowConstants.EXIT_ON_CLOSE",
...} as well. If you are not setting source code constants, but just
some random options e.g. for a SystemOption, then probably this method
will never be called, but if it is then best is to use the raw number,
as you do

- BoolEditor.setAsText need not be so complicated - if you provide
getTags then only those tags can be passed back to you. No need to
check case, trimming, etc. - the user cannot enter freeform text.

- don't forget that if applied this is a compatible API change ->
needs apichanges.xml entry, spec version, note "since 4.whatever" in
Explorer API HTML docs
Comment 17 _ tboudreau 2003-03-10 17:13:55 UTC
Created attachment 9332 [details]
Patch revised per Jesse's comments & including unit test
Comment 18 _ tboudreau 2003-03-10 17:21:15 UTC
Revised patch attached.  intKeyValues -> intValues  

Unit test included (had to do some monkeying with PropertyEnv - I
assume there's nothing wrong with having a package 
org.openide.explorer.propertysheet in the core/test/src/unit? -
I needed a way to get an instance of PropertyEnv). Docs patch revised.

Jesse:  I did keep the trimming in place in BoolEditor - though
it would be dumb, someone could find some reason to call it 
programmatically for whatever reason.  

Added another hint, "codeValues" that allows initialization strings
to be supplied.  Also, attachEnv now sqawks loudly if it gets
bogus values (like keys array longer than values array).

I don't know much about these apichanges.xml docs - is there
a walkthrough somewhere?

Rochelle, do you want to review this or should I just commit
it?  I'm waiting for some word.
Comment 19 Jesse Glick 2003-03-10 17:36:50 UTC
Re. putting a package org.openide.explorer.propertysheet in a core
unit test - this is not good I think. Use reflection if you need to.

Re. trimming bool editor - no one should be calling
PropertyEditor.setText programmatically, *especially* with bogus
values. Leaving in such code will just mislead people into thinking
this is normal. It's not and it need not be supported. "someone could
find some reason to call it programmatically for whatever reason" -
yes, they could, and when it fails to work and they whine on nbdev we
will have the opportunity to ask them what they were thinking; this is
a benefit.

Re. apichanges.xml -


and read the comments in the file itself which explain it. You *must*
understand how to use this file and deal with API changes properly
before working on API-sensitive areas of openide code.

I haven't had time to actually look at the new patch itself, too busy,
maybe ask someone else (Yarda?) for review if you are unsure.
Comment 20 Rochelle Raccah 2003-03-10 19:56:12 UTC
Tim, I think it makes sense to have someone else review it (Yarda, 
David S. or some other prop expert).  I *do* intend to try it when I 
can, but since it won't be in 3.5 I had to put in my own version for 
now and I have some other high priority tasks to finish first.
Comment 21 _ tboudreau 2003-04-04 14:33:09 UTC
Hintable IntEditor/IntegerEditor committed to trunk, API docs updated.
Rochelle, reopen if this does not satisfy your needs.

IntEditor 1.1
Comment 22 Rochelle Raccah 2003-05-22 21:01:29 UTC
I finally tried this and I'm getting the following exception (note
that my constant *is* 8, but the number of strings and constants are
both 3):
Annotation: Exception in org.netbeans.beaninfo.editors.IntEditor
Property Editor
java.lang.IllegalArgumentException: This property editor uses a set of
keyed values, and the value 8 is out of range.
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:443)
[catch] at
Comment 23 _ tboudreau 2003-05-23 10:01:23 UTC
My apologies, Rochelle - I made a truly dumb error and 
only tested the new code with a values array that was
sequential and corresponded to the real values.  I'll
have it fixed by Monday.


Comment 24 _ tboudreau 2003-05-24 14:57:09 UTC
Fixed in trunk, IntEditor 1.4.
Comment 25 Rochelle Raccah 2003-05-27 23:22:40 UTC
Still not working =(.  I get a slightly different stack with today's
Comment 26 _ tboudreau 2003-06-02 13:19:32 UTC
Rochelle, could you attach the code you're using to produce this,
or a simple test case?  This is the code that's calling the exception:

   public Object getValue () {
        Integer v = (Integer) super.getValue();
        if (values != null) {
            v = new Integer (values[v.intValue()]);
        return v;

The way it works is, if keys and values are present, 
PropertyEditorSupport's getValue method is used to store
the index into the values array; otherwise it is used to
store the actual value.

Is there any possibility for your property to return a 
value from its getValue method that is outside the range
of the keys/values array?  It *is* possible to initialize
the editor with a bad value, before attachEnv() is ever
Comment 27 Rochelle Raccah 2003-06-03 17:03:37 UTC
I've sent it to you privately.
Comment 28 _ tboudreau 2004-04-19 14:53:03 UTC
Passing property editor issues to new owner, Jirka
Comment 29 Jiri Rechtacek 2008-10-16 15:43:30 UTC
It's not planned for long time. It's fair to close as WONTFIX

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo