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.

9 comments
Comment actions Permalink

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...

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.



0
Comment actions Permalink

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

0
Comment actions Permalink

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...

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.



0
Comment actions Permalink

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.


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.

0
Comment actions Permalink

That's the reason I really miss an option for javac to turn off certain
parts of Java5!


I miss that too. IMHO, it was a bad idea to add auto-unboxing.

Tom

0
Comment actions Permalink

Sven Steiniger wrote:

Auto-boxing is only useful for passing vararg-Parameters.


Sounds like a reasonable exclude-option for IG. Wanna submit a JIRA entry for that?

Sascha

0
Comment actions Permalink

Done: http://www.jetbrains.net/jira/browse/IDEA-3065

Sascha Weinreuter schrieb:

Sven Steiniger wrote:

>>Auto-boxing is only useful for passing vararg-Parameters.


Sounds like a reasonable exclude-option for IG. Wanna submit a JIRA entry for that?

Sascha

0
Comment actions Permalink

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.


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.

0
Comment actions Permalink

I think it's strange to see all this negative energy towards
boxing/unboxing.


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).

I use it all the time.


Which does not mean, that it is good. ;)

> I have many List]]> and

Map<Integer,xxx>. Autoboxing is nice to me in these situations.


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

0

Please sign in to leave a comment.