Matthew Walton

Greenhorn
+ Follow
since Dec 18, 2007
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 Matthew Walton

At a guess I'd say it's because you're not necessarily reading text. Generic file reading methods need to be able to cope elegantly with binary data as well. They can't use byte, because it doesn't have any values they could use to indicate read failure short of throwing an exception (not a good way to cope with end-of-file conditions which are not at all exceptional). That leaves int as a candidate with sufficiently wide coverage. The part of my brain which deals with more exotic languages suggests what you really want is a byte value which evaluates to false in boolean context if there's a read error, but you can't do that in Java, so you're left with either int or using byte and throwing an exception when you hit the end of the file. Ow. You also can't do an overload with int and one with char, because the parameter lists aren't distinct and Java can't resolve overloads solely based on return type (and neither can virtually every other language going).

If you're casting every single byte you read to a char, perhaps you should be looking at some of the other file reading methods available - perhaps BufferedReader.readLine() - which returns a String.
13 years ago
Write some non-trivial Java programs and you'll soon start to see what it's for.
I'm surprised final isn't illegal on static methods, since it doesn't actually mean anything.
Well if you're taking SCJP6 there's some things on that exam which aren't in K&B (not very many), but I've not found anything missing for SCJP5.

Bear in mind that it is an exam-passing book though - there's virtually nothing in there on actual software design and development, because they're not in the SCJP.

Originally posted by nhlanhla mazibuko:
Hi, there

Why do you we have to use the reference variables to access there static variable.



If you mean what I think you mean, you don't, and in fact you shouldn't.
Such behaviour is officially called 'hiding', where the static method in the subclass hides the one in the base class.

Very simply, static methods are not dispatched on the runtime type of the object pointed to by a reference, but on the compile-time type of the reference being used to call, so polymorphism doesn't work as it does with instance methods.

This is also reflected by the Java compiler issuing warnings when calling statics through instances. Really you should call them through the class name.
It's so that you can provide a base concept which isn't itself complete enough to be sensible instantiatable, but which does have some useful implementation to contribute. Purely abstract concepts with no implementation are best represented using interfaces, but if you can provide a partial implementation that makes sense for all or most of the anticipated subclasses (you can always override it, after all), an abstract base class may be the way to go.

Originally posted by Sandeep Bhandari:
I would like to say that, its the method calls which determine the ambiguity of overloaded methods.

e.g.
void foo(long l,float t) {}
void foo(int t,float f) {}

foo(2.0,2.4f);

makes the compiler to flash error.



Yes, because 2.0 is a double constant, and the compiler doesn't have a preference whether it should convert to long or to int, so it can't make a choice between the two.

I believe if you replace the 2.0 in the foo call with 2, it'll be an int constant and will thus call the int, float overload.
The Java runtime takes care of the copying, I believe at the time the method of the inner class is invoked.
Any Collection which has an internal implementation using hashes will need a decent implementation of hashCode() to be efficient. Fortunately most of them have 'Hash' in their classnames - HashMap, Hashtable, HashSet, LinkedHashSet etc.

There's not a huge amount of application for it outside the realm of storing objects inside hashing data structures though.
13 years ago
Veena, Freddy's regular expression is fairly simple as these things go, so I'll have a go at explaining it for you.

".*=\"(.*)\""

which of course without the Java string escaping is

.*="(.*)"

which makes it a bit clearer. We know that ., *, ( and ) are all metacharacters in regular expressions. The =, " and " will all match literally.

So, starting at the beginning:

. means 'match any character'. Followed by a *, it becomes 'match zero or more of anything', as many times as possible.

Then the = means match the character '='.

After this we have a literal '"' to match.

( opens a capturing group, which contains again .* to match zero or more of any character. ) closes the group.

Finally, another '"' matches the quotation mark at the end of the string.

If you wrote the regular expression out in English you might get this:

Match zero or more characters as many times as possible, followed by an equals sign and a double quote, then match zero or more characters as many times as possible, remembering them in a capture group, followed by a double quote.

The 'as many times as possible' is important because * is a 'greedy' modifier and will grab the longest string which still allows the rest of the regular expression to match. For example, this would match:

s.name=s.name="Something"

and so would

s.name=s.name="Something"Something"

In the latter case, the captured group (the .* in parens) would be 'Something"Something', and the first .* would have matched 's.name=s.name'.

I hope that's helpful. Regular expressions are something you just have to learn, and the best way to do that is by writing them. I did it by doing a lot of coding in Perl, where you tend to use regular expressions with great regularity, but there's no point learning Perl just to learn regular expressions
13 years ago
Actually I don't think it's a very good book. Its main redeeming feature is that it rather brutally covers what you need for the exam and very little else - where it does diverge one is tempted to wonder why what they're diverging into isn't on the exam, since it's usually something fairly critical. It also has a CD with a mock exam (which is harder than the real exam due to not telling you how many options you need to choose for each question), which is undoubtedly useful.

Unfortunately it also seems unsure of its target audience, and there are places where it talks at length of the sort of thing any programmer should know (like deadlocks), but other places where it assumes you already know a fair bit and just want to get the details on how Java does things. There are also a few rather dubious descriptions (no, StringBuffer.delete does NOT take a zero-indexed and then a one-indexed parameter - the second one is zero-indexed and means 'up to but not including this character'. A hairsplitting distinction perhaps, but one that's much less confusing).

Also unfortunately I can't recommend a better one, but I would recommend reading quite widely on various Java topics, especially anything you find difficult. Somewhere out there is probably an explanation which makes more sense to you. It's certainly been helping me in my preparations.