Hello, dear friends. In this video, we will start examining the syntax of JSP directives in Eclipse. Let's begin. First, open Eclipse. I want to create a new project. If you want, you can use any old project. File new dynamic web project, adjust target runtime. Next, and finish. Now, on web content, right-click. Add a new JSP file. If you don't see the JSP file option, you can select 'Other', then search for JSP and you can add a JSP file. Give it a name and click 'Next'. In this area, you can select the page where you want to use JSP codes. I want to use HTML markup. As you can see, you can also use JSF pages. Finish. Now our page is ready. In the previous video, we talked about this code snippet. Let's run it and see the result. Now, run the page. And look, now we can see the millisecond count, and also today's date as day. Now we can start to examine the syntax with the JSP directives. JSP directives which dictate properties global to the JSP are all of the forms. They can appear anywhere in the JSP file, though by convention, they are usually listed at the top of the JSP file. This makes good sense because their effect is on the whole of the JSP. The three directives are page, include, and tag lib. Page directive governs general properties of the JSP, such as characterizing its output, buffering properties, and using imports for Java Scriptlets. Include directive allows a JSP to include the content of another file. This can be useful for including, for example, a standard header in your JSP. Tag lib directive allows a JSP to declare that it will use special tags from something called a tag library. A tag library is a collection of Java classes that formulate small snippets of markup output, each of which is associated with a markup tag that can be included in a JSP page. We will see tag libraries later in this lesson. Each JSP directive may appear multiple times with different attributes. So, there is a design choice as to whether to use multiple attributes with the same directive name, or whether to list multiple directives, each with one attribute. The type of design choice is really a matter of aesthetics, but developers usually group related attributes together in the same directive, and use separate directives for attributes that are not related. Let's start with page directives. JSP page directives are a collection of instructions to the JSP runtime as to how to process the JSP. There are several different kinds. Let's take a look at them one by one. The first one is attributes governing JSP. Output two page directive attributes declare information about the output of a JSP. contentType and pageEncoding. The contentType attribute allows the JSP to declare the mime type of the content it produces. And the pageEncoding attribute allows the JSP to declare the character encoding it uses. These may be listed as separate attributes or for brevity, the pageEncoding may be combined into the contentType attribute. For example, we can define contentType  = text HTML and pageEncoding  = UTF-8 in different page tags. But if you want, we can also define the page contentType as text HTML, UTF-8. These are the same. You can use any one of them. There are many types of content. For example, image JPEG or plain text. Attributes governing languages used in JSPs. JSPs use the Java language for scriptlets and JSP expression language, JSPEL. Languages other than Java may be used for scriptlets if the underlying implementation supports them. Four page directive attributes govern the use of these languages in a JSP. Language isELIgnored, isScriptingEnabled, and import. A JSP may declare the language Java directive to indicate it uses Java in its scriptlets, although this particular value is not usually necessary to declare, because Java is always supported in JSPs. If a JSP does not use JSPEL, it may declare it as, isELIgnored = "true". This can yield some performance gains. The default is that the JSP implementation always looks for uses of JSPEL in the JSP. Finally, a JSP that uses no scriplets at all may declare this by using the page directive isScriptingEnabled with a false value. The JSP implementation assumes that every JSP has scriplets, unless it is told otherwise using this directive. When Java scriplets are used, they often need to import classes from other Java platform packages, in which case the JSP must declare a page directive using the import attribute.  The value is a comma separated list of packages the scriptlet's code in the JSP will need. For example, import java.util*, java.text*. This will be the same as page import = java.util., page import = java.text. Many developers prefer the second style where the import is split into multiple page directives using the import with a single package, as it more closely mimics the single package per import statement pattern found in the Java language. JSP Scriptlets may use any of the classes in java.lang, the Java Servlet API and the JSP Java API, which are located in javax.servlet with sub packages, and javax.servlet.jsp with sub packages. Let's move on to attributes that control how the JSP behaves at runtime. When the JSP page output is gathered in order to be written into the underlying output stream back to the calling client, there are a number of choices about how the content is written. The implementation may buffer the content and may wish to choose when to write the buffer to the output without using any special page directive. JSP implementations buffer the page output and automatically flush the content to the output when the buffer fills. So, these switches are definitely for more advanced developers. They can give useful control to the developer in optimizing JSP performance for particular pages and particular clients. The last two attributes of the JSP page directives are a request to the JSP implementation to control aspects of how the JSP output is buffered. autoFlush and buffer. The buffer attribute defines whether any buffering is used at all and if so, how large the buffer should be. The second, the autoFlush attribute, is a switch that instructs the JSP implementation whether to flush the buffer when it fills or whether to require the JSP to flush the buffer manually. For example, autoFlush = "false" and buffer = "8 kilobyte" instructs the JSP implementation to use a buffer no smaller than eight kilobytes and not to flush it automatically. Contrastingly, buffer = "none" instructs the JSP implementation not to use a buffer at all. And buffer = "6 KB" instructs the JSP implementation to use a buffer of size at least six kilobytes with automatic flushing of content when the buffer fills. As for Java Servlets, the default threading model for the JSPs is that they are expected to handle multiple incoming HTTP requests concurrently. This frequently happens in web applications with more than one client. However, it can be useful to be able to create JSPs that you know will only ever be called by one thread at a time. In such cases, JSP implementations may choose to make any concurrent requests from a line and invoke only the JSP one thread at a time, or it may choose to instantiate multiple instances of the same JSP, each handling only one request at a time. With either approach, the JSP implementation can guarantee that each JSP instance is handling one HTTP request or thread at a time. You can use the isThreadSafe attribute, isThreadSafe = "false" to let the JSP implementation know that this JSP needs gentle handling and should be called only one thread at a time. JSP error pages. JSPs may act as error pages for other web components. This is useful if you wish to customize the page that the client sees if a JSP generates an unhandled runtime error. In such cases, the JSP that wishes to act as a nicely formatted error page must use the isErrorPage attribute in a page directive, isErrorPage = "true". And a JSP that wishes the client to be redirected to this error page in the event that an unhandled exception at runtime can indicate the name of the JSP that it wishes to use using the ErrorPage attribute. Done. Let's continue with the session. Turning off HTTP session tracking. As we will see when we look at JSP implicit object shortly, JSP developers can easily get hold of the HTTP session from the JSP Java environment available to scriptlets. However, session tracking comes with some overhead, and as an optimization, some JSPs that do not make use of the HTTP session can turn off the session tracking mechanism by using the session attribute of the page directive. We only need this session = "false" attribute by default, that is, without such a directive, the HTTP session is always maintained by the JSP implementation. There are many attributes of page directives. I don't want to explain all of them. You can find the necessary information in this table. This table summarizes the attributes of the page directive. These are the other attributes of the page directive. Now, I think that's enough for the page directive. Now, let's take a break here. In the next video, we will continue examining directives. See you in the next video.