duplicate aliases in config

11 views
Skip to first unread message

Jason S

unread,
Jul 22, 2011, 9:43:29 AM7/22/11
to javabu...@googlegroups.com
I have two independent .jar files that use JXTable.

When each of my classes uses JXTable, I call

SwingJavaBuilderConfig config = SwingJavaBuilder.getConfig();
config.addType("JXTable", JXTable.class);

and on the 2nd time I get the error

org.javabuilders.DuplicateAliasException: Duplicate alias 'JXTable' for class 'org.jdesktop.swingx.JXTable'. One already exists for 'org.jdesktop.swingx.JXTable'

How can I do this the right way to prevent calling addType() twice? I tried SwingJavaBuilderConfig.isTypeDefined(JXTable.class) but that's not right.

Jason S

unread,
Jul 22, 2011, 9:59:21 AM7/22/11
to javabu...@googlegroups.com
...odd.... I'm stepping through the debugger and looking at source code https://github.com/jacek99/javabuilders/blob/master/javabuilder-parent/javabuilder-core/src/main/java/org/javabuilders/BuilderConfig.java

and I see JXTable in the typeAliases map but not in the typeDefinitions map.

My concurrency radar is up: when potentially dealing with multiple threads, should I synchronize on SwingJavaBuilder.getConfig() ?

Jason S

unread,
Jul 22, 2011, 10:21:44 AM7/22/11
to javabu...@googlegroups.com
never mind, typeAliases and typeDefinitions are two different things. This works (w/ thread-safety added just to be sure):

    static public boolean addJavaBuilderClass(String alias, Class<?> cl)
    {
        SwingJavaBuilderConfig config = SwingJavaBuilder.getConfig();
        synchronized(config)
        {
            Class<?> cl0 = config.getClassType(alias);
            if (cl0 == null)
            {
                config.addType(alias, cl);
                return true;
            }
            else
            {
                return false;
            }
        }
    }

Jacek Furmankiewicz

unread,
Jul 23, 2011, 4:55:20 PM7/23/11
to javabu...@googlegroups.com
We can probably do better than that...if the new alias is the same as the old one (in terms of the Class) we could probably
silently ignore it.

Since most initialization like this happens on a single thread, I wouldn't worry about the synchronized too much,
unless your app behaves differently on startup.


            }
        }
    }

--
You received this message because you are subscribed to the Google Groups "JavaBuilders" group.
To view this discussion on the web visit https://groups.google.com/d/msg/javabuilders/-/OIZdkYq2IQoJ.

To post to this group, send email to javabu...@googlegroups.com.
To unsubscribe from this group, send email to javabuilders...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javabuilders?hl=en.

Reply all
Reply to author
Forward
0 new messages