This week's book giveaway is in the Artificial Intelligence forum.
We're giving away four copies of Pragmatic AI and have Noah Gift on-line!
See this thread for details.
Win a copy of Pragmatic AI this week in the Artificial Intelligence forum!

Paul Clapham

+ Follow
since Oct 14, 2005
Paul likes ...
Eclipse IDE Firefox Browser MySQL Database
Forum Moderator
Paul Clapham currently moderates these forums:
Vancouver, Canada
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 Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Paul Clapham

Allen Fields wrote:my problem lies in the amount of decimal places my program puts out

No, it doesn't. The example there clearly shows you should output those numbers with one decimal place only; there's nothing else to suggest otherwise. If somebody is downgrading you because you aren't using some other number of decimal places then you should complain, because nothing in what you posted specifies a number of decimal places to use.
17 hours ago
Do you only have examples to guide your programming decisions, or do you have actual specifications of how the output should appear?

If you have specifications, it might help to tell us what they are.
19 hours ago
First you should remind yourself of what "thread-safe" means. Next, for each method consider what has to be done to make it thread-safe. For methods which use the internal state of your ArrayList class, consider how the state could be affected by other threads while the method is using the internal state.

Jan de Boer wrote:(*) Should I use 'that' or 'who' here by the way?

Yesterday Microsoft Word wanted me to use 'which' rather than 'who' when referring to a person. Definitely don't use 'which' in that context no matter where on Earth you are.
2 days ago
To put it another way:

When a class is loaded, the static initializers are called before anything else, as you already know. So if a class's static initializer throws an unchecked exception, then the attempt to load that class has failed. That means that you can't subsequently call static methods of that class, and you can't create instances of it. Basically the class is useless after that happens. You would probably want to log the error and terminate the application, but I suppose the SO comments about being able to unload the class in some circumstances might be relevant. However that presupposes that you can subsequently reload the class without the same unchecked exception being thrown, which means that your code would have had to catch the first unchecked exception and fix the problem which caused it to be thrown.

I suppose that situation might exist in some design somewhere, but in my opinion it would be better for that "catch the unchecked exception and fix the problem" code to be part of the static initializer, thus making it unnecessary for the static initializer to throw an (unchecked) exception unless the problem is really unfixable. So then unloading and reloading the class would be unnecessary.

Anyway I'd have to say that describing the process of having a static initializer throw an unchecked exception as "a bad idea" is unhelpful -- unless a better idea is proposed. That didn't happen in the SO thread. So I'd reject that and say that if you can't load the class because a static initializer fails, then throwing an unchecked exception is your best option. Yes, that probably means your whole application is going down, unless it can continue without the failed class, but chances are there's nothing else you can do.

Of course it's also possible that the class which can't be loaded isn't a critical part of your application. Maybe it can continue, with that class's features disabled. In that case throwing the unchecked exception would be a perfectly reasonable design.
3 days ago
I'm not even familiar with the word "fuddle" myself. To me it only brings to mind the phrase "fuddle duddle", which... well, you can read about it here: Fuddle duddle.
3 days ago

Campbell Ritchie wrote:[Weit can mean far, which the English word wide usually doesn't.

I suppose that the expression "from far and wide" (which appears in my country's national anthem) dates from the time when the meanings of the two words diverged.
3 days ago

Tim Moores wrote:I really don't understand why people think that Java won't be free any more. I thought Oracle's document was pretty clear on that, and on the difference between Oracle's JDK and OpenJDK.

Well, as the Java Is Still Free document mentions, there are factually-incorrect documents on the web which say otherwise. If you happened to read one of them there's a good chance you wouldn't consider fact-checking it, so that's where those people are coming from.
3 days ago

Paul Clapham wrote:... from the ServletContextEvent object passed to the contextInitialized method you can get a ServletContext; to add an object to application scope you can call its setAttribute(name, object) method.

2 weeks ago

Vaibhav Gargs wrote:Can we have something like once T2 is done its processing it informs T1 that it has done the processing even though T1 can continue its normal execution?

Of course you could do that. But I'm not sure why that would be useful. Is it the case that at some point T1 is going to need the data from T2? In that case T1 should do everything which doesn't depend on T2 and then get the data from T2. It may have to wait, but that's not a problem because it can't do anything else anyway. Or if T1 doesn't ever need the data from T2, then there's no point in informing T1 that T2 is complete. Or at least you haven't described a situation where T1 only needs to know that T2 is complete but doesn't need its data.
Execute code on webapp startup and shutdown using ServletContextListener

To that I would add: from the ServletContextEvent object passed to the contextInitialized method you can get a ServletContext; to add an object to application scope you can call its setAttribute(name, object) method. Elsewhere in your app you can easily get a ServletContext and call getAttribute(name) to retrieve that object, or in JSTL it's very easy to access objects in application scope.
2 weeks ago
Wasn't me insisting.

Vaibhav Gargs wrote:I found that CompletableFuture was added in JDK8 but we are using JDK6. So, what would be the solution in lower versions?

So you're going to have an ExecutorService whose job is to run a collection of threads which each do long-running computations? In this case what you do is to start all of the long-running computations running, then wait for them all to finish. Using Future.get() would be a good way to do that waiting.

Now you might think that it's important to get the results of those long-running computations in some special order, so that you can minimize the elapsed time. But if you think about it for a while you'll realize that the order in which you wait for those results doesn't matter. No matter which order you choose, the total elapsed time is going to be the elapsed time of the longest-running computation.
It seems to me that if those lists belong to the application, and aren't specific to any particular user, then you should be putting them in application scope rather than in session scope. That way you'd only have to create them once, when the application starts, instead of having to create them every time a new session is created. Likewise there'd be only one copy of the lists instead of having a copy for each active session.

Note: this assumes that the contents of the lists don't ever change. If they do, then you need to have a way for the application to reload the lists when such a change happens. This can be done, of course, but it's something that needs to be included in your application's design.
2 weeks ago

Sam Ritter wrote:What ModalityType is the equivalent of setModal(true)?

I don't know, I've never seen that before. I've always just created modal dialogs like Norm did, in fact I don't think I've ever needed a non-modal dialog.

Anyway the docs for setModalityType say

The API documentation wrote:Note: changing modality of the visible dialog may have no effect until it is hidden and then shown again.

Perhaps that's an issue in your case -- if you still care.
2 weeks ago