File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes IDEs, Version Control and other tools and the fly likes Why am I receiving Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » IDEs, Version Control and other tools
Bookmark "Why am I receiving "Type mismatch" messages in the Eclipse 3.7 JavaScript Editor ?" Watch "Why am I receiving "Type mismatch" messages in the Eclipse 3.7 JavaScript Editor ?" New topic

Why am I receiving "Type mismatch" messages in the Eclipse 3.7 JavaScript Editor ?

Jay Damon
Ranch Hand

Joined: Jul 31, 2001
Posts: 282
This may be a question for the IDE forum but I thought I would post here first.

Ever since I upgraded to the Eclipse 3.7 IDE the JavaScript editor has begun showing a number of "Type mismatch" warnings in the Problems view. The following code example always seems to issue an "Type mismatch" warning on the line noted. However, I think the line where the warning is issued is is a legal assignment. Is it legal or not? Unfortunately the JavaScript editor does not seem to be consistent in the warning messages it issues. I get sporadic "Type mismatch" warning messages like:

"cannot convert from null to Boolean"
"cannot convert from HTMLElement to __element<number>"
"cannot convert from __anonymous<number to __anonymous><number>" (Note: The numbers always seem to be identical so this make absolutely no sense to me)
"cannot convert from String to __value<number>"

I thought JavaScript was a weakly typed language and that one could basically assign any value to any variable? I know I can suppress these warnings in the Eclipse IDE Preferences but, before I do so, I would like to understand why these warnings are being issued. Note that the code that these warnings flag works fine in all browsers. I would appreciate any comments or suggestions.

Marco Leise

Joined: Aug 22, 2011
Posts: 1
You are right in all you say. While Eclipse is mostly used by Java developers I can understand that the developers of the web tools packages try to make JavaScript feel a bit more like Java and I personally like that.
What the web tools try to do is infer the actual type of variables and function return values. This allows the code completion to only show the matching items. I have a big JavaScript application and I can tell you that this is really helpful and also more responsive than other approaches that just list everything. And while you can assign different data to a variable it will usually lead to confusion when someone else looks at the code. If you want to optimize the runtime performance it is also advisable to enable the JavaScript engines to make some assumptions like "x always contains an integer number".

Now to your code... I don't understand what you are trying to do there. But I found that the web tools are somewhat allergic to "{}". So I switched that out for "new Object()". I really hope the automatic type inference becomes better in the next releases though.
I have a case where a member of my class is initialized with null, but is otherwise of object type 'Button'. When I try to assign a 'Button' object to this member Eclipse tells me that Button cannot be converted to __result1. If on the other hand I initialize the member with "new Button()" no warning is produced.

If you want, you can make the code completion more precise by adding some JSDoc. It works great for function parameters that are objects. When you write "@param {Button} btn the button" Eclipse can use that information to 'follow' that object. It will know the type of other variables that you assign it to as in "this.btn = btn" and can infer the return type of methods called on it: "window = btn.getParent()". Since btn is a "Button" and has a method "getParent" that returns a "Window" it knows that "window" is of that type now.
I agree. Here's the link:
subject: Why am I receiving "Type mismatch" messages in the Eclipse 3.7 JavaScript Editor ?
It's not a secret anymore!