Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #36751 > unrolled thread

Eclipse

Back to article view | Back to comp.lang.java.programmer

Contents

  Eclipse Eric Douglas <e.d.programmer@gmail.com> - 2017-06-28 07:57 -0700
    Re: Eclipse Eric Douglas <e.d.programmer@gmail.com> - 2017-06-28 09:04 -0700
      Re: Eclipse Eric Douglas <e.d.programmer@gmail.com> - 2017-06-28 12:07 -0700
        Re: Eclipse Eric Douglas <e.d.programmer@gmail.com> - 2017-06-29 06:05 -0700
          Re: Eclipse Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-29 09:32 -0400
            Re: Eclipse Eric Douglas <e.d.programmer@gmail.com> - 2017-06-29 06:42 -0700
          Re: Eclipse Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-06-29 09:47 -0400
            Re: Eclipse Andreas Leitgeb <avl@logic.at> - 2017-06-30 14:47 +0000
              Re: Eclipse Eric Douglas <e.d.programmer@gmail.com> - 2017-06-30 08:22 -0700
                Re: Eclipse Eric Douglas <e.d.programmer@gmail.com> - 2017-07-07 06:19 -0700
                  Re: Eclipse Andreas Leitgeb <avl@logic.at> - 2017-07-13 09:29 +0000
          Re: Eclipse Martin Gregorie <martin@address-in-sig.invalid> - 2017-06-29 17:18 +0000
            Re: Eclipse Eric Douglas <e.d.programmer@gmail.com> - 2017-06-29 11:08 -0700
              Re: Eclipse Martin Gregorie <martin@address-in-sig.invalid> - 2017-06-29 18:58 +0000
                Re: Eclipse Eric Douglas <e.d.programmer@gmail.com> - 2017-06-29 12:55 -0700
                  Re: Eclipse Martin Gregorie <martin@address-in-sig.invalid> - 2017-06-29 21:31 +0000
                    Re: Eclipse Eric Douglas <e.d.programmer@gmail.com> - 2017-06-30 04:55 -0700
                      Re: Eclipse Martin Gregorie <martin@address-in-sig.invalid> - 2017-06-30 13:02 +0000
                Re: Eclipse Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-06-29 16:34 -0400
                  Re: Eclipse Eric Douglas <e.d.programmer@gmail.com> - 2017-06-29 13:49 -0700
                    Re: Eclipse Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-06-29 18:16 -0400
    Re: Eclipse Arne Vajhøj <arne@vajhoej.dk> - 2017-07-02 11:56 -0400

Page 1 of 2  [1] 2  Next page →

#36751 — Eclipse

Am I doing something wrong?  I download the Eclipse Oxygen installer and I point it to the same folder where I have Eclipse Neon installed because I don't want to lose any preferences.  It says it installed, then it starts and I go to help about and it still shows Neon.

[toc] | [next] | [standalone]

#36752

On Wednesday, June 28, 2017 at 10:58:08 AM UTC-4, Eric Douglas wrote:
> Am I doing something wrong?  I download the Eclipse Oxygen installer and I point it to the same folder where I have Eclipse Neon installed because I don't want to lose any preferences.  It says it installed, then it starts and I go to help about and it still shows Neon.

