Vadim Vararu

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

The exception is really thrown, but it goes up till it gets here:
/** * Handle the specified ServletException encountered while processing * the specified Request to produce the specified Response. Any * exceptions that occur during generation of the exception report are * logged and swallowed. * * @param request The request being processed * @param response The response being generated * @param exception The exception that occurred (which possibly wraps * a root cause exception */ private void exception(Request request, Response response, Throwable exception) { request.setAttribute(RequestDispatcher.ERROR_EXCEPTION, exception); response.setStatus(HttpServletResponse.SC_INTERNAL_SERVER_ERROR); }

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.

Conclusion:
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?

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:
private void doForward(ServletRequest request, ServletResponse response) throws ServletException, IOException { // Reset any output that has been buffered, but keep headers/cookies if (response.isCommitted()) { throw new IllegalStateException (sm.getString("applicationDispatcher.forward.ise")); }

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

Let's go farther. How is response.isCommitted() implemented:
@Override public boolean isCommitted() { if (response == null) { throw new IllegalStateException( sm.getString("responseFacade.nullResponse")); } return (response.isAppCommitted()); }

That's the implementation from a response facade implementation that delegates the decision to a contained reponse.
Let's see what does it do:
/** * Application commit flag accessor. */ public boolean isAppCommitted() { return (this.appCommitted || isCommitted() || isSuspended() || ((getContentLength() > 0) && (getContentWritten() >= getContentLength()))); }

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.
@Override public void flushBuffer() throws IOException { if (isFinished()) { // throw new IllegalStateException // (/*sm.getString("responseFacade.finished")*/); return; } ........... .......... response.setAppCommitted(true); response.flushBuffer(); }

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:
response.getWriter().println("truallfdasfdafasfdasfasfdaa"); response.flushBuffer(); response.getWriter().append(Boolean.toString(response.isCommitted())); request.getRequestDispatcher("/Test2").forward(request, response); response.getWriter().append("blabla");

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.

Queue<String> queue = new PriorityQueue<String>(); queue.add("J"); queue.add("A"); queue.add("V"); queue.add("A"); System.out.println(queue);

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:
class Parent{ public Number getNumber(){} } class Child extends Parent{ public Integer getNumber(){} }

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.

Hi!

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:
class Parent { <T> void say() { } } class Child extends Parent { void say() { } }

and this does not:
class Parent { void say() { } } class Child extends Parent { <T> void say() { } }

public static void main(String[] args) { Console console = System.console(); try { console.reader().close(); } catch (IOException e) { } String name = console.readLine("Please enter your name: "); console.format("Hello %s!", name); }

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.

John

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

package md.vararu.bean; class Job extends Thread { private Integer number = 0; public void run() { for (int i = 1; i < 1000000; i++) { number++; } } public Integer getNumber() { return number; } } public class My { public static void main(String[] args) throws InterruptedException { Job thread = new Job(); thread.start(); synchronized (thread) { thread.wait(); } System.out.println(thread.getNumber()); } }

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:

Pattern pattern = Pattern.compile("\\d*"); Matcher matcher = pattern.matcher("ab34ef"); boolean b = false; while(b=m.find()){ System.out.print(m.start()); }

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:
Short x = 200; //It shortens the int to short and then autoboxes it to Short.

and this does not compile ok:
xxx(200); static void xxx(Short xxx){}

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.

Henry

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).