Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrectly added BoxedUnit.UNIT to a no-parameter constructor call #4851

Closed
scabug opened this issue Jul 28, 2011 · 13 comments
Closed

Incorrectly added BoxedUnit.UNIT to a no-parameter constructor call #4851

scabug opened this issue Jul 28, 2011 · 13 comments
Assignees

Comments

@scabug
Copy link

scabug commented Jul 28, 2011

I have this piece of code

trait Bound {
  private val support = new PropertyChangeSupport()
  
  def firePropertyChange(name:String, oldVal:Object, newVal:Object) = support.firePropertyChange(name, oldVal, newVal)
}

I realized that I used a constructor which is NOT present in the java class. How is that possible ? A decompile yielded:

    public static void $init$(Bound $this)
    {
        $this.scala$test$Bound$_setter_$scala$test$Bound$$support_$eq(new PropertyChangeSupport(BoxedUnit.UNIT));
    }

So it seems the compiler tried to match the Object constructor with a default unit. Is this the proper behavior ?
How can a programmer know that this substitution is happening ?

@scabug
Copy link
Author

scabug commented Jul 28, 2011

Imported From: https://issues.scala-lang.org/browse/SI-4851?orig=1
Reporter: Daniel Cardin (mrhightech)
Affected Versions: 2.9.0

@scabug
Copy link
Author

scabug commented Jul 28, 2011

Daniel Cardin (mrhightech) said:
wow, sorry for the poor code formatting

@scabug
Copy link
Author

scabug commented Jul 28, 2011

@paulp said:
It is very, very unfortunate behavior. As specified.

See this thread.

Leaving this open anyway.

@scabug
Copy link
Author

scabug commented Jul 28, 2011

@paulp said:
It is possible you are getting at a related but different issue; however your code is too confusing to tell. Can you identify exactly what the constructor signatures are and what constructor you think was called?

@scabug
Copy link
Author

scabug commented Jul 28, 2011

Daniel Cardin (mrhightech) said:
basically the important part is new PropertyChangeSupport()

the no-args constructor does NOT exist in the java class. But my understanding is that scalac converts the () to BoxedUnit.UNIT which satisfies the PropertyChangeSupport(Object o) constructor.

Obviously that constructor is not what I am expected to be used... It is actually very misleading to someone using a Java API.

I read the other thread and I think scalac should be more strict when using Java classes... if that is even identifiable to the compiler.

@scabug
Copy link
Author

scabug commented Jul 28, 2011

@paulp said:
Now that's a great point. What are the odds someone wants to implicitly pass BoxedUnit to a java class? The world hasn't gone that mad.

@scabug
Copy link
Author

scabug commented Jul 28, 2011

Daniel Cardin (mrhightech) said:
ahaha :) Indeed!

I'm having a hard time "selling" Scala to my programmers (strangely enough, the older guy is pushing on the younger ones... go figure).

But a key point, and this is almost an understatement, is that the Java integration must be stellar. The same goes for a great IDE, and it's
a real blessing Martin O. went ahead and made it a priority.

A "feature" like this makes Java integration risky. Please consider :)

@scabug
Copy link
Author

scabug commented Jul 28, 2011

@paulp said:
You don't have to convince me (note my claim of "this is a debacle!" in the linked thread.) But I don't call all the shots.

@scabug
Copy link
Author

scabug commented Jul 28, 2011

Daniel Cardin (mrhightech) said (edited on Jul 29, 2011 1:21:26 PM UTC):
It's not you I'm trying to convince. I am appealing to the higher authorities ;)

@scabug
Copy link
Author

scabug commented Jul 29, 2011

@paulp said:
Most likely I'm your whole audience for these comments.

@scabug
Copy link
Author

scabug commented Jul 29, 2011

Commit Message Bot (anonymous) said:
(extempore in r25410) Added two new compiler options:

-Ywarn-adapted-args // also included in -Xlint
-Yno-adapted-args

The former warns when a () is inserted or an argument list is implicitly
tupled. The latter errors under the same conditions. Using these options
I found several bugs in the distribution which would otherwise be nearly
impossible to spot. These bugs were innocuous (I think) but similar bugs
could easily be (and have been) otherwise.

Certain particularly threatening scenarios are at minimum warned about
regardless of options given. Closes #4851, no review.

@scabug scabug closed this as completed Jul 29, 2011
@scabug
Copy link
Author

scabug commented Jul 29, 2011

@paulp said:
OK, that's the best I can do for now. Give -Xlint a try.

@scabug
Copy link
Author

scabug commented Jul 29, 2011

Daniel Cardin (mrhightech) said:
Thanks ! I'll try with -Xlint and try to get it added to the IDE plugin.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants