Paul Clapham

And it looks like you want to create more than one row in your table, based on what I see in your JSON data. But your code only creates one.

Fortunately you just asked the same question about your Java code creating only one object instead of a list of different objects. The answer to that question is the answer to this question too.

So, for example, "each.id" in line 13 is undefined. Using your JavaScript debugger should show you why that is in no time at all. It looks like you're making some incorrect assumptions about what's in that "table_values" variable or maybe whatever calls that function isn't passing the right thing, but like I say the debugger should help you track down that sort of thing.

Robert Houston wrote:The prof said that AWT and SWING were mere choices, not that one replaced the other.

Well, that's just plain untrue.

You misspelled "delimiter".

Sam Peterson wrote:Since when can you pass parameters into a constructor without declaring them as instance variables first?

Let's just clarify what you're talking about there. The constructor has three declared parameters, named "length", "width", and "height". And values are passed into that constructor by some other code which isn't shown in your example. That might look like this:

MouseHouse residence = new MouseHouse(20, 11, 9);

This passes the values 20, 11, and 9 into the constructor, and none of those values are declared as instance variables.

But clearly that isn't what you meant. My best guess is that you mean that the declared parameters of the constructor are supposed to match instance variables of the class. Like this:

private int length; private int width; private int height; public MouseHouse(int length, int width, int height) {  this.length = length;  this.width = width;  this.height = height; }

It looks like the first constructors you saw were written like this, to assign values to instance variables of the class. This is certainly a common use of constructors. However it also looks like you've decided that there is a rule that all constructors must look like that. But there's no such rule, as you can see from the example.

Let us know if you need more help when you get farther along, then. We're always here for that.

Sam Peterson wrote:The initialization wasn't invoked until line 18.

Not so. Your class is named InitializationOrder and so the class is loaded before its static main(String...) method can be run. And as part of loading the class, its static initializers are run before anything else happens. The block including line 11 is a static initializer.

What happens at line 18 is that an instance of the class InitializationOrder is created (via a constructor). At that point the constructor and the instance initializers are run, in some order which this example is supposed to be teaching you.

Well... loading a class is one thing. And creating an instance of that class is another thing. But from the way your post is written it seems that you don't understand the difference between a class and an object. (Hint: You don't "execute" a class. For that matter you don't execute an object either.) If that's the case then it's going to be very hard for you to achieve what you want to do.

But perhaps it's just the terminology which you aren't using properly. It might help if you went back to review what you've learned so far about classes and objects.

Anyway I'm in agreeance with Carey, real class names would be much easier to talk about, and a description of what you want to do would help too. And that could help us clear up your misunderstandings.

Joe Ess pointed you to the classic article about how to deal with Runtime.exec(), which is still a must-read. However since then the ProcessBuilder class has been added to Java, and it simplifies a lot of the annoying details that have to be dealt with. In particular you're going to have to read the process's output stream and its error stream so you can know about what's happening in the process. It's possible to send commands to the process via its input stream, but I'm sure there are still annoying details which have to be dealt with.

As you said in your original post:

But I don't know how I can bring methods from different classes to be used on the same object?

So it looks like you want to have a single object behind which there are different classes doing the same work. Also in your original post was "OldStyleClient" which appeared to be the same sort of thing. That's a facade in my opinion.

Or as you just said:

being able to use a rich set of methods without all methods defined in the same class, or without skipping between objects in the automation script

You want only one object, but you want to use methods from different classes. The "one object" is a facade, behind which are those different classes. I don't see why a facade shouldn't support a "rich" set of methods; it's true that examples of the Facade pattern aren't like that, but then they are just examples.

Robert Houston wrote:How about the reverse? Can ClassM reach ClassU's getter/setters, if can that be done; if so, how?

Of course. ClassM is a subclass of ClassU, so all the methods of ClassU are automatically methods of ClassM.

So yeah, you can access them from ClassM -- unless you declared them private. But you didn't do that, right? They are getters and setters so it wouldn't make sense for them to be private.

So far you're mostly talking about programming, but what you describe is (I think) a design pattern called Facade. Follow that link to the Wikipedia article and maybe it will clarify your thoughts a bit. There's a Java example there too.

And welcome to the Ranch!

Mort Bundersnatch wrote:In "... class ClassM extends ClassU...", where ClassM is the Main (lead-off) class, I found thru the debugger that ClassU executes first. ClassU may need to get info from ClassM via a Getter/Setter mechanism, but I don't know how to do this.

That's because you shouldn't do it. A class should never depend on its subclasses and ideally it shouldn't even know that they exist. If you find yourself breaking that rule then your design has problems. Would you like to post the details for discussion?

PS in Java class these types of issues were never discussed, and I didn't know enough to ask

Yeah, Java is supposed to be an object-oriented language but you'd never know it based on some Java courses.

Fernando Guerrero wrote:I want to run the up and op threads in parallel to save time. Once they are done they continue with the rest of the process.

No, you don't. That doesn't save any time.

The way you have the code written now (wait for op then wait for up), the rest of the process won't continue until both op and up are finished. You can't continue any earlier than that anyway.