Guy Reynolds

Ranch Hand
+ Follow
since Oct 27, 2000
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Guy Reynolds

I just got into a big discussion about this very same thing...
protected-
allows inheritance regardless of package. Which means subclasses get a copy of the feature(method or variable) that they can access. It does not mean that a subclass object has access to a superclass object's features. The static features of the superclass are accessable to the subclass, however.
Also, classes in the same package have free reign. Any object in a package can access the protected features of any other object in the same package.
At least that's what I've gained from the whole ordeal...
[This message has been edited by Guy Reynolds (edited August 17, 2001).]
If you want the superclass's finalize to run then you have to call the superclass's finalize... finalize is not "chain called" like default constructors.
A try has to have either an associated catch OR finally; or it can have both.
The presence of an exception is a bit of a different subject. The compiler will always complain if a checked exception is generated and not caught or thrown, regardless of the try/catch/finally blocks.
You could have:
<code>
void exMethod() throws java.io.IOException
{
try
{
throw new java.io.IOException();
}
finally
{
System.out.println("finally");
}
}
</code>
and it would be up to the caller of exMethod to either catch or throw the exception.
Or you could have:
<code>
void exMethod()
{
try
{
System.out.println("try");
}
finally
{
System.out.println("finally");
}
}
</code>
But you can't have only a try.

[This message has been edited by Guy Reynolds (edited August 17, 2001).]
I guess that is easier.
It is easy to test, but #2 is the correct answer...
try:
String ref = null;
if( ref instanceof Object )
System.out.println(true);
else
System.out.println(false);
nullref instanceof anything will always be false...
even nullref instance of nullRefType
String ref = null;
if( ref instanceof String )
System.out.println(true);
else
System.out.println(false);
}
also prints out false...
The tricky part of your question, however, is should
String ref = null;
be considered a "reference"?


[This message has been edited by Guy Reynolds (edited August 17, 2001).]
Correct, so in rajashree's example there is 1 object in the pool and 2 on the heap... 3.
And in mine there is one in the pool and 1 on the heap... 2.
Nope. It doesn't convert the byte to an int...
Yep 3.
"new" creates a seperate object.
If you had:
String str="java";
String str1= "java";
String str2=new String("java");
then str and str1 would reference the same object and you would only have 2 String objects.

[This message has been edited by Guy Reynolds (edited August 17, 2001).]
The only way I know of is to pass the inner class a reference to the outer class like:
<code>
class OuterClass
{
class InnerClass
{
void method()
{
System.out.println( outer.memberVariable );
}

String memberVariable = "Inner";

public InnerClass( OuterClass outer )
{
this.outer = outer;
}

private OuterClass outer;
}

String memberVariable = "Outer";
public static void main( String[] args )
{
OuterClass outer = new OuterClass();
outer.new InnerClass( outer ).method();

}
}
</code>
This will print out "Outer".

You can't convert a char to a short. However, Java relaxes the rules in the case of literals like 'i'. In this case the compiler allows the short type to refer to the value of the literal character, as long as the short is capable of containing the value of the character.
see the other post with the same topic
22 years ago
Java strives to be "compile once". Which means it has to have a way of having a common environment or "machine" for it's compiled code to run on. The JVM is this "machine" and since it doesn't really exist, but is the result of a program running on the "real" machine, it is virtual. Hence the title Virtual Machine... for Java: JVM.
22 years ago
"Integral" basically means the values that can be represented are whole numbers...(no fractions). So there are five different types whose any one value is at the least 1 different from any other value of that type: char, byte, short, int, and long.
Now, that does not mean that Java uses them all to represent numbers. This is where the confustion between integer and integral comes in. All five are Integral, but Java only uses four of them to represent numbers: byte, short, int, and long. Numbers that are Integral are called "integers". All the integral numbers (integers) in Java are signed, they can represent both positive and negative values.
The byte type is an integral type, but since it is used to refer to Unicode, not a number, it doesn't seem proper to call it an integer. The integral, non-number type "byte" is unsigned, it can only represent positive values.

[This message has been edited by Guy Reynolds (edited August 17, 2001).]
There are five INTEGRAL data types in Java. Four are signed and are used to represent numbers and one is unsigned and used to represent Unicode, but you can still perform mathmatical operations on it (well kind of, actually, more correctly, it can be converted to an int, which can have mathmatical operations performed on it):
byte - signed
short - signed
int - signed
long - signed
char - unsigned

[This message has been edited by Guy Reynolds (edited August 17, 2001).]