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 223154 - Change type of reference hint removes type parameters
Summary: Change type of reference hint removes type parameters
Status: NEW
Alias: None
Product: java
Classification: Unclassified
Component: Hints (show other bugs)
Version: 7.3
Hardware: PC Windows 7
: P3 normal (vote)
Assignee: Svata Dedic
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-12-03 07:52 UTC by Chiana
Modified: 2013-09-02 14:24 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments
Before using hint (31.34 KB, image/jpeg)
2012-12-03 07:52 UTC, Chiana
Details
After work (22.77 KB, image/jpeg)
2012-12-03 07:53 UTC, Chiana
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chiana 2012-12-03 07:52:03 UTC
[ JDK VERSION : 1.7.0_09 ]

The "change type of reference" hint removes the type parameters when used.
Comment 1 Chiana 2012-12-03 07:52:52 UTC
Created attachment 128741 [details]
Before using hint
Comment 2 Chiana 2012-12-03 07:53:23 UTC
Created attachment 128742 [details]
After work
Comment 3 Jiri Prox 2012-12-03 11:52:14 UTC
The type is derived from the right side of assignment - no in this case there are no generic types. 

The question is, if there should be some heuristic to determine the requested generic type.
Comment 4 Chiana 2012-12-03 19:21:04 UTC
Some sort of check for parameters to the rval and a quick check if there are some on the lval and if they are similar (or as in this case have the same ancestry) retain them.

Just a simple suggestion...
Comment 5 Jan Lahoda 2012-12-06 16:04:18 UTC
Sorry, but I don't think this is a defect - the fix works as it is currently intended: it replaced the type on the left side with the type on the right side.

I'll keep this open as an enhancement to keep left-side type parameters if the new type is a compatible raw type, but my guess is that the cost/benefit ratio of that would not be very high, and I would not be surprised if it would not be implemented in foreseeable future.
Comment 6 Chiana 2012-12-06 16:35:36 UTC
You are aware that this behaviour could cause some hard to track error since the resulting declaration would (in this case) yield WeakHashMap<Object,Object> instead of desired WeakHashMap<ObjectId,Object> ?
Comment 7 Jan Lahoda 2012-12-06 17:55:05 UTC
What the fix promises is that it will change the type to "WeakHashMap", and it does that. If that is or is not appropriate is up to the developer, it only saves some typing. Sure it can lead to compile-time (and in some cases even run-time) errors, but the same applies to cases where the classes have no common ancestor (or a different number of type parameters, or type parameters on left-hard side that do not have any relation to the type parameters listed on the right-hand side, etc.). Also, changing a HashMap to WeakHashMap as such is surely an operation that requires review of the usages of the map.

That does not mean that copying the type parameters would be impossible or a priori wrong - but it would need to be done carefully, and would introduce additional clutter and unpredictability (i.e. why in this case it did copy the parameters and in this other cases it did not?). Overall, I think the time needed to implement that is likely better spent somewhere else.