Ensign Expendable posted:

I have never heard of instanceof being a bad idea. You could do something like

code:

Instrument tabComponent = (Instrument)instrumentSettingsTabbedPane.getComponent(x);
instrumentSettings[x] = tabComponent.getSettings();

provided Instrument1 and Instrument2 are subclasses of Instrument that defines getSettings(). This will also call the Instrument1 and Instrument2 getSettings() methods automatically, depending on which Instrument the tabComponent is.

Ensign Expendable posted:

Write an interface Instrument that defines getSettings() and other stuff Instruments need.

HFX posted:

Using it for the method you describe cries that you should implement an interface that Instrument classes subclass to provide that method. It is considered bad form when you are using it to basically serve as the old dreaded C 200 line if..else if.. statement. Basically, used too liberally it can point to issues with design.

Now that I've said that, it is important to remember that instanceof is the only way to handle certain situations (especially when dealing with code older then Java 5). People who automatically dismiss it as bad, are the same people who think dynamic_cast in C++ is terrible.

iam posted:

Anyone any tips on the easiest/best method for utilising properties files to store system messages?

I want to move all my "Error parsing comms" etc messages to a properties file, so that the system/API can just import com.x.pz.messages and then use the constants held within (that have been populated from the properties file).

Ideally I'd like the properties file to look like:

code:

COMMS_ERROR = "Error parsing comms"
VALIDATION_ERROR = "Error validating packet"

And then just be able to use the property names as the constant names, without having to manually do something like:

code:

final String COMMS_ERROR = properties.getProperty("COMMS_ERROR");

For the dozens of system messages...

Once I've imported com.x.pz.messages I'd like to then just substitute them in as you'd expect:

code:

throw new CommsErrorException(COMMS_ERROR);

Edit: Ignore, should have spent 30 more seconds Googling :P

code:

for(String key : properties.stringPropertyNames()) {
  String value = properties.getProperty(key);
  System.out.println(key + " => " + value);
}

Edit 2: No in fact, the above snippet doesn't answer the question. HALP. I don't know if it's going to be possible unless there's an elegant method to do it, i.e. there's no way you can do final String <key> = properties.getProperty(key); - the compiler will surely just tell you to gently caress off? I suppose one solution would be to populate a HashMap using the properties file, but then that's not as clean when you have to do:

code:

throw new CommsErrorException(hm.get("COMMS_ERROR"));

King Lazer posted:

code:

<applet code=learning.AppletTest.class width=640 height=480></applet>

The html file is in the same directory as AppletTest.class.

baquerd posted:

Move the AppletTest.class file to a directory called learning in the same location as the class file is currently.

wins32767 posted:

Is there a Java equivalent of easy_install and eggs from python? I'd really like to be able to do something like:

code:

easy_install make-config myapp.war
<edit config file>
easy_install setup-app myapp
...
<load jar/war into the servlet container>
<everything works>

wins32767 posted:

Is there a Java equivalent of easy_install and eggs from python? I'd really like to be able to do something like:

code:

easy_install make-config myapp.war
<edit config file>
easy_install setup-app myapp
...
<load jar/war into the servlet container>
<everything works>

tractor fanatic posted:

Why does transfer_wrong1 have a race condition?

code:

class Account { 
    float balance; 
    synchronized void deposit(float amt) { 
        balance += amt;
    }

    synchronized void withdraw(float amt) {
        if(balance < amt)
            throw new OutOfMoneyError();
        balance -= amt;
    }

    void transfer_wrong1(Acct other, float amt) {
        other.withdraw(amt);
        // race condition: wrong sum of balances
        this.deposit(amt);
    }

    synchronized void transfer_wrong2(Acct other, float amt) {
        // can deadlock with parallel reverse-transfer
        other.withdraw(amt);
        this.deposit(amt);
    }
}

tractor fanatic posted:

Why does transfer_wrong1 have a race condition?

tractor fanatic posted:

Why does transfer_wrong1 have a race condition?

fletcher posted:

Instead of checking for someCondition again, you could do a if (myObject != null), and the code would function the same way. Is there a good reason to use one way over the other?

baquerd posted:

code:

x.transfer_wrong1(y, 50)
y.transfer_wrong1(x, 50)

transfer_wrong1(0) withdraws from account y
transfer_wrong1(1) withdraws from account x, OutOfMoneyError thrown
transfer_wrong1(0) deposits into account x

-vs-

transfer_wrong1(0) withdraws from account y
transfer_wrong1(0) deposits into account x
transfer_wrong1(1) withdraws from account y
transfer_wrong1(1) deposits into account y

There's other ways to race this but if the error is thrown that's the cleanest to see.

tractor fanatic posted:

but if you are relying on one happening before the other you shouldn't be using concurrency anyways, right?

I mean this race condition would appear no matter what solution you try since you can't control which transfer comes first.

baquerd posted:

stackoverflow posted:

You only need to use this - and most people only use it - when there's an overlapping local variable with the same name. (Setter methods, for example.)

Of course, another good reason to use this is that it causes intellisense to pop up in IDEs

carry on then posted:

Yeah, the only time I've ever seen it is when a parameter and an instance variable have the same name, or an instance variable and a local variable.

carry on then posted:

Yeah, the only time I've ever seen it is when a parameter and an instance variable have the same name, or an instance variable and a local variable. (edit: I guess a parameter is just a local variable, isn't it?)

code:

public class MyClass {
    int number; //BUTTS

    public MyClass(int number) { //CHEWBACCA
        this.number = number;
    }
}

I'm sure with a bit of work you could always make sure the names are different. What's the consensus on which one is best?

gotly posted:

Just to make sure I have it 100% - in this case, MyClass will actually change BUTTS and leave CHEWBACCA alone?

gotly posted:

Just to make sure I have it 100% - in this case, MyClass will actually change BUTTS and leave CHEWBACCA alone?

Sedro posted:

Naming conventions like _fieldName solve the naming conficts (safer to avoid them entirely).

Sedro posted:

I would like to hear your reasoning against the typed equals method though.

Sedro posted:

I would like to hear your reasoning against the typed equals method though.

Joshua Bloch, Effective Java posted:

It is acceptable to provide such a “strongly typed” equals method in addition to the normal one as long as the two methods return the same result, but there is no compelling reason to do so. It may provide minor performance gains under certain circumstances, but it isn’t worth the added complexity (Item 55).

brosmike posted:

code:

        reallyA.equals(b); // Still true - great!
        b.equals(reallyA); // Nope. poo poo.
        reallyA.equals(reallyA); // Double poo poo

Sedro posted:

I mostly use this (and base, super, etc) when I want to filter autocompletion. Naming conventions like _fieldName solve the naming conficts (safer to avoid them entirely).

Aleksei Vasiliev posted:

those conventions are poo poo and make code look terrible, why people don't just use this and avoid polluting their variables I will never understand