Brian Cole

Campbell Ritchie wrote:That could have shown return this; or return new Test3();

The point is that the method is called, so any side-effects do happen, but what value it returns is irrelevant.

By the way: which section in the JLS?

It's in §15.11.1. (BTW, I happen to be looking at the Java SE 7 edition of the JLS.)

Campbell Ritchie wrote:You can still write rubbish like((Arrays)null).sort(numbers);...and it will both compile and run with the expected result.

I agree. In fact the JLS shows this nifty example:class Test3 {    static String mountain = "Chocorua";    static Test3 favorite(){        System.out.print("Mount ");        return null;    }    public static void main(String[] args) {        System.out.println(favorite().mountain); // prints "Mount Chocorua" (by way of a call to print followed by a call to println)    } }
What I was trying to get at was there was, at one point in the distant past (for Java), a time when the javac compiler was handling nullInstance.staticMethod(...) incorrectly w.r.t. the JLS.

When this was discovered they either changed the compiler or changed the JLS, but I can't find any corroborating details. I've spent a few minutes googling and have struck out. I guess it's possible it never happened and I made it up.

it would have been clearer to just write Animal.staticMethod(...) and be done with it

I realized what you were doing. In saying this I was not trying to imply otherwise, was just trying to answer your "which one is actually executed?" question for the benefit of others. I apologize for being less than clear.

Ricky Bee wrote:but let me rephrase my previous question (and steer it a little from the inheritance of a static method problem which originated it in the first place):

FYI, one should be careful using the term inheritance with static methods. Which is not to say that a subclass can't inherit static methods, because they often do, but it's best to be precise.

In Campbell Ritchie's example, for example, the Lion class does not inherit the method staticMethod() from Animal because it's hidden by its own implementation of staticMethod(). Here hidden is a formal term defined by §8.4.8.2 of the Java Language Specification. (See also the first sentence of §8.4.8.)

Ricky Bee wrote:is such a structure a common-place in Java programing? I mean, is it normal to instantiate an object from a superclass and then pass it an object from a subclass?

I would say it's somewhat common. For example, in my code I often write
List<SomeType> myList = new ArrayList<>();Now this isn't quite the same, because List is an interface and not a class, but the concept is the same.
I want the rest of my code to treat myList as a generic List without presuming any specific implementation. Then later I can easily change the implementation from ArrayList to something else (such as LinkedList) if I want.

To use Campbell Ritchie's example...
Animal a = new Lion("Simba", ...); a = new Elephant("Jumbo", ...); //assume each of the Animal, Lion, and Elephant classes has a method called staticMethod()...it wouldn't be unusual to do
Animal[] myArray = { new Lion(), new Elephant(), new Wombat() };and it would be even less unusual to use a Collection instead of an array. Consider
List<Animal> myList = Arrays.asList( new Lion(), new Elephant(), new Wombat() );where it's kind of happening twice. The List's type parameter is Animal but the each element of myList is a some subclass of Animal. And also the type of myList is List but the asList() method will return a particular implementation of List.

In swing this of course happens all the time, with java.awt.Component, javax.swing.JComponent, and all the subclasses of JComponent. When you write myPanel.add(new JButton("text")) the type of the argument is Component but you're passing it instance of JButton. And calling myPanel.getComponents() returns an array of type Component[] but each element of the array will be some particular subclass of Component. (But this isn't quite what you were asking.)

Junilu Lacar wrote:Campbell is trying to point out an example where a call using a object reference instead of a class reference actually does more than just make the code confusing

But it doesn't. In Campbell's example all the Lion and Elephant instances are doing is trying to cause more confusion. The confusion is intentional, of course, but it would have been clearer to just write Animal.staticMethod(...) and be done with it.

I'm not saying that calling instanceVariable.staticMethod() is always exactly the same as ClassName.staticMethod() for all contrived examples, because it's not if instanceVariable is null (although early compilers had a bug that missed this) but it is indeed the same in this particular JColorChooser.showDialog(...) case.

Sam Ritter wrote:Sorry about the confusion. It started as what I thought was a simple issue of static methods. It evolved into more details about what I was doing. Responses made it clear my entire approach was wrong (i.e. poor programming practices).

Well, part of it is that you are confused about calling static methods. You don't seem to realize that doing this...JColorChooser chooserInstance = new JColorChooser(); chooserInstance.showDialog(...);...is exactly the same as doingJColorChooser.showDialog(...);
The fact the first one instantiates a specific instance of JColorChooser doesn't change anything, except add confusion that it might somehow be relevant to the showDialog() method when it's not.

The reason people (and also the IDE) recommend you do it the second way and not the first way is not because it works any better (which it doesn't—it works exactly the same) but because it's less confusing.

You might want to read a tutorial on how Swing's cell editors and cell renders are supposed to work. Typically the same editor object will be used and re-used no matter which row is being edited, which would explain the behavior you're seeing.

But, beyond that, you shouldn't really need to create a custom cell editor if you want your JTable to display checkboxes. There are built-in cell editors for that, so all you need to do is make sure your TableModel returns Boolean.class in its getColumnClass() method [and also make sure to actually return Boolean.TRUE or Boolean.FALSE in its getValueAt() method]. And if you want to know whether a given row is checked or not, you should not ask the cell editor (nor the cell renderer) but just ask the TableModel directly: myTable.getModel().getValueAt(row, column)

You haven't shown us how you're dealing with your TableModel, except that it's either DefaultTableModel or a subclass. In general I would recommend creating your own table model that extends AbstractTableModel rather than using DefaultTableModel for almost any use case. But that's irrelevant for this checkbox stuff, because either approach should work. However it's weird that your addRow() method creates a zero-length array to pass to DefaultTableModel.addRow(). Presumably your table model has at least one column, or else there would be no cells to have cell editors for.

BTW you can add JCheckBoxes to a ButtonGroup if you want, to answer the original question. But I agree that from a UI perspective JRadioButtons make more sense.

Have you tried experimenting with myButton.setContentAreaFilled(true) yet?
It may be that Netbeans is using a different look and feel, or something like that, which is setting this property differently.

If you perform this search it will return a bunch of hits.

At the time I'm writing this, the first hit is this thread. The second is https://coderanch.com/p/3268303 which interestingly has a capital Y in the excerpt on the search result page, but the Y is lower case if you follow the link and look at the page itself.

Same deal for  and https://coderanch.com/p/3268176 and https://coderanch.com/p/3268005 . Both of those show capital Y in the search results excerpts and lower-case Y on the post themselves. Obviously they should be capitalized, since they start sentences.

It seems that there is some code that looks for "you should" and creates a hyperlink to http://www.permies.com/t/36936/tnk/

That's fine, I guess, but there seems to be a bug where it replaces "You should" (with a capital 'Y)' to "you should" (with a lower-case 'y'). The result is that it looks like I've made an editorial mistake in my post, when I haven't. (Or rather, there are probably plenty of editorial mistakes, but this particular sentence that begins with a lower-case letter was not one of them.)

I tried to post this to the actual thread at http://www.permies.com/t/36936/tnk/ but I don't seem to have an account on that site.

Luke jaryszek wrote:But with this text pane i should have only place for 4 digits. (number from 1 to 100).

There are a couple of issues here, but IMHO the fundamental one is that setBounds() and setSize() simply do not work to set a component's size. That's because the container's LayoutManager that is automatically in place will clobber any size/bounds you might have tried to set. (If you're not using a LayoutManager at all, then those two methods will work, but it is not recommended to not use a LayoutManager except by experts who know what they are doing, and even then only rarely. The rest of this posting assumes that a LayoutManager is in place.)