So, the Eclipse download page (http://www.eclipse.org/downloads/eclipse-packages/) says the installer is "the easiest way to install AND UPDATE your Eclipse environment).

The FAQ page (https://wiki.eclipse.org/FAQ_How_do_I_upgrade_Eclipse_IDE%3F) actually has the warning "We strongly recommend against installing/unzipping over your existing version of Eclipse IDE as it may corrupt your installation".

Despite the installer, there is no uninstaller and it doesn't show in the Windows Programs list.  So apparently the only solution if you installed it when you were supposed to run it and select update from the menu, is to delete the eclipse folder and do another fresh install which loses the preferences.  I figured it would, so I did the export on the code style clean up and formatter, and screen shots on the compiler errors/warnings setup since there's no export.  Now to tell if anything else was lost.

[toc] | [prev] | [next] | [standalone]

#36755

So I got a clean install of Oxygen, comparing to Neon with screenshots of warning preferences and they've added warnings.

"Unlikely argument type for collection methods using 'Object'", with an optional "Perform strict analysis against the expected type"

"Unlikely argument type for method equals()"

So I got this first warning on a .contains() of an ArrayList<> defined to hold objects implementing my custom interface, checking an instance of Component.  This is valid code, and it's only suggestions are to add a @SuppressWarnings, or configure warning severity.

[toc] | [prev] | [next] | [standalone]

#36762

On Wednesday, June 28, 2017 at 3:07:29 PM UTC-4, Eric Douglas wrote:
> So I got this first warning on a .contains() of an ArrayList<> defined to hold objects implementing my custom interface, checking an instance of Component.  This is valid code, and it's only suggestions are to add a @SuppressWarnings, or configure warning severity.

Is there a proper way to make this message go away, or do I just add @SuppressWarnings or change this "error" to completely ignore?
I have some different types of JComponent classes which implement MyCustomInterface, and some JComponent which do not implement.
I have a class level variable defined as ArrayList<MyCustomInterface>.
I have a method parameter passing in a Component.
My ArrayList variable calls .contains() to check against that component.
It wants to warn me this is unlikely.  It's very likely.

[toc] | [prev] | [next] | [standalone]

#36763

On 6/29/2017 9:05 AM, Eric Douglas wrote:
> On Wednesday, June 28, 2017 at 3:07:29 PM UTC-4, Eric Douglas wrote:
>> So I got this first warning on a .contains() of an ArrayList<> defined to hold objects implementing my custom interface, checking an instance of Component.  This is valid code, and it's only suggestions are to add a @SuppressWarnings, or configure warning severity.
> 
> Is there a proper way to make this message go away, or do I just add @SuppressWarnings or change this "error" to completely ignore?
> I have some different types of JComponent classes which implement MyCustomInterface, and some JComponent which do not implement.
> I have a class level variable defined as ArrayList<MyCustomInterface>.
> I have a method parameter passing in a Component.
> My ArrayList variable calls .contains() to check against that component.
> It wants to warn me this is unlikely.  It's very likely.
> 

Did you ask Eclipse support?  They know their product much better than
anyone here would.  They have a forum, mailing lists and even an IRC
channel.  And if you think it's a bug, you can report it to them.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#36764

On Thursday, June 29, 2017 at 9:32:18 AM UTC-4, Jerry Stuckle wrote:
> 
> Did you ask Eclipse support?  They know their product much better than
> anyone here would.  They have a forum, mailing lists and even an IRC
> channel.  And if you think it's a bug, you can report it to them.
> 

Just wondering if anyone here understands this new error, and knows some syntax I'm not aware of to avoid it.  I tried something like declaring the variable as ArrayList<JComponent implements MyInterface> but it doesn't like that...

[toc] | [prev] | [next] | [standalone]

#36765

On 6/29/2017 9:05 AM, Eric Douglas wrote:
> On Wednesday, June 28, 2017 at 3:07:29 PM UTC-4, Eric Douglas wrote:
>> So I got this first warning on a .contains() of an ArrayList<> defined to hold objects implementing my custom interface, checking an instance of Component.  This is valid code, and it's only suggestions are to add a @SuppressWarnings, or configure warning severity.
> 
> Is there a proper way to make this message go away, or do I just add @SuppressWarnings or change this "error" to completely ignore?
> I have some different types of JComponent classes which implement MyCustomInterface, and some JComponent which do not implement.
> I have a class level variable defined as ArrayList<MyCustomInterface>.
> I have a method parameter passing in a Component.
> My ArrayList variable calls .contains() to check against that component.
> It wants to warn me this is unlikely.  It's very likely.

     To recapitulate:

     - You have an ArrayList that is supposed to contain objects that
implement MyCustomInterface.

     - You have an object that is known to be a Component.

     - There are lots and lots and lots of Component classes that do
not implement MyCustomInterface.

     - Therefore, it is at the very least "suspicious" that a list of
MyCustomInterface instances is being examined for the presence of
something that (for all Java knows) needn't implement MyCustomInterface.

     It certainly doesn't strike me as an "error" to check for the
presence of something that isn't there, or even of something that
might turn out to be there under a different guise (a Component
that does, in fact, implement MyCustomInterface).  Nonetheless, it
does seem "suspicious," just as it would be "suspicious" to look
for a raw Component in a List<JButton>.  Not as suspicious as looking
for a JButton in a List<String>, but certainly odd.

     You've shown no code so I can't make a solid recommendation,
but here are a few things you might consider:

     - Use an ArrayList<Component>

     - if (comp instanceof MyCustomInterface
	   && list.contains((MyCustomInterface) comp))

     - @SuppressWarnings plus a lengthy comment

     I would *not* recommend defeating the warning altogether, as
that would apply to a much wider scope.  If something you're cooking
sets off the smoke detector, it would be ill-advised to respond by
taking the batteries out of all detectors everywhere ...

-- 
esosman@comcast-dot-net.invalid
Thirteen hundred one days to go.

[toc] | [prev] | [next] | [standalone]

#36777

It's a pity, that this imho-most-to-the-point post seems to have drowned
among all the others...  Main reason for my followup is really to give
it another chance to being seen, but I hope my answer isn't entirely
worthless beyond that goal.

Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
>      To recapitulate:
>      - You have an ArrayList that is supposed to contain objects that
> implement MyCustomInterface.
>      - You have an object that is known to be a Component.
>      - There are lots and lots and lots of Component classes that do
> not implement MyCustomInterface.
>      - Therefore, it is at the very least "suspicious" that a list of
> MyCustomInterface instances is being examined for the presence of
> something that (for all Java knows) needn't implement MyCustomInterface.

>      It certainly doesn't strike me as an "error" to check for the
> presence of something that isn't there, or even of something that
> might turn out to be there under a different guise (a Component
> that does, in fact, implement MyCustomInterface).  Nonetheless, it
> does seem "suspicious,"

so far yes...

> just as it would be "suspicious" to look
> for a raw Component in a List<JButton>.

The case, where the reference type of the "needle" object is a
superclass or superinterface of the hay-type (of the haystack)
is a tad *less* suspicious, imho.

The case at hand, where these two types are just unrelated 
to Java's knowledge-at-the-point is somewhat suspicious. 

> Not as suspicious as looking
> for a JButton in a List<String>, but certainly odd.

This would indeed be a quite a tad *more* suspicious, namely in so
far as Java doesn't even let you explicitly directly *cast* JButton
to String.

>      - if (comp instanceof MyCustomInterface
>            && list.contains((MyCustomInterface) comp))

This is what I'd have suggested to Eric D., too.

I'd even see it as a serendipituous runtime benefit: no need
to even scan the list, if there's no chance of a hit in the first
place. That even counts for me as "algorithmic optimization" of
sort "don't do goofy things", rather than the usual "premature" one.

>      - @SuppressWarnings plus a lengthy comment

I think, I once saw it happen that a SuppressWarnings added for one 
Java compiler actually caused a warning about the "unnecessary"
suppresion by another Java compiler (iirc, it was netbeans versus
eclipse, but I only saw the eclipse side, and knew that someone
else was working on the project with netbeans, so it is possible that 
netbeans even showed the same warning) - I also don't remember the
annotation's argument (i.e. what warning even was to be suppressed)

Anyway, I'm reluctant about adding @SuppressWarnings for IDE-specific
warnings.

>      I would *not* recommend defeating the warning altogether

I usually do disable the IDE warnings about missing serialId fields,
but that's a different case. I agree, that the warning at hand is 
instead a generally useful one and rather not one to just disable
globally.

[toc] | [prev] | [next] | [standalone]

#36778

On Friday, June 30, 2017 at 10:51:12 AM UTC-4, Andreas Leitgeb wrote:
> >      - if (comp instanceof MyCustomInterface
> >            && list.contains((MyCustomInterface) comp))
> 
> This is what I'd have suggested to Eric D., too.
> 
> I'd even see it as a serendipituous runtime benefit: no need
> to even scan the list, if there's no chance of a hit in the first
> place. That even counts for me as "algorithmic optimization" of
> sort "don't do goofy things", rather than the usual "premature" one.
> 

Aha.  I did overlook that point.  While it is slightly more wordy, it may be more efficient if you're searching a relatively large array.
given: ArrayList<MyCustomInterface> myArray, and Component c
instead of if (!myArray.contains(c)), it doesn't complain if we write if (!(oc instanceof MyCustomInterface) || !myArray.contains((MyCustomInterface)c)).

> 
> I usually do disable the IDE warnings about missing serialId fields,
> but that's a different case. I agree, that the warning at hand is 
> instead a generally useful one and rather not one to just disable
> globally.

I've found the serial ID unnecessary and just disabled all those warnings, but I'm only running my API in webstart so I know the class I'm serializing from a JVM on a server to a JVM on a client PC is the same class.

Oracle adds the big warning comment that all their serializable classes may not be able to serialize from one JVM to another if they're running different versions.

[toc] | [prev] | [next] | [standalone]

#36810

On Friday, June 30, 2017 at 11:23:01 AM UTC-4, Eric Douglas wrote:
> On Friday, June 30, 2017 at 10:51:12 AM UTC-4, Andreas Leitgeb wrote:
> > >      - if (comp instanceof MyCustomInterface
> > >            && list.contains((MyCustomInterface) comp))
> > 
> > This is what I'd have suggested to Eric D., too.
> > 
> > I'd even see it as a serendipituous runtime benefit: no need
> > to even scan the list, if there's no chance of a hit in the first
> > place. That even counts for me as "algorithmic optimization" of
> > sort "don't do goofy things", rather than the usual "premature" one.
> > 
> 
> Aha.  I did overlook that point.  While it is slightly more wordy, it may be more efficient if you're searching a relatively large array.
> given: ArrayList<MyCustomInterface> myArray, and Component c
> instead of if (!myArray.contains(c)), it doesn't complain if we write if (!(oc instanceof MyCustomInterface) || !myArray.contains((MyCustomInterface)c)).
> 

Eclipse conflicts itself.
given: ArrayList<MyCustomInterface> myArray, and Component c

instead of if (!myArray.contains(c)), it doesn't complain if we write if (!(oc instanceof MyCustomInterface) || !myArray.contains((MyCustomInterface)c)).

Source > Cleanup has an option 'Remove unnecessary casts'.  If you use this it does remove this cast on the (MyCustomInterface)c, then it throws the new 'Unlikely type argument' error on that line.  Either the cast is necessary and I need to remove that cleanup option, or it's not necessary and I need to completely ignore that error/warning (or add the @SuppressWarnings("unlikely-arg-type")).

[toc] | [prev] | [next] | [standalone]

#36876

Eric Douglas <e.d.programmer@gmail.com> wrote:
> Eclipse conflicts itself.
> given: ArrayList<MyCustomInterface> myArray, and Component c
>
> instead of if (!myArray.contains(c)), it doesn't complain if we write
> if (!(oc instanceof MyCustomInterface) || !myArray.contains((MyCustomInterface)c)).
>
> Source > Cleanup has an option 'Remove unnecessary casts'.  If you use this it does
> remove this cast on the (MyCustomInterface)c, then it throws the new
> 'Unlikely type argument' error on that line.  Either the cast is necessary and
> I need to remove that cleanup option, or it's not necessary and I need to
> completely ignore that error/warning (or add the @SuppressWarnings("unlikely-arg-type")).

Good catch!  I'd call it a bug.

Did you report it on some eclipse bug-tracker?   (if you intend to do it,
first check if it hasn't already been reported, of course.)

[toc] | [prev] | [next] | [standalone]

#36766

On Thu, 29 Jun 2017 06:05:31 -0700, Eric Douglas wrote:

> I have some different types of JComponent classes which implement
> MyCustomInterface, and some JComponent which do not implement.
> I have a class level variable defined as ArrayList<MyCustomInterface>.
>
Shouldn't you be using the name of the class that implements the 
MyCustomInterface Interface rather than the name of the Interface?


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#36767

On Thursday, June 29, 2017 at 1:22:13 PM UTC-4, Martin Gregorie wrote:
> On Thu, 29 Jun 2017 06:05:31 -0700, Eric Douglas wrote:
> 
> > I have some different types of JComponent classes which implement
> > MyCustomInterface, and some JComponent which do not implement.
> > I have a class level variable defined as ArrayList<MyCustomInterface>.
> >
> Shouldn't you be using the name of the class that implements the 
> MyCustomInterface Interface rather than the name of the Interface?
> 
> 

That's why it's an interface.  This array holds instances of several different classes which implement the interface.  They're all components and they all require custom methods described in the interface.  They come from different classes, one might extend JTextField, another extends JComboBox.  I need to check this group of controls against generic Component because I'm looking at the values from getComponent() and getOppositeComponent() in a focusGained().

[toc] | [prev] | [next] | [standalone]

#36768

On Thu, 29 Jun 2017 11:08:26 -0700, Eric Douglas wrote:

> On Thursday, June 29, 2017 at 1:22:13 PM UTC-4, Martin Gregorie wrote:
>> On Thu, 29 Jun 2017 06:05:31 -0700, Eric Douglas wrote:
>> 
>> > I have some different types of JComponent classes which implement
>> > MyCustomInterface, and some JComponent which do not implement.
>> > I have a class level variable defined as
>> > ArrayList<MyCustomInterface>.
>> >
>> Shouldn't you be using the name of the class that implements the
>> MyCustomInterface Interface rather than the name of the Interface?
>> 
>> 
>> 
> That's why it's an interface.  This array holds instances of several
> different classes which implement the interface.  They're all components
> and they all require custom methods described in the interface.  They
> come from different classes, one might extend JTextField, another
> extends JComboBox.  I need to check this group of controls against
> generic Component because I'm looking at the values from getComponent()
> and getOppositeComponent() in a focusGained().

Err, not really. An Interface defines a set of methods that must all be 
defined by an Interface but is not a Class anbd I think thats what is 
making Eclipse spit.

I think you need to declare the various classes that implement 
MyCustomInterface into subclasses of an (abstract?) superclass that 
extends JContainer which, at a quick glance, inherits the methods you 
mention from Container and Component. 


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#36769

On Thursday, June 29, 2017 at 3:02:15 PM UTC-4, Martin Gregorie wrote:
> Err, not really. An Interface defines a set of methods that must all be 
> defined by an Interface but is not a Class anbd I think thats what is 
> making Eclipse spit.
> 
> I think you need to declare the various classes that implement 
> MyCustomInterface into subclasses of an (abstract?) superclass that 
> extends JContainer which, at a quick glance, inherits the methods you 
> mention from Container and Component. 
> 

That is the problem.  These are all Component, as the focusGained() refers to them, or JComponent but they're different components.  They are already subclasses of the various components (JTextField, JTextArea, JComboBox, JSpinner) so they can't subclass an abstract class so they have to use the interface.  The ArrayList has to refer to it's elements with the interface or else I'd have to declare it as ArrayList<JComponent> and assume we're only adding objects to it which implement the interface, and every time I want to call an interface method on an object in the array I have to cast the object.  Unless I'm missing something?  Like I said you can't just define both ways as ArrayList<JComponent implements MyCustomInterface>, I tried that.

[toc] | [prev] | [next] | [standalone]

#36772

On Thu, 29 Jun 2017 12:55:26 -0700, Eric Douglas wrote:

> On Thursday, June 29, 2017 at 3:02:15 PM UTC-4, Martin Gregorie wrote:
>> Err, not really. An Interface defines a set of methods that must all be
>> defined by an Interface but is not a Class anbd I think thats what is
>> making Eclipse spit.
>> 
>> I think you need to declare the various classes that implement
>> MyCustomInterface into subclasses of an (abstract?) superclass that
>> extends JContainer which, at a quick glance, inherits the methods you
>> mention from Container and Component.
>> 
>> 
> That is the problem.  These are all Component, as the focusGained()
> refers to them, or JComponent but they're different components.  They
> are already subclasses of the various components (JTextField, JTextArea,
> JComboBox, JSpinner) so they can't subclass an abstract class so they
> have to use the interface.  The ArrayList has to refer to it's elements
> with the interface or else I'd have to declare it as
> ArrayList<JComponent> and assume we're only adding objects to it which
> implement the interface, and every time I want to call an interface
> method on an object in the array I have to cast the object.  Unless I'm
> missing something?  Like I said you can't just define both ways as
> ArrayList<JComponent implements MyCustomInterface>, I tried that.

Understood.

What does your MyCustomInterface contribute to making it easier to handle 
the different types of objects?

Would it help to do something like declaring a MyClass that extends 
Component and implements MyCustomInterface and that is passed the 
JTextField, etc as constructor argument? At least this should avoid your 
casting problem.

Apart from that all I can suggest is that, after double checking that 
your classes compile correctly when javac is run either manually of via 
ant outside the Eclipse environment, you ask the Eclipse project why this 
has started to happen in this version and/or file a bug against Eclipse.

Filing bugs is very much in the FOSS ethos - IMO you should regard the 
work involved in posting good, well documented bug reports as your 
contribution to the Eclipse project.  Put another way, users of 
commercial software pay cash: FOSS users pay by testing, reporting bugs 
and making sensible enhancement suggestions.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#36774

On Thursday, June 29, 2017 at 5:35:03 PM UTC-4, Martin Gregorie wrote:
> Would it help to do something like declaring a MyClass that extends 
> Component and implements MyCustomInterface and that is passed the 
> JTextField, etc as constructor argument? At least this should avoid your 
> casting problem.
> 

It seems that could work.  Instead of making an array of objects that implement an interface that Eclipse is uncertain if they may be components, I just make an array of component wrappers.
public class ComponentWrapper extends Component implements MyCustomInterface{
 final MyCustomInterface wrapped;
 public ComponentWrapper(final MyCustomInterface arg){
  wrapped = arg;
 }
 public void interfaceMethod(){
  wrapped.interfaceMethod();
 }
}

[toc] | [prev] | [next] | [standalone]

#36775

On Fri, 30 Jun 2017 04:55:18 -0700, Eric Douglas wrote:

> On Thursday, June 29, 2017 at 5:35:03 PM UTC-4, Martin Gregorie wrote:
>> Would it help to do something like declaring a MyClass that extends
>> Component and implements MyCustomInterface and that is passed the
>> JTextField, etc as constructor argument? At least this should avoid
>> your casting problem.
>> 
>> 
> It seems that could work.  Instead of making an array of objects that
> implement an interface that Eclipse is uncertain if they may be
> components, I just make an array of component wrappers.
> public class ComponentWrapper extends Component implements
> MyCustomInterface{
>  final MyCustomInterface wrapped;
>  public ComponentWrapper(final MyCustomInterface arg){
>   wrapped = arg;
>  }
>  public void interfaceMethod(){
>   wrapped.interfaceMethod();
>  }
> }

Yep. If a minimal version, i.e. with as little code as possible inside 
it, lets you compile your TableModel extension without complaint it's 
likely you've cracked it.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#36770

On 6/29/2017 2:58 PM, Martin Gregorie wrote:
> On Thu, 29 Jun 2017 11:08:26 -0700, Eric Douglas wrote:
> 
>> On Thursday, June 29, 2017 at 1:22:13 PM UTC-4, Martin Gregorie wrote:
>>> On Thu, 29 Jun 2017 06:05:31 -0700, Eric Douglas wrote:
>>>
>>>> I have some different types of JComponent classes which implement
>>>> MyCustomInterface, and some JComponent which do not implement.
>>>> I have a class level variable defined as
>>>> ArrayList<MyCustomInterface>.
>>>>
>>> Shouldn't you be using the name of the class that implements the
>>> MyCustomInterface Interface rather than the name of the Interface?
>>>
>>>
>>>
>> That's why it's an interface.  This array holds instances of several
>> different classes which implement the interface.  They're all components
>> and they all require custom methods described in the interface.  They
>> come from different classes, one might extend JTextField, another
>> extends JComboBox.  I need to check this group of controls against
>> generic Component because I'm looking at the values from getComponent()
>> and getOppositeComponent() in a focusGained().
> 
> Err, not really. An Interface defines a set of methods that must all be
> defined by an Interface but is not a Class anbd I think thats what is
> making Eclipse spit.

     I doubt it (although my Eclipse experience is both little and
long ago).  There's certainly nothing wrong from Java's point of
view: You can have a List<Runnable>, for example, and populate it
with instances of many different classes implementing Runnable,
none with a common ancestor other than Object.

> I think you need to declare the various classes that implement
> MyCustomInterface into subclasses of an (abstract?) superclass that
> extends JContainer which, at a quick glance, inherits the methods you
> mention from Container and Component.

     Insisting on a particular inheritance hierarchy would be rather
limiting.  To put it another way, what are interfaces *for*?

     Now that we've learned where the Component reference comes from,
we can begin to speculate about what's going on: The O.P. has a
FocusListener, and wants to know whether the focus loser or focus
gainer (or perhaps both) is on a list of "special" instances that
all happen to implement MyCustomInterface.  (We don't know whether
the list contains all MyCustomInterface implementations or only some
of them; but we know everything on the list is such an implementation.)
So he does `list.contains(event.getComponent())' and Eclipse alerts him
that the query is a trifle odd.  It is in fact what he wants to do, but
Eclipse's eyebrows arch upward anyhow.

     The question I'd ask is: What does the Component's presence in (or
absence from) the List<MyCustomInterface> tell us?  That is, what will
the code do differently if the answer is "Here!" rather than "Huh?"
And -- here's the nub -- could the different action be handled more
smoothly by overriding focusGained() and/or focusLost() in the
MyCustomInterface implementation?

     Maybe not, but that's the question I'd ask to start with.

-- 
esosman@comcast-dot-net.invalid
Thirteen hundred one days to go.

[toc] | [prev] | [next] | [standalone]

#36771

On Thursday, June 29, 2017 at 4:34:59 PM UTC-4, Eric Sosman wrote:
>      The question I'd ask is: What does the Component's presence in (or
> absence from) the List<MyCustomInterface> tell us?  That is, what will
> the code do differently if the answer is "Here!" rather than "Huh?"
> And -- here's the nub -- could the different action be handled more
> smoothly by overriding focusGained() and/or focusLost() in the
> MyCustomInterface implementation?
> 
>      Maybe not, but that's the question I'd ask to start with.

This component, which is checking for focusGains on this array of components, has it's own list of listeners.  It is reporting a focusGain/focusLost event to those whenever one of these components gains or loses focus except if the focus came from one of these components and went to one of these components.  This custom event needs to treat these components as a group.

The only way I can see to get rid of the warning is to break it up to tell it they're components.

myComponentArray.contains(focusComponent)

becomes

for (MyCustomInterface i : myComponentArray)
 if (((Component)i).equals(focusComponent)) {
 }
}

I don't know any way to tell it for certain that yes any class which implements this interface does also extend Component.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web