Confusion related with <jsp:include> and <@ include>? Dynamic include and "friendly Containers"

There is good discussion on Stack Overflow about their difference found here. It roughly says that <jsp:include> is dynamic, while <@ include> is static. Yet, I have some questions.

1. st question

Say I use <jsp include> to include header.jsp file. It would run like this: Container compiles my JSP file and during runtime it calls header.jsp, which would also get compiled. So now it uses its content as a response to my JSP file (and combines it). But how is it dynamic? What happens if I change header.jsp? As it had already been compiled, it won't see any changes. So does <jsp: include page="header.jsp"/> simply compiles header.jsp every single time to maintain its dynamic behavior? Or there is different approach that "tells" Container to recompile it?

2. nd question

Whatever the answer on first question, I understand that it is dynamic, no matter how does it do it. Well, until I came across this picture from Head First JSP and Servlets.

Does this now mean that even <@ include> can be dynamic, as well? If I am making an app in Tomcat5 (friendly container), why would I care if some other Container (older versions) aren't friendly? I mean, I would use one Container and stick to it, not move my app around other Containers, right? So why I don't simply always use <@ include>, let Container "deal" with any changes in included file, plus I don't get performance hit of using RequestDispatcher every single request (like <jsp:include has).

The <%@ include %> directive is static because it takes the content of the included file and simply "dumps it" in the place of the directive. This is done at translation time, so the content becomes part of the parent JSP as if you wrote it there yourself.

The <jsp:include> action is dynamic because you "call it" by sending it the request and it can generate a response that gets included into the output of the parent JSP. What makes it dynamic is that you can send it parameters with <jsp:param> sub-elements. So basically, instead of dumping some content in the page, it acts like a function that you can invoke with parameters. For this reason, the things you include with it are not just content but it's dynamic content resulting from using a template that you can invoke with various parameters at various moments of time.

As for your second question, this isn't related to the <%@ include %> directive or <jsp:include> action themselves, this is how the server works (and I find it silly that they would call this "a friendly container", but well, the books tries to be friendly, I guess). Tomcat implementers decided that they can make it detect when a page included at compile time has changed and then recompile the JSP that included it, but other servlet container may have not. The specification doesn't direct the implementers to handle this, so the behavior is not portable to other servlet containers.

If you want to take advantage of this fact, that's your choice, assuming you run the same server in all your environments and you can guarantee this fact won't change, a statement which can be valid in a development environment, or if you want to play with things, but most likely will not be valid in a professional setting running user facing production code, where using proprietary things that limit portability is a frowned upon practice.