Win a copy of OCP Java SE 8 Programmer II Exam Study Guide this week in the OCP forum!

Vadim Vararu

Ranch Hand
+ Follow
since Jan 03, 2009
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 Vadim Vararu

I've debugged a little bit in the tomcat sources.

The exception is really thrown, but it goes up till it gets here:

As it is described in the javadoc comment, it gets swallowed.
Why? Because at this moment it sets the status of the response as internat server error, but response has already been committed, so this has no effect at all.

When we forward to another component after the response has already been committed, next things happend:
- We get an exception logged into the container's log file.
- We get in the output everything that was flushed before the exception has been thrown.
- We don't get a visible error as response.

P.S. That also means that tomcat implementation deviates a little bit from the specification. Doesn't it?
5 years ago
I've taken a look in the tomcat source code and that's what i see:

Inside the RequestDispatcher implementation class we get here when we forward:

So, if response.isCommitted() is true, than throw the exception.

Let's go farther. How is response.isCommitted() implemented:

That's the implementation from a response facade implementation that delegates the decision to a contained reponse.
Let's see what does it do:

Here we go. If any of those conditions are true, than the exception has to be thrown.
So why it is not thrown, if the flushBuffer method sets the appCommited to true.
5 years ago
The javadoc says:

forward should be called before the response has been committed to the client (before response body output has been flushed). If the response already has been committed, this method throws an IllegalStateException. Uncommitted output in the response buffer is automatically cleared before the forward.

What i don't understand is why having the next excerpt of code:

i don't get an IllegalStateException. I get printed all till "true" from response.isCommited(). After that i was waiting for an exception, but nothing happened.

P.S. I tested it on tomcat 6 container.
5 years ago

and that prints [A,A,V,J]

Where is the logic? It should order it in the natural order A,A,J,V.

Any ideas?
So, till the JAVA SE5 the rule was: when you override a method, the overriding method has to return exactly the same type as the overridden one!
Beginning with JAVA SE5 the rule is: when you override a method, the overriding method has to return any type that is in relation IS-A with the type returned by the overridden method.

So, till JAVA SE5 i could not do this:

Beginning with JAVA SE5 this is legal, because Number and Integer are covariant return types.

So, in your code the class D extends the class C, so if the overridden method returns C, it's quite legal that the overriding method returns D.

Have a good day, Vadim.

Static import is used only and only for static things. You can import static methods or static attributes. With static import you can not import anything else. You can not import instance methods or attributes. That's the rule and you have to memorize it.

With the non static import you can import just concrete Types (for instance: import java.util.List) or all the types from a certain package (for instance: import java.util.*).

There are no other ways to use import. You can not import instance members or methods.

Have a good day, Vadim.
Who knows why this works:

and this does not:

Why we can read a line and the program prints if further if we close the reader?

Mallik Kumar wrote:You have to obtain a lock on an object rather than a thread.

Isn't a thread an object?

John Stark wrote:Hm, for wait() it says 'Causes the current thread to wait until ...'. I guess it is the main thread which is waiting in your code. With the wait() in your code the printout is 999999, so the main thread waits until the Thread 'thread' has finished. If you remove the wait() then the printout is something like '143' on my computer, so execution of the main thread immediately continues after doing thread.start(). Not sure why there is no notify() necessary.


That's the problem. Documentations says that it will wait until any thread owning the block on the "thread" object will notify.

Could you please explain, how it comes that i get printed the actual thread's value in the end, if, normally, the current thread should wait the invocation thread.notify() or thread.notifyAll() and it is not in the code? Thank you!

Stephan van Hulst wrote:No, but that's the easiest way to think about it, especially when you're working with patterns that can match the empty string.

Let me give you a trivial example. Say we want to find all the instances of any character repeated *exactly* zero times. This would be the pattern: ".{0}". Let's say we want to find all the substrings of "0123" that match this pattern. Think about it, where in this input string can we find any character repeated exactly zero times?

Well, there's an empty string before the 0; there's one between 0 and 1; between 1 and 2, and 2 and 3. Finally we can also find an empty string right after 3. If it makes it easier to visualize, think of the input string like this: "" + "0" + "" + "1" + "" + "2" + "" + "3" + "".

Yeap, right you are! Visually it's easier to imagine. As i have understood, it has to be taken as a rule of work with empty character pattern. It would be great to find that in an official documentation. In case, i'll find something, i'll share it. For now, thanks for explanation.

Stephan van Hulst wrote:Because there are seven spots where you can start a sequence of zero or more characters, namely one before every character of the input string, and one after the last character of the string.

Are you sure about "one before every character of the input string"? I would formulate "one spot FOR every character of the input string". Actually, i don't understand why we have to consider the one after the last character of the string.
Do you know where it is described or explained in any documentation?
Hi everybody. Please, help me understand a regex excercise.

Here is an excerpt:

How comes that the output is 0123456 (7 start positions) if we have just 6 chars in the string? Thanks in advance.

Henry Wong wrote:

Vadim Vararu wrote:
I can't get the logic here.

This compiles ok:

and this does not compile ok:

Why it doesn't use the same logic/algorithm for the method parameters. So it shortens and autoboxes it well at the variable declaration and cann't do it at the method invocation. Is here a logic or we just have to take it as a rule?

The first case is defined in section 5.2 of the JLS (assignment conversion). The second case is defined in section 5.3 of the JLS (method invocation conversion). If you look, you will notice that there is a section regarding compile time constants, in section 5.2. The equivalent to this is not present in section 5.3. This is why the first works and the second does not.

It kinda makes sense, for method parameters, the compiler must actually pass a parameter. It is not possible for a method parameter to be a compile time constant.


Actually, it's a little bit wrong. There is no problem to invoke methods passing them literals (compile time constants). The problems is that we cant pass a numeral literal (because they all are integers) as a argument to a method that requires a smaller Wrapper (Short, Byte). That's because compiler will autobox any integer literal to Integer (which is not a variant for an Short or Byte parameter).