Chick and egg,which comes first?

[Jack Dowson]

Hello Everybody:
I have a problem.There are two classes, in the definations of both of
which there is the employment of another.Then which shoud I compile
first using 'javac'.
Thanks in advance for any reply.

Dowson.

 

[Lasse Reichstein Nielsen]

I have a problem.There are two classes, in the definations of both of
which there is the employment of another.Then which shoud I compile
first using 'javac'.

The blue one!

Seriously, you have told us no information that distinguishes the two,
so even if there was a necessary order, we wouldn't be able to say which
was which.

The real answer is that you should compile both at the same time.

Two classes with such a close relationship should probably be in the
same module, or even package. If they are from widely different places
in your application code, you could consider refactoring and make them
dependent only on interfaces instead of on implementation.

/L

 

[Roedy Green]

I have a problem.There are two classes, in the definations of both of
which there is the employment of another.Then which shoud I compile
first using 'javac'.

see http://mindprod.com/jgloss/javacexe.html#CIRCULAR

 

[Jack Dowson]

Lasse Reichstein Nielsen 写é“:

Seriously, you have told us no information that distinguishes the two,
so even if there was a necessary order, we wouldn't be able to say which
was which.

If there are class A in which main method exists and class B,they are in
the same folder(module).In the defination of class A there is a sentence
"B b = new B();" while in the defination of class B there is "A a = new
A();".

Is the description above enough to distinguish the two class A and B?

Thank you.
Waiting for your reply.

Dowson.

 

[~kurt]

Hello Everybody:
I have a problem.There are two classes, in the definations of both of
which there is the employment of another.Then which shoud I compile
first using 'javac'.
Thanks in advance for any reply.

You can compile either first. You can test this with less than 20 lines
of code total. Sometimes the easiest way to get an answer is to just
do it.

- Kurt

 

[~kurt]

Lasse Reichstein Nielsen ??:

If there are class A in which main method exists and class B,they are in
the same folder(module).In the defination of class A there is a sentence
"B b = new B();" while in the defination of class B there is "A a = new
A();".

This is a little different from what you told us first. The first time around
you said each class employed the other, which I would assume means each class
uses the other. Not an issue.

But, if you are creating (as in, to instantiate) class A, which creates
class B, which creates class A - you run into a loop that won't end.
You can compile the folowing two classes just by typing "javac A.java",
but be ready to hit ^C after you type in "java A":


public class A {
public static void main(String[] args) {
A a = new A();
}
public A()
{
System.out.println("Making A");
B b = new B();
System.out.println("Done with A");
}
}

public class B {
public B() {
System.out.println("Making B");
A a = new A();
System.out.println("Done with B");
}
}

When you run it, notice that you will never get "Done with [AB]".

- Kurt

 

[Andreas Leitgeb]

Lasse Reichstein Nielsen 写é“:
If there are class A in which main method exists and class B,they are in
the same folder(module).In the defination of class A there is a sentence
"B b = new B();" while in the defination of class B there is "A a = new
A();".

In the end, you will need to compile them both in one go.
Actually, javac should even do that on your behalf, automatically.

If the classes are in different packages, they really shouldn't be
mutually dependent.

 

[Jack Dowson]

First of all,thank you!

In the end, you will need to compile them both in one go.
Actually, javac should even do that on your behalf, automatically.

Do you mean using "javac *.class", and neither "javac a.class" nor
"javac b.class" will go through while compiled?

If the classes are in different packages, they really shouldn't be
mutually dependent.

In such case,none of the above will work.Right?

Dowson.

 

[Andreas Leitgeb]

First of all,thank you!
Do you mean using "javac *.class", and neither "javac a.class" nor
"javac b.class" will go through while compiled?

to javac, you pass the .java files, not the .class-files:
javac *.java
javac A.java
javac B.java
javac A.java B.java
javac B.java A.java
Either of these five should do.

In such case,none of the above will work.Right?

I think even in that case it might work, but you really
shouldn't do it, still.

If they are even further separated, say in two separate projects
(on different planets of different solar systems) ... then you
might run into difficulties. ;-)

It's not automatically a sure failure, but if you do it, and
suddenly find a hole in your foot and it hurts, then don't
come to complain that we didn't warn you against targeting
your foot and firing.

 

[Daniel Pitts]

Lasse Reichstein Nielsen ??:

If there are class A in which main method exists and class B,they are in
the same folder(module).In the defination of class A there is a sentence
"B b = new B();" while in the defination of class B there is "A a = new
A();".

This is a little different from what you told us first. The first time around
you said each class employed the other, which I would assume means each class
uses the other. Not an issue.

But, if you are creating (as in, to instantiate) class A, which creates
class B, which creates class A - you run into a loop that won't end.
You can compile the folowing two classes just by typing "javac A.java",
but be ready to hit ^C after you type in "java A":

public class A {
public static void main(String[] args) {
A a = new A();
}
public A()
{
System.out.println("Making A");
B b = new B();
System.out.println("Done with A");
}

}

public class B {
public B() {
System.out.println("Making B");
A a = new A();
System.out.println("Done with B");
}

}

When you run it, notice that you will never get "Done with [AB]".

- Kurt

How about you do it the sensible way:

public class A {
B b;
public void setB(B b) {
this.b = b;
}

public void foo() {
System.out.println("Foo!");
b.bar();
}
}

public class B {
A a;
public void setA(A a) {
this.a = a;
}

public void usesA() {
a.foo();
}

public void bar() {
System.out.println("Bar!");
}
}

public class Framework {
public static void main(String...args) {
A a = new A();
B b = new B();
a.setB(b);
b.setA(a);

b.usesA();
}
}


Its often advantageous to have the instantiation of interrelated
objects done by a coordinator or framework, and have the framework
inform the objects about each other. That way, if I wanted to have b
talk to an "A" subclass, I don't have to modify B . Also, that
alleviates the stress of deciding whether A should create B, or visa
versa. The answer is No, they shouldn't create each other, just deal
with each other.

javac will figure out how to compile them, don't worry about that
much. Generally (as others have noted) you'll want to compile all
the .java files at once. (javac *.java works in simple cases,
depending on package structure).

Hope this helps,
Daniel.

 

[~kurt]

How about you do it the sensible way:

I was illustrating what would happen given the OP's statement that A
created a new B, that created a new A.... Nothing about it was meant
to be sensible.

- Kurt

 

[Andreas Leitgeb]

I was illustrating what would happen given the OP's statement that A
created a new B, that created a new A.... Nothing about it was meant
to be sensible.

Oh and it didn't occur to you, that each class' code to create
instances of the other class does not necessarily reside in
the class' own constructor?

 

[Lew]

Oh and it didn't occur to you, that each class' code to create
instances of the other class does not necessarily reside in
the class' own constructor?

What ~kurt was doing was presenting an anti-example. Picking apart what's
wrong with it is exactly the right thing to do with an anti-example. It is
possible all these issues occurred to him, which is the point of embodying
worst practices in an anti-example.

He warned us.

 

[~kurt]

Oh and it didn't occur to you, that each class' code to create
instances of the other class does not necessarily reside in
the class' own constructor?

The OP said:

'In the defination of class A there is a sentence "B b = new B();" while in
the defination of class B there is "A a = new A();".'

My assumption was that by "definition", he meant in the constructor. I guess
he could have very well meant anywhere in the the declaration of the class.
Personally, I found the entire question confusing because it takes only about
5 minutes to test on your own.

- Kurt

 

[~kurt]

What ~kurt was doing was presenting an anti-example. Picking apart what's
wrong with it is exactly the right thing to do with an anti-example. It is
possible all these issues occurred to him, which is the point of embodying
worst practices in an anti-example.

He warned us.

All I know is when I went to run it, I was ready to hit ^C.... I'm not
familiar with all the fancy terminology like "FrameWork", but I do use
such concepts when I have objects that reference each other.

- Kurt

 

[Andreas Leitgeb]

The OP said:
'In the defination of class A there is a sentence "B b = new B();" while in
the defination of class B there is "A a = new A();".'
My assumption was that by "definition", he meant in the constructor.

Of course it's not the question where that piece of code really resides,
but rather if it was executed in the course of the constructor call in both
classes.

Personally, I found the entire question confusing because it takes only
about 5 minutes to test on your own.

I vaguely remember having had problems of the same sort as the OP seems
to have anticipated. It's a while back, and if I hadn't read other
postings meanwhile, indicating that modern versions of javac handle this
just fine, I'd also have been curious in advance. (Maybe that was in the
old days, when javac still had the explicit -depend and -xdepend options)

 

[Ben Phillips]

It's not automatically a sure failure, but if you do it, and
suddenly find a hole in your foot and it hurts, then don't
come to complain that we didn't warn you against targeting
your foot and firing.

I thought that only happened with C?

 

[Andreas Leitgeb]

I thought that only happened with C?

Oh no... just the method differs: in Java you first create
a new Thread for the foot, and one for the gun, then you
derive BentFinger from Finger, which you attach to your
hand through: Hand.setDefaultIndexFinger(bentFinger).

To make it relevant to this specific thread, you'd also
have to create (bent)fingers from within the toes and toes
from within the fingers...

 

[Lew]

To make it relevant to this specific thread, you'd also
have to create (bent)fingers from within the toes and toes
from within the fingers...

That'd definitely be one application to leave on the hillside for the wolves.