Choosing a JSP instead of a servlet as a BS foreground mainstream program is Java's strategic direction error

Js|servlet| Error | strategy | main text
Many people think JSP is Java to Microsoft ASP Challenge successful products, to today, around the JSP program developed Tag/el Technology, JSP as a Java BS foreground interface solution seems to be irreversible. But in my opinion, Java chooses JSP this kind of expression, it is the most failed place, is a parody of the ASP, it could have done better, and may even let Microsoft completely out of the server domain, but in the end, it may be enough to make Java final failure of the major strategic direction of the error.
Java today still has Microsoft all languages do not have the advantage, in C #, is just the shape and God does not like. The most fundamental part of Java is not its OOP, not that it's a C + + syntax optimization, it's not important, it's the virtual machine mechanism that makes it the best Cross-platform server language, and C # no matter how grammatically similar, it can't change the reality that it's just one of the languages in Microsoft's CLI, It succeeds, and at best replaces the Java that runs in Windows; In a way, C # is a language that is doomed to be unnecessary, and in the CLI, just one is enough, like vb.net.
The biggest impact of Java to the software world is that the software is truly layered, with a real three-tier structure. Although some guys boast that their software is n-layered (really shameless!) In fact, it is only the traditional CS-type two-tier structure of the variant, can not add a function of each one called a layer Oh! Java appears to embody the creative thinking of the software, but the biggest mistake of Java is that he has no creative imitation of the ASP, and even the JSP as the main middleware access means to develop. This is a big mistake, perhaps, if Java dies one day, it will die on this mistake.

ASP is the imitation of the earliest livewire-style JSP and Cofusion,livewire is also my first contact in the project JSP, and later Java JSP is not the same place. This Netscape company's "JSP" and ASP have a common feature, that is, there is no object-oriented features, is a pure analytic scripting language, and later PHP is such a product, PHP can be seen as a cscript in nature. The appearance of these languages is intended to meet those who do not understand the computer language, from the HTML art to change the ability of the half-baked programmer needs, the United States is called so that art can write dynamic page level. However, this development is supposed to be one of the biggest jokes since the advent of the Internet, art programmers can never write real dynamic Web pages, but let real programmers to do the art of life, the most typical product is struts.

Java is completely different from this, it is a language that needs to be compiled, with complete object-oriented ability, so if it can play this feature, defeating several other scripts is no difficulty. As a result, Sun's talented idiots (I think the term is the most objective, both gifted and stupid), chose to use tanks and Jetta to compete for the taxi market, to do JSP. And I think that the servlet should be its best development direction. Today, I've forgotten what caused me to give up my JSP and use the servlet as a project solution; Just remember that the JSP was completely discarded because it was complicated to pass the variables and addresses in two forms, rather than a light one. Today when I thought I was wrong, and the emergence of the label/el and other technology will make JSP different from the past and once again in the selection of major projects JSP, (one of the reasons is also the continuation of the joke, I hope that the maintenance personnel can not understand the Java in the delivery of their own maintenance system front), as the project entered, I remember the first reason to give up JSP: One is that the code management is very difficult, JSP system is basically the same as other PPP classes are not maintainable, and another reason is that JSP can not be based on the template maintenance. The former is mitigated by the advent of tag and so on (it used to be able to use include sevlet approach to achieve close effect), the latter is still the same, the key is not to cover the existing code. In the servlet, overloading a method is easy.

Many people think that the servlet is difficult to write, in doget/dopost/init/and so on need to cram so many methods; in fact, this is a misconception that the servlet is essentially a Java class, can easily public private methods, can also inherit, Can overload and so on. Therefore, it is easy to form a system-wide following template in the servlet, and change it together. On the contrary, think that the writing servlet is in doget with out.println output, is to write JSP understanding into the servlet; JSP is compiled into a servlet, and that's exactly what it looks like. So it does not exist the value of inheritance.

So how does a complex HTML interface achieve the same simplicity of embedding as a JSP? It's actually very simple. My solution at the time was to use ${xxx} to mark presets by default, and then to have a directory of these tagged files with a lot of HTML code, read through a file byte stream when the SVERLT was initialized, Use a String parsing component (which is still in use today) to convert the tag into the corresponding actual dynamic variable. This is precisely today's so-called most advanced El Expression language solution. Really, I don't think there's any point in writing a servlet is harder than a typical Web application. In a way, I think I've made a JSP explanation engine out.

So what's the difference between this native JSP and the real JSP? The big difference is that it sees JSPP only as an HTML code base for servlet services, not as a serlvet for JSP services. In other words, the JSP here is something similar to today's tile/jspfragment. A small difference, the effect is completely different, because it can fully play the Java object-oriented and inheritance features, and even as a PB to the entire project foreground as a class "inheritance", and then expand and restructure need to modify the place. And this ability, is the "P" language can never do. But Sun is behind Microsoft's butt to parody JSP.

What is the most common architecture at the BS front desk? is a large site with a similar frame layout for most layouts, and only one of the columns is different. JSP can easily share the same parts, but there is nothing to do with the different parts of it. Because the JSP cannot form a top-level template, and each of the central columns is different, so the only way to do that is to copy a JSP file from each large column to get a top-level frame template; Obviously, this means maintaining the same frame portion of each file; the larger the project, the greater the amount of work to change later. At this time Hou Jin a little nostalgic for the function of the servlet, for this need, just write a servlet, the other servlet inherited it, and then overload its central content method, to do. The only way to achieve a similar requirement at the moment seems to be to use the if-else/equal-notequal judgment in the top-level page to include different content files. Is there any good way to do this?

The correct thinking of the Java BS Front desk should be centered on a servlet that can customize the inheritance method, and then decompose some files such as JSP, which can be used in these JSP files like today's JSP technology. That is, the core should be a customizable servlet, instead of providing a tool to compile the JSP into a immutable servlet. The top-level file should be a servlet, not a JSP, that's what I'm talking about.
I am a person is not possible with the entire JSP community, not one person to complete the work of sun thousands of development engineers, since some sun's genius idiot chose JSP as a Java in the mainstream of BS, to this day, if I still use Java as a foreground interface program, The best thing to do is to conform to the standard, and a few years ago, JSP is not a standard, the situation is different. However, from the actual experience today, I still feel strongly that Sun has made a serious methodological mistake. Even more regrettable is that Sun did not do things, so that Microsoft in the asp.net of the embodiment of Microsoft's things are never intended to be ported across the platform, so Sun has a chance.