To discuss: "Create method" intention does not take unboxing into account
I just filed an issue "'Create method' intention does not take unboxing
into account" at http://www.jetbrains.net/jira/browse/IDEA-3043. The
issue is basically that IDEA will not suggest "int" for a method
parameter type, even when it would work because of autoboxing.
The issue was immediately marked "Won't fix." Eugene Vigdorchik said
"No, I think suggesting autoboxing from IDE is a bad idea; there are so
many pitfalls with it, we can hardly guarantee no change of semantics."
I think this is a silly decision - maybe IDEA shouldn't support
autoboxing at all, because of its pitfalls. Maybe IDEA should refuse to
compile code which uses java.util.Date because it doesn't support time
zones. I think these seem silly like not suggesting autoboxed parameter
types in "Create method" intention.
Also, what "change in semantics" is there? The "Create method" intention
is shown when I type a method that doesn't exist, and pass it whatever
parameters I want. Before I run "create method," there are no semantics.
What do you guys think? Personally I think this is a bug and it should
be fixed.
Please sign in to leave a comment.
Keith, you are missing the fundamental distinction between error
highlighting and code generation (smmrt type completion being somewhere in
between):
while highlighting has to analyze EXISTING code for
errors/warnings/inconsistencies, the generation is to suggest your next
steps in writing code. When making this suggestion, the IDE must be really
careful not to introduce subtle hard-to-find errors (you don't have all IG
inspections switched on, right?). Due to really weird semantics autoboxing
introduces (e.g. caching autoboxed range for ints of certain range, or weird
rules for resolution among overloaded methods), it is really impossible to
guarantee your program will preserve its runtime behavior if
autoboxing/unboxing is silently applied).
Another point that comes against your proposal is the runtime cost
autoboxing has. While this may be neglectable in some situations, it may
also influence performance in others.
So to summarize, I'd recommend using this language feature with great care,
and definitely would not like the IDE to offer it to me by itself. Even if I
do need it occasionally, I'd prefer to stop tabbing in live template to fill
the autoboxed type manually while rethinking if I really need it.
What do others think?
Eugene.
"Keith Lea" <keith@cs.oswego.edu> wrote in message
news:d9mfah$pva$1@is.intellij.net...
>
>
>
>
Well, I don't think it's a bug. IDEA /could/ be more "auto-boxing" friendly here, but
honestly I don't think it's a good idea to offer to create the method with a primitive
type in your example. Code like that is almost guaranteed to produce unwanted results.
Your example code will crash in the moment that the Integer-object becomes null. That's a
pretty big impact on semantics that probably not many people are aware of.
I just learned this the hard way some days ago when code like
Boolean b = ...;
if (b) { ... }
blew up with an NPE. In that moment I decided to stay the hell away from auto-(un)boxing
and turned the IG inspections on for that - as errors.
So basically there's a difference between supporting the language feature and actively
providing ways of doing stupid things with this IMHO stupid and dangerous feature. I also
think that the impact of not including "int" in the list of possible types is not big
enough to call that decision "silly". Consider it as a safety-feature: IDEA will not offer
you to do something potentially dangerous, but if you know what you're doing, typing those
three keys isn't a high price to pay.
My 2c.
Sascha
And just one more point has just come to my mind:
what autoboxing int to Integer is, is a syntatic sugar for calling
Integer.valueOf(int) method.
"Keith Lea" <keith@cs.oswego.edu> wrote in message
news:d9mfah$pva$1@is.intellij.net...
>
>
>
>
That's the reason I really miss an option for javac to turn off certain
parts of Java5! Auto-boxing is only useful for passing vararg-Parameters.
I miss that too. IMHO, it was a bad idea to add auto-unboxing.
Tom
Sven Steiniger wrote:
Sounds like a reasonable exclude-option for IG. Wanna submit a JIRA entry for that?
Sascha
Done: http://www.jetbrains.net/jira/browse/IDEA-3065
Sascha Weinreuter schrieb:
>>Auto-boxing is only useful for passing vararg-Parameters.
I think it's strange to see all this negative energy towards
boxing/unboxing. I use it all the time. I have many List and Map. Autoboxing is nice to me in these situations. Sven Steiniger wrote: >> Boolean b = ...; >> if (b) { ... } >> >> blew up with an NPE. In that moment I decided to stay the hell away >> from auto-(un)boxing and turned the IG inspections on for that - as >>]]> errors.
The reason is simple: auto-UNboxing might introduce subtle bugs, which where
caught be 1.4-javac. I'm sure, nobody has such a negative example for
auto-boxing (except making it not obvious from reading the source).
Which does not mean, that it is good. ;)
> I have many List]]> and
We have only so few int/long collections (if it's a hand-full, it is much),
that writing "intObj.intValue()" is acceptable. I definitely would not miss
auto-(un)boxing if it would be removed in a future version (I know, it never
will).
Tom