A method that does work is setPreferredSize(). It's fine if you want to use setPreferredSize(), but Swing's text components generally provide simpler ways of setting size.

JTextPane doesn't, but the only reason to use JTextPane is if you want to handle text in different styles (such as some text in one font and some text in a different font). If you want text in a single style, you could use JTextArea, which has constructors which take rows and columns paramaters: new TextArea(1, 8) Or there are separate setRows() and setColumns() methods. But JTextArea only makes sense if you need to support multiple rows of text.

For a single-row text field you can use JTextField, which has constructors which take a columns parameter: new TextField(4) Or it has a setColumns() method. Or you might want to use a JSpinner instead of a JTextField.

minor footnote: With JTextField you sometimes must to set more columns than you actually need. That's because it sets the required text-width for the whole component, including its borders, but the left and right borders cut into the usable width. This is stupid, but it's been that way for decades and isn't going to change now.

Campbell Ritchie wrote:Does that code compile without event -> ?

Are you asking about my code or Mr. Souris's code?

My code needs something to replace the "...". It could be a call to a constructor of a named class, or an anonymous subclass, or something like "event -> someMethod()" (as you suggest).

The method reference expressions Mr. Souris uses should be fine, presuming you have java8 or later. They are more or less interchangable with lambdas.

Scott Eric Catalano wrote:So to re-iterate my question. The JButton and JMenuItem need to call the same Action Listener.

You can do something like this:ActionListener myListener = ...; // create your listener any way you want myButton.addActionListener(myListener); myMenuItem.addActionListener(myListener);Then they will both invoke the same listener no matter where you place them.


However that's probably not the way I would do it. I would usually create an instantiation of javax.swing.Action and pass it to the JButton and JMenuItem constructors:Action myAction = ...; JButton myButton = new JButton(myAction); JMenuItem myMenuItem = new JMenuItem(myAction);This is slightly more work but can be cleaner. (ActionExample)

Glen Chamisa wrote:It seems even when I use BI_RLE4, I get the same issue. However, with the other string types, BI_RGB and BI_BITFIELDS the program runs fine. Can someone explain this cos I don't understand the problem.

I don't know a whole lot about the BMP format, but the javadoc for javax.imageio.plugins.bmp.BMPImageWriteParam says, "If the specified compression scheme is not compatible with the type of image being written then the IOException will be thrown by the BMP image writer." It sounds like this is happening.

You might want to try calling getCompressionTypes() on your BMPImageWriteParam and examine what it returns. I can't say for sure that this would be helpful, but it might be.

peter m hayward wrote:can you expand upon the Never do I/O in a renderer

Because I/O is slow and renderers are intended to be fast. And even if I/O weren't slow, it would still be wasteful to call createImageIcon() more than once per image. And a renderer can and will be called many many times for each item in your list.

Mr. Camick's suggestion to make type of your ComboBox be a compound object that holds both text and an icon is sound. That's a good solid way to write your program.

Here's another way, where the type of the ComboBox can remain a simple String: public class MappedIconRenderer extends DefaultListCellRenderer {    private Map<?, ? extends Icon> map;        public MappedIconRenderer(Map<?, ? extends Icon> iconMap) {        map = iconMap;    }    @Override    public Component getListCellRendererComponent(JList<?> list, Object value, int index, boolean isSelected, boolean cellHasFocus) {        Component c = super.getListCellRendererComponent(list, value, index, isSelected, cellHasFocus);        setIcon(map.get(value)); // might be passing null as the Icon, which would be fine        return c; // or: return this; (c and this are the same object)    }        private static final long serialVersionUID = 1L; }

This way you load all your images up front, like this: Map<String, Icon> iconMap = new HashMap<>(); iconMap.put("hardback", createImageIcon("file:///C:/images/hardback.gif")); iconMap.put("paperback", ...); ... bindings.setRenderer(new MappedIconRenderer(iconMap));