Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Here are my answers to some of your questions:</p> <hr> <p>Question number <strong>2</strong>:</p> <p>I think you're not capitalizing the properties properly. The methods should be called getPBar and setPBar.</p> <pre><code>String pBar; void setPBar(String str) {...} String getPBar() { return pBar}; </code></pre> <p>The JavaBeans specification states that:</p> <blockquote> <p>For readable properties there will be a getter method to read the property value. For writable properties there will be a setter method to allow the property value to be updated. [...] Constructs a PropertyDescriptor for a property that follows the standard Java convention by having getFoo and setFoo accessor methods. Thus if the argument name is "fred", it will assume that the reader method is "getFred" and the writer method is "setFred". Note that the property name should start with a lower case character, which will be capitalized in the method names.</p> </blockquote> <hr> <p>Question number <strong>3</strong>:</p> <p>I agree with the suggestion of the software you're using. For readability, only one exit point is better. For efficiency, using 'return;' might be better. My guess is that the compiler is smart enough to always pick the efficient alternative and I'll bet that the bytecode would be the same in both cases.</p> <p><strong>FURTHER EMPIRICAL INFORMATION</strong></p> <p>I did some tests and found out that the java compiler I'm using (javac 1.5.0_19 on Mac OS X 10.4) is not applying the optimization I expected.</p> <p>I used the following class to test:</p> <pre><code>public abstract class Test{ public int singleReturn(){ int ret = 0; if (cond1()) ret = 1; else if (cond2()) ret = 2; else if (cond3()) ret = 3; return ret; } public int multReturn(){ if (cond1()) return 1; else if (cond2()) return 2; else if (cond3()) return 3; else return 0; } protected abstract boolean cond1(); protected abstract boolean cond2(); protected abstract boolean cond3(); } </code></pre> <p>Then, I analyzed the bytecode and found that for multReturn() there are several 'ireturn' statements, while there is only one for singleReturn(). Moreover, the bytecode of singleReturn() also includes several <em>goto</em> to the return statement.</p> <p>I tested both methods with very simple implementations of cond1, cond2 and cond3. I made sure that the three conditions where equally provable. I found out a consistent difference in time of 3% to 6%, <strong>in favor of multReturn()</strong>. In this case, since the operations are very simple, the impact of the multiple return is quite noticeable.</p> <p>Then I tested both methods using a more complicated implementation of cond1, cond2 and cond3, in order to make the impact of the different return less evident. I was shocked by the result! Now multReturn() is consistently <strong>slower</strong> than singleReturn() (between 2% and 3%). I don't know what is causing this difference because the rest of the code should be equal. </p> <p>I think these unexpected results are caused by the JIT compiler of the JVM.</p> <p>Anyway, I stand by my initial intuition: the compiler (or the JIT) can optimize these kind of things and this frees the developer to focus on writing code that is easily readable and maintainable.</p> <hr> <p>Question number <strong>6</strong>:</p> <p>You could call a class method from your instance method and leave that static method alter the class variable.</p> <p>Then, your code look similar to the following:</p> <pre><code>public static void clearInstance() { instance = null; } @Override public void handleEvent(Event e) { switch (e.type) { case SWT.Dispose: { if (e.widget == getComposite()) { MyClass.clearInstance(); } break; } } } </code></pre> <p>This would cause the warning you described in 5, but there has to be some compromise, and in this case it's just a smell, not an error.</p> <hr> <p>Question number <strong>7</strong>:</p> <p>This is simply a smell of a possible problem. It's not necessarily bad or wrong, and you cannot be sure just by using this tool.</p> <p>If you've got a real problem, like dependencies between constructors, testing should show it. </p> <p>A different, but related, problem are circular dependencies between jars: while classes with circular dependencies can be compiled, circular dependencies between jars cannot be handled in the JVM because of the way class loaders work.</p>
    singulars
    1. This table or related slice is empty.
    1. POSimple, general-interest, code-analyzers based, Java questions
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USnozebacle
    1. USnozebacle
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POSimple, general-interest, code-analyzers based, Java questions
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COWow..that was amazing. It fixed the problem with pBar..and i guess the other warnings are given from the same reason. But..that is how Eclipse suggested the getters and setters should be created and..it's a bit stupid, dont you think? I mean, those methods ARE the get and set method for the object, regardless of their name :-(. +1 for the observation.
      singulars
      1. PO
      1. UShypercube
    2. COIf Eclipse suggests that, shame on them! The Java Beans standard is clear about capitalizing the first letter of the field in the getters and setters. You cannot 'mark' methods as the getters and the setters, you've got to rely on their name, and they were not getX / setX but getpX / setpX.
      singulars
      1. PO
      1. USnozebacle
    3. COThis : public static void setNullInstance() { Dog.instance = null; } inside my Dog class will do the trick,and leaves me with code-smell warning for assigning object to null..which is not good enough. Using private instance method is NOT an option, since the instance might be null. Yes, i could check for that..but..things get complicated..for no reason. There MUST be a better way to do this.
      singulars
      1. PO
      1. UShypercube
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload