Help coderanch get a
new server
by contributing to the fundraiser

Rob Acraman

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

Recent posts by Rob Acraman

In GameHelper line 41, you're missing an ampersand. I haven't tested it, but maybe that's sending it into an infinite loop.
14 years ago
How about this for an algorithm? It's impossible to get away from brute force, but the big thing is to trim the tree of possibilities as early as possible:

By calculating the count at the start, you automatically avoid dead ends as soon as they occur (the brute-force method tends to only throw its hands up at the end - ie. if it puts the cross-pentomino is a corner, it'll still try every combination thereafter!), and automatically zero in on the limiting factors

[ June 20, 2006: Message edited by: Rob Acraman ]
[ June 20, 2006: Message edited by: Rob Acraman ]
18 years ago
You could have a dozen billion:

18 years ago
Hi Jayashree,

If you want want to compare the values of two Strings, then you have to use "str1.equals(str2)", not "==".

"==" actually compares whether the two variables are pointing to the same object.

In your first example, the compiler picks up that "Ja" and "va" are constants, and that therefore "Ja" + "va" is also constant. It therefore replaces "Ja" + "va" with a reference to "Java" in a constant-string pool - which happily happens to be the same object used to initialise str1.

In the second example, you have two separate String objects. In this case, the compiler cannot make the same constant assumptions, so the evaluation is left until runtime. This means a temporary result object will be created, which cannot be at the same address as the constant "Java" string.

You probably wanted str3.equals(str1+str2).
18 years ago
Hi Gavi,

Depends on what you mean by "Correct" :
- If you mean, does it work?, then presumably you've tested it and it's doing what you want.
- If you mean is this the best way of laying out the code, then I think the fact that your gut feeling has led you to post here is its own answer

You have one statement doing three things :
- Casting this.ejbSession
- Calling a function
- Doing a return

Generally, you want each statement to do just one thing, so this statement should be split.

First off, why do you need the cast? What type is "this.ejbSession", and could it instead be declared as AgendaServiceEJB? If not, you could always declare a local variable.

So, how about something like :

One last point: You say "you need to create an object". Not true - the code above does not create any more objects than your original. All you've created is a local REFERENCE to the agenda.
18 years ago
I just looked at Thinking In Java, Chapter 7

All method binding in Java uses late binding unless the method is static or final (private methods are implicitly final). This means that ordinarily you don�t need to make any decisions about whether late binding will occur�it happens automatically. Feedback

Why would you declare a method final? As noted in the last chapter, it prevents anyone from overriding that method. Perhaps more important, it effectively �turns off� dynamic binding, or rather it tells the compiler that dynamic binding isn�t necessary. This allows the compiler to generate slightly more efficient code for final method calls. However, in most cases it won�t make any overall performance difference in your program, so it�s best to only use final as a design decision, and not as an attempt to improve performance. Feedback
18 years ago
Sorry Stefan, I'm with Amar.

You are right that issue 1 (determining the signature of a method to call) has to be performed by the compiler, but that's not early binding.

Early binding means the compiler effectively hard-codes in the .class file which implementation of that signature is going to be called. As Amar says, that is only possible with static/final/private methods, since these methods cannot be overridden.

So, coming to Issue 2 (which implementation to call): if the method is static/final/private, then early binding is used, otherwise late binding.

To go back to Amar's original question, early/late binding has NOTHING to do with overloading, for the simple reason that overloaded methods have nothing to do with eachother.
18 years ago
p is a reference to a Person object
p.getCar() is a reference to a Car object
p.getCar().getName() is a reference to a String object

In theory, so long as each method returns a reference to an object, you can string any number of "."s together.

In practice, it would be bad coding to put too many - certainly not more than what you've got here. For example, the following clearly does the same :

However, the advantage with splitting the code like this is it enables debugging and maintenance. You can log the value of myCar to ensure it's what you expected it to be, etc.
18 years ago
Thanks Norm,
Now, why didn't I think of that ?!

Results show that it's cloned.
18 years ago
Hi All,

Just a question I've been pondering ....

If I have a big ArrayList, and call toArray() on it, will it simply return me a reference to a pre-existing private array, or will it construct a whole new array object?

18 years ago
No, there's no way round it. It is a very deliberate feature that has been designed specifically to stop your applet accessing anything on your computer No, I'm not kidding - You'll find every browser will behave exactly the same.
The common term for this is the java "sandbox", the term coming from the children's playarea where they can do what they like without destroying anything outside.
The reason for this behaviour is because Applets are most often used over the internet. How would you feel if you visited and ran one of their applets, only to find that the pesky thing had read the files on YOUR hard-disk, and sent all your personal details back without your knowledge??
Clearly, that's unacceptable, and if that COULD be possible, then Java would have died a death VERY quickly. So, as I say, a great deal of effort has gone into ensuring that Java Applets have ABSOLUTELY NO ACCESS **WHATSOEVER** to the computer they're running on.
Since doubtless every hacker would have been trying to break this, and that NO reports of such breaking have ever been received, you can be sure the sandbox is very secure indeed.
What an applet CAN do is communicate back to its host (ie. the machine it was loaded from), and access its resources.
22 years ago
You may notice a loss of precision going from int-to-float when you're dealing with large numbers. With small numbers (certainly upto 1-million - probably MUCH beyond that as well, but you get my drift) the numbers should match well.
Why is this? Well, if you're really techie, read on - but beware! I'm writing this turned midnight with no reference books to hand
Consider this: Both int and float are 32 bits. Now, 32 bits can take on 2**32 distinct "values" (that is, 2-raised-to-32nd power - ie. 2 times 2 times 2 ..... 32 times). Therefore, both int and float can only have this number of distinct values as well.
The int type holds these as precise integers upto (plus-or-minus) 2**16.
The float type holds a fantastically wider range of numbers: offhand, let's say from 10**-99 through to 10**99 (positive and negative).
You can't get something for nothing. The float type has a wider range of values, but remember that it can still only hold 2**32 distinct values. That means, if there is a "good" match with integers around zero, there has to be a "worse" match with integers far from zero - ie. BIG numbers.
22 years ago
That's right, but perhaps a better way of saying it is :
Despite creating a second method, the OneClass variable can still only "see" the OneClass attributes the object being referenced.
The point here is that other classes can extend from OneClass, and not all of those will have getNumber(int i). The only things we KNOW that every subclass will have is what is declared in OneClass, so that is all that we're allowed to call.
22 years ago
Interesting comments about the maturity of the technology. Is there a list somewhere of what major companies are currently using this technology on live systems? (esp financial systems, since I'm working in an investment bank at present that's looking/thinking about Java).
Interesting project. I'm no great expert, but I'll throw my 2-cents in for what it's worth
Offhand, I reckon you wouldn't be able to use Unix security.
Picture this: Your users are on their PCs hitting your intranet through their web-browsers. What's happening at the server end? Answer: the client's requests are being handled by your web-server.
And that's the problem. Your WebServer is a single process, with its own user-id and protection. Unix security never sees the "remote" user-id, and it doesn't have the faintest idea which user the web-server is servicing at the moment.
In fact, of course, the WebServer could very well be servicing a user that doesn't even have a logon id on the unix box (just like you don't have a logon id at the machine that's hosting JavaRanch).
The closest you can get to it is that you can get the WebServer to prompt for a login against one of its own user-ids, and that enables users to access various directories protect by the ".htaccess" files. Of course, ".htaccess" is a filename coded into the WebServers, not Unix.
22 years ago