Scotty Mitchell

O. Ziggy wrote:I actually got this wrong because i thought compilation would fail because of the command line.

java Regex "\d*" ab34ef

i thought that the \d would have required an additional escape character. i.e. it should have been \\d

I think that would only be true if you tried to create the pattern within whatever editor you are using...though I didnt go test that. I'm assuming the OCPJP test people would not be as harsh to throw in a compiler error question based on syntax like that. Especially, since for regex stuff you only need to know the basics, but who knows. I haven't taken the exam yet...A WEEK or SO TO GO!!! ahh

Anjali Vaidya wrote:why doesn't it print "Super" then?
Can anybody please write the line number it goes to step by step?

The getI method isnt like a constructor that makes calls to its super class before returning the subclass.

thanks for that link tommy...I can never find these topics lol

The object reffered to by the reference variable "two" was created using the new keyword. As it is not refered to from the constant pool, what provides its immutability?

I dont think I'm understanding the question you are asking...I do know that the reference to the string pool doesnt matter for immutability directly because if it did then there would be a problem with the wrapper class Integer immutability as there is no integer constant pool.

As far as my knowledge of immutable is concerned it just means if the reference variable two is pointing to "someString" then you can't change the value of "someString" without rerefencing the variable two to point to it. When I say change the value I kind of mean that loosely, as in you really cant get to it. It's not that a new object hasnt been created.

I.e If you have
String two = new String("someString"); two.concat("blah"); System.out.println(two); // The Output is -> someString

Of course you can change the reference. Like if you wanted two to point to "someOtherString" in that case the "someString" object would be as they say "lost" because nothing else references it.

And btw Strings are Immutable regardless of how they are created. Only StringBuilder and StringBuffer are mutable string objects.

I actually thought that since one of the elements in the expression is a string, the + operator will be used for concatenating.

The + operator is an overloaded operator and its use depends on the arguments...for example if you come across System.out.println(1 + 2 + "string") the output would be "3string". This is because the arguments the operator recieves first are primitive ints (precedence is factored in here). However, if you had System.out.println("string" + 1 + 2) you would get "string12" because the + operator sees a string object and an int.

I think the way you have your code now looks like System.out.println((" 2: ".concat(s1)) == s2) // -> false (boolean) if you were to use the concat operator instead of +. Maybe, what you were intending to do is print System.out.println((" 2: ".concat((s1 == s2)+""))); // -> "2: true" (string).

Stephan van Hulst wrote:I very rarely use inheritance myself, but was it a mistake to add it to the language, because so many new programmers misuse it?

I'd have to agree with this...I mean I've only been out in the real world for a couple months, and I've never really used inheritance at all. Mostly composition...

The + operator has higher precendence than the ==. Effectively, the concatenation is occuring before the == hence they are not pointing to the same references. You are creating a new string object "2: hello" and seeing its its equal to the reference "hello", obviously this is false. If you were to put parenthesis around (s1==s2) you would get true I'm pretty sure?

You should know this you read the precedence post from the other day this is why you need to know precedences.

And also, since s1 == s4 is false, does not mean that strings created using the new keywork are not placed in the pool?

If you use any constructor of string, the object will be created in the heap, and not find a reference in the string literal pool I'm pretty sure.

The string objects h1 = h1.concat("world"), and h2 = h2.concat("world") are not pulled from the literal pool as they create new string objects. Thats why you have an output as false. Of course, all these string objects are on the heap, just the reference to the literal pool is not there.

nice man! how long did you study for just out of curiousity? I'm on week 2 myself, but I only ask because you seemed to know what you were talking about in some of our forum discussions and wanted to gauge my test taking around how long you took hah

Sudhanshu Mishra wrote:Hi all,
Please have a look at my question.
I need to understand it urgently.
Eagerly waiting for the answer....

Well, I had some issues with compiling programs at work that required imports of a jar file so I'm assuming its along this reasoning...some classes within the jar file are needed for compilation if used within the class file you are trying to compile. Say for instance you are trying to use a database such as db4o and you are trying to create an instance for a DAO. You will need to import something...I believe the jar would be needed to get this important information. If you dont add those jars you would get some sort of Symbol Not Found during compilation, and you wouldnt be able to build.

This could be wrong...but thats my guess

Arn't closures being supported or something along those lines so we can have anonymous functions work like in other languages that use currying and such? I thought I read that somewhere

What I meant to say or was trying to imply is what does writeObject do to the class code to allow for deserializing later by an ObjectInputStream. And yes you are right "a" should be a reference to a ObjectOutputStream object. Sorry for the confusion.

What do you mean by reflective code?

Good idea to look at the source code...a lot is going on behind the scenes that you never really know about until you look at the source code.

thanks~

The code from the K&B book is as follows:

import java.io.* class Vechicle {} class Wheels {} class Car extends Vechicle implements Serializable {} class Ford extends Car {} class Dodge extends Car { Wheels w = new Wheels(); }

The question asked is: Instances of which class(es) can be serialized? (Choose all that apply.)
A. Car
B. Ford
C. Dodge
D. Wheels
E. Vehicle

Answer Given: A and B are correct. Dodge instances cannot be serialized because they "have" an instance of Wheels, which is not serializable.

My question finally...

I agree with the answer and explanation given. Hypothetically speaking, if we were to add a transient keyword into the mix at line 7: ie.
transient Wheels w = new Wheels();

Then Dodge would be serializble?

Also what if Wheels for some reason was a subclass of Car then everything would also be fine?

Darryl Burke wrote:

Catherine austin wrote:Since final object ...

Hold it right there. Objects aren't ever final. Variables can be.

The english isn't very understandable in her post, but I believe she was referring to reference variables of objects based on the code she showed.

Question about what you said though...wouldnt declaring say an immutable "object" to be final be an example contridicting what you just said? This would be the only case of course as all other uses of the keyword final pertain to methods, classes, fields, and variables.

Matthew Brown wrote:You're probably right - I misunderstood the question.

In which case, the answer is "because Integers are immutable".

ahhhh YES! Thank you thank you