Paul Clapham

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.

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.

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.

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.

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.

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.

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.

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.

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.

Is it possible that on your machine, your code and the database were both running on the same machine? Whereas on your VPS, the database is running on a different machine and the query results have to be sent over the network?

Vaibhav Gargs wrote: it will turn out to be a huge performance impact. So, how can we overcome this problem?

Perhaps you could explain more about why you think there will be a "huge performance impact". The first thing for us to know is what you are comparing this technique to. In other words, "Compared to X technique the use of Future.get() produces a performance impact". The second thing for us to know is what you mean by "performance" in that statement. I suspect you're talking about elapsed time but it would help for us to know that before we rush off to produce "solutions".

If you run your class using the "java" command then you get a console to see its output and accept its input. If you use the "javaw" command then you don't. So you'd have to examine which of those two commands is run by the double-click action.