Re: Java compatibility issues (WAS: MF having issues?)

Oliver,

"Object1 == Object2" will just not work in java as you think !!! :-)))
Actually, I suspect it's exactly as I think... but of course, I could
be wrong.

:-))
It was not about your java knowledge.
We were speaking about EVALUATE and in this case "==" will not work the way
we want (to be a Cobol equivalent)
And if we imagine implementation of switch(Object1) ... case Object2: in
Java, than it should be Object1.equals(Object2) and not "=="

String a = "123";
String b = "123";
if (a == b) {
/*You SHOULD reach this point*/
}

It's just implementation.
I'm not sure about optimization requiremens and as I can recall in java 1.1
I saw different results on a different platforms.

Regards,
Sergey

"Oliver Wong" <owong@xxxxxxxxxxxxxx> wrote in message
news:XS2Pf.12046$Cp4.2538@xxxxxxxxxxx

"Sergey Kashyrin" <ska@xxxxxxxxxxx> wrote in message
news:TD2Pf.44$3j.28701@xxxxxxxxxxxxxxxxx
Oliver,

The problem otherwise is whether whether the implementation should
use "Object1.equals(Object2)" or "Object1 == Object2". The former is
probably more useful, but the latter is safer (the first one could throw
exceptions for example).

"Object1 == Object2" will just not work in java as you think !!! :-)))

Actually, I suspect it's exactly as I think... but of course, I could
be wrong.

in java you can't overload operations and "==" is a pointer comparison
and not Object.equals function !
i.e.
String a = "abc"; String b = new String(a);
if(a == b) {
// I'm giving 100% that you'll never reach here....
}

I suspect you are correct, but it's tricker than you are implying. The
compiler will optimize something like this:

String a = "123";
String b = "123";
if (a == b) {
/*You SHOULD reach this point*/
}

because it can detect the same literal being used twice, and only
instantiate a single String object for both the "a" and "b" references. In
fact, I believe (but am not sure), that the JLS (Java Language
Specification) REQUIRES that this optimization be done (i.e. if you write
a compiler which does NOT perform this optimization, then you are not
legally allowed to call it a "Java compiler").

It's just another 2 cents about java stupidity :-)

The == operator and the . operator have two different semantics when
applied to references. The former is to test for reference equality (i.e.
do two references refer to the same object?) while the latter is to
derefenrece members of the object. In the example of
(object1.equals(object2)), the . is being used to perform a method
invocation.

The method being invoked is called "equals", but there's nothing to
prevent the programmer from implementing the equals method from, for
example, printing out the first 20 fibonacci numbers to the standard
console. (This is a problem with programmers writing incorrect code,
rather than a problem with Java itself).

Anyway, the fact that == and .equals does two different things is why I
bring up the fact that *someone* will have to decide which of these two
things will be done "under the hood", and that both choices have their
advantages and disadvantages.

- Oliver


.

Relevant Pages

  • Re: Java compatibility issues (WAS: MF having issues?)
    ... I suspect you are correct, but it's tricker than you are implying. ... because it can detect the same literal being used twice, and only instantiate a single String object for both the "a" and "b" references. ... In fact, I believe, that the JLS (Java Language Specification) REQUIRES that this optimization be done. ... The method being invoked is called "equals", but there's nothing to prevent the programmer from implementing the equals method from, for example, printing out the first 20 fibonacci numbers to the standard console. ...
    (comp.lang.cobol)
  • Re: Calling JVM from a C program
    ... Sun's web site only offers very old and short stuff. ... The whole book online... ... that almost all users of JNI will be wanting to call C from Java ... suspect -- false far more often than the books would lead you to suspect. ...
    (comp.lang.java.programmer)
  • Re: What are first-class objects?
    ... >Classes in Java are not first-class objects. ... but suspect it's similar to Java. ... In Smalltalk, classes are first-class objects. ...
    (comp.object)
  • Re: MF having issues?
    ... I've heard from Java advocates that because it's very common in Java to write a program in which you create and quickly throw away objects, many implementations of Java are heavily optimized for this kind of usage. ... I've read some articles about garbage collection algorithms -- generative garbage collectors do in fact keep track of "how old" objects are, and do some optimizations to be able to quickly recycle younger objects -- so I can confirm that a lot of thought was actually put into the issue. ... I suspect, all other things being equal the COBOL program would be easier to understand, COBOL being much more verbose than Java. ...
    (comp.lang.cobol)
  • Re: Whats special about Lisp, in practice
    ... Pascal Costanza wrote: ... > I don't know about the C++ version, but suspect equally wrong behavior ... > as in the Java version. ... Prev by Date: ...
    (comp.lang.scheme)
Loading