Bug 278379 - [ErrorHandling] Misleading error for javax.swing.JLabel constructor
Summary: [ErrorHandling] Misleading error for javax.swing.JLabel constructor
Status: RESOLVED INVALID
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.4.2   Edit
Hardware: PC Windows Vista
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: JDT-UI-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-05-29 08:17 EDT by Jonathan Camilleri CLA
Modified: 2009-05-29 09:22 EDT (History)
2 users (show)

See Also:


Attachments
Source code (619 bytes, application/zip)
2009-05-29 08:17 EDT, Jonathan Camilleri CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Camilleri CLA 2009-05-29 08:17:10 EDT
Created attachment 137631 [details]
Source code

Build ID: Build id: M20090211-1700

Steps To Reproduce:
Consider the following code:
import javax.swing.*;
import java.awt.BorderLayout;
import java.awt.event.*;

@SuppressWarnings("serial")
public class AboutDialog extends JDialog {
	public AboutDialog(JFrame owner)
	{
		super(owner, "About Dialog Test", true);
		add (new JLabel ("<html><h1><i>Core Java</i></h1></html>",
				BorderLayout.CENTER));
//ERROR: The constructor JLabel(String, String) is undefined

		
		final JPanel panel = new JPanel(); //constructor has to be final, so I can't change it.
		final JButton ok = new JButton("Ok"); 
		
		ok.addActionListener(new ActionListener()
		{
			public void actionPerformed(ActionEvent event)
			{
				setVisible(false);
				panel.add(ok);
				add(panel, BorderLayout.SOUTH);
				
				setSize(250,150);
			}
		});
	}

}






More information:
NOTES:
Microsoft Windows [Version 6.0.6001]
Copyright (c) 2006 Microsoft Corporation.  All rights reserved.

C:\Users\Administrator>java -version
java version "1.6.0_13"
Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode, sharing)
Comment 1 Jonathan Camilleri CLA 2009-05-29 08:17:46 EDT
Further information at http://java.sun.com/javase/6/docs/api/javax/swing/JLabel.html
Comment 2 Remy Suen CLA 2009-05-29 08:31:07 EDT
1. I see no JLabel(String, String) constructor.

2. BorderLayout.CENTER is a java.lang.String.
http://java.sun.com/j2se/1.4.2/docs/api/java/awt/BorderLayout.html#CENTER

3. I do not see a problem here. Telling me "The constructor JLabel(String, String) is undefined" when the constructor does not exist sounds right to me.
Comment 3 Jonathan Camilleri CLA 2009-05-29 08:32:45 EDT
The point is that this error is misleading because other constructors are allowed according to the API.
Comment 4 Paul Webster CLA 2009-05-29 08:40:16 EDT
Jon,

1) please open Java (JDT) bugs against the JDT product
2) please read http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
- your bugs say things like "misleading" but you do not give an "expected result" ... a specific result.


As for this specific bug, the error is correct and accurate (that constructor does not exist).

IDEs (like Eclipse) then help you by providing Quick Fixes which often list things like "remove parameter" or "cast 2nd parameter" or "Create new function".  This is where the "power of suggestion" should be enhanced, if at all.

You can delete the arguments and use CTRL+SPACE to select one of the provided constructors as well.

PW
Comment 5 Paul Webster CLA 2009-05-29 08:40:56 EDT
Reopening.
Comment 6 Paul Webster CLA 2009-05-29 08:42:15 EDT
.
Comment 7 Jonathan Camilleri CLA 2009-05-29 09:07:29 EDT
Well, thank you for the useful feedback, I do make it a point to be as clear as possible, however, I tend to think in phases, the first of which simply being 
What is the problem? Can you give an example?

Sometimes a solution or suggestion doesn't "popup" readily, but I've had a few ideas, which I hope do not sound intrusive:

1. Include all possible variations to every method call prior to reporting an error to the user.
2. Another issue is that some of my code (being a bit dumb and green) sometimes just has "a lot of errors", and, whether I have pasted it from somewhere or done it myself, I still don't know what is going on.  So the problem is that of troubleshooting the issue.  The error messages at that stage might actually be confusing, because I would try to focus on the logic of the program, and, in the meantime I would get popups reading 'this should be changed to that'.  

So, although this suggestion is inconcrete, one may consider using metrics that measure certain aspects of the code.

The following document might illustrate the concept:
http://ieeexplore.ieee.org/Xplore/login.jsp?url=http://ieeexplore.ieee.org/iel3/4850/13403/00613302.pdf%3Farnumber%3D613302&authDecision=-203

Another dumb question that comes to mind is:
If I have a humungous piece of code, like the ones used for creating desktop control graphics, how does Eclipse help me understand where the various groups and layout map to the design?  Honestly I prefer using a UI builder after having tried to understand layout etc, and, in production environments most of the time you're expected to use "the fastest road to meet the deadline", because nobody will appreciate the beauty of the architecture unless they have the end product.  However, what about the Java techies that hand code their desktop interfaces line by line?  

NOTE: The mid-aid collisions are a bit annoying, can't you have the bug tracker queue comments rather than locking the bug report :)  I was writing something then I forgot what I was going to say, and, since I read that my comment was added, I didn't bother about it.
Comment 8 Paul Webster CLA 2009-05-29 09:22:05 EDT
(In reply to comment #7)
> Well, thank you for the useful feedback, I do make it a point to be as clear as
> possible, however, I tend to think in phases, the first of which simply being 
> What is the problem? Can you give an example?

You have been supplying demonstration snippets which are very useful (and much appreciated :-)  But it is really important to include a concrete "expect result" of some kind.

> 1. Include all possible variations to every method call prior to reporting an
> error to the user.

This is I think where the confusion is ... the compiler is reporting the error (that's its job).  The IDE can suggest fixes, but how accurate they are depend on how much context the error itself has.


> 2. Another issue is that some of my code (being a bit dumb and green) sometimes
> just has "a lot of errors", and, whether I have pasted it from somewhere or
> done it myself, I still don't know what is going on.

When this happens, the SOP is to start with the first error and fix it.  Once the file is broken (some errors are self contained and don't effect the rest of the file) then errors simply need to be eliminated one at a time, starting at the top.  The end goal is to have the entire file compile, anyway :-)


> Another dumb question that comes to mind is:
> If I have a humungous piece of code, like the ones used for creating desktop
> control graphics, how does Eclipse help me understand where the various groups
> and layout map to the design?

This is a UI designer type problem, not really java.  You would need a tool for that, essentially one that can reverse engineer UIs, and way out of the scope of JDT or the IDE.


> 
> NOTE: The mid-aid collisions are a bit annoying, can't you have the bug tracker
> queue comments rather than locking the bug report :) 

This gets me occasionally as well :-)  ... I back up, copy out my comment, and then reset the bug and paste (not elegant, but it works).

PW