This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 188550 - entity class generation in 6.9 has huge code-breaking changes
Summary: entity class generation in 6.9 has huge code-breaking changes
Alias: None
Product: javaee
Classification: Unclassified
Component: Persistence (show other bugs)
Version: 6.x
Hardware: All All
: P2 normal (vote)
Assignee: Sergey Petrov
: 189473 (view as bug list)
Depends on:
Reported: 2010-07-09 23:37 UTC by xirias
Modified: 2010-11-03 14:35 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description xirias 2010-07-09 23:37:34 UTC
The method names in 6.9 follow a new and hugely code-breaking new convention.  To avoid touching thousands of lines of code, is there a way to configure the method names of the generated classes to be similar to prior versions of Netbeans.  Version 6.9 generates method names using the name of the table, not the name of the primary key.  Either way would have been okay, but users have tons of code written against the convention from earlier versions.  Can you either roll back the change, or make it configurable?
Comment 1 Jiri Rechtacek 2010-07-12 14:09:28 UTC
I'm sorry I don't understand the problem. Please, add more details, test-case will be best. Thanks
Comment 2 xirias 2010-07-12 17:27:29 UTC
I am referring to the Netbeans feature in which it will generate entity classes automatically by analyzing database structure, one entity class per table.  The entity classes have a get and set method for each column.  

In prior versions of Netbeans, all get and set method names were based directly on the database column names, regardless of whether the column was a foreign key or not.  This was an excellent design choice, since it preserved a close match between the Java class and the underlying table.

In version 6.9 of Netbeans, this is broken for foreign keys.  The get and set method names for foreign keys no longer have any correlation to the column name, but instead are named for the name of the parent table.  In cases where multiple columns in a table refer to the same parent table, it gets worse:  the get and set methods are based on the parent table name plus a number.

Example:  I have a table called facility, with two audit fields:  one called CreatedByUser to keep track of the user who added the facility, and another called ModifiedByUser to keep track of the user who last modified the facility.  Both of these columns are foreign keys to the user table.

In prior versions of Netbeans, the entity class facility would have get and set method names of getCreatedByUser(), setCreatedByUser(), getModifiedByUser(), and setModifiedByUser().

In Netbeans 6.9, the entity class facility has get and set method names of getUser(), setUser(), getUser1(), and setUser1().

Of course these new names are not as useful as those made by prior versions of Netbeans, since they lead to very unreadable code.  

But the most devastating thing about the problem is that thousands of lines of existing code no longer even compile.  I have rolled back to version 6.8 since in its current state version 6.9 cannot be used.
Comment 3 Jiri Rechtacek 2010-07-12 18:03:55 UTC
Thanks for your more detailed report. I reassign to persistence team who can analyze the problem.
Comment 4 Sergey Petrov 2010-07-13 05:02:18 UTC
unfortunately there is no way. there was request to have names more user friendly to avoid lined like myId.myId ad have my.myId instead. it looks better for me.
but according to your samples it may be better to roll back this change but it will be available only in dev build and in next netbeans.
Comment 5 Sergey Petrov 2010-07-13 09:43:03 UTC
another problem will be code generated in 6.9 will be different in 6.10 if rollback issue 185253.

why "But the most devastating thing about the problem is that thousands of lines of
existing code no longer even compile." it may happen? Is it right after entities generation from db?
Comment 6 xirias 2010-07-13 15:58:35 UTC
Yes, for example in one project I have 127 generated entity classes.  When I modify the database schema, I delete and rebuild those classes.  When the method signatures (the get and set method names) all change, all of my handwritten code, in hundreds of other classes that references those entity classes, all break -- they don't compile because they refer to method names in the entity classes that no longer exist.

Beyond it being a code-breaking change, I am baffled as to why the naming was changed from version 6.8.  The new names are not friendlier.  What's clearer, a method name like getModifiedByUser(), or get User2()?  The former is what I would have gotten with 6.8, the latter is what 6.9 generates.

I would certainly take advantage of any interim build that rolled back the change, as currently I cannot use 6.9 at all.  thanks alot
Comment 7 Sergey Petrov 2010-07-15 18:27:53 UTC
ok, it looks like mapping options step in entity from db wizard may be a good place to add setting like "use column names for relations", it will be cmpartible with old and with 6.9 behavior even one will require wo more clicks.
Comment 8 Sergey Petrov 2010-07-16 09:12:17 UTC options is added.

there is another issue, all options are default on last wizard step on each invocation(aren't saved) but it need to be handled as another issue.

wait for integration message t see what build to use.
Comment 9 Quality Engineering 2010-07-17 03:45:08 UTC
Integrated into 'main-golden', will be available in build *201007170001* on (upload may still be in progress)
User: Sergey B. Petrov <>
Log: fix #188550 options is added on mappings step
Comment 10 Sergey Petrov 2010-08-13 08:16:28 UTC
*** Bug 189473 has been marked as a duplicate of this bug. ***
Comment 11 Petr Suchomel 2010-10-18 09:25:21 UTC
Backported into release692
Comment 12 rbalada 2010-11-03 14:35:53 UTC
Verified in 6.9 patch 2