I've been learning Tomcat and servlets recently. Now I came to realise that the Oracle API and the Tomcat API are at least somewhat different. I know the Oracle API should be wider, but still even in the limits of Tomcat operation, they seem to have completely different packages, etc.
This may seem silly, but I can't find any answer. Could someone please explain the differences? And in practical terms, if I build a service that runs under Tomcat, will it also run in, say, Glassfish, without any refactoring of imports?
--- EDIT ---
So, apparently I mistook Tomcat API for Servlet API, etc.
The solution is not to look at the Tomcat Javadocs in the shot above, but at Servlet Javadoc, or whatever is in question. The list in the pic can be found at Apache Tomcat 8 Documentation Index, on the left, slightly down.
Thanks, Andreas and EJP.
Java Enterprise Edition
What you call the “Oracle API” is actually the Java Enterprise Edition (Jave EE) specification. I suggest you avoid using your misnomer.
Java EE is a vast collection of dozens of varied technologies layered on top of Java Standard Edition (Java SE). Various implementations of Java EE support different pieces, not necessarily all of them.
Subsets of technologies
The Apache Tomcat project, and similarly the Eclipse Jetty project and others, intentionally implement only these technologies:
Java Servlet
JavaServer Pages (JSP)
Java Expression Language
Java WebSocket
These few APIs are just a small, but vital, subset of Java EE.
The Tomcat API you linked is specific to Tomcat’s implementation. Developers would only very rarely go through that API. Instead we stick to the interfaces published in Servlet, JSP, EL, and WebSocket specifications all published as JSRs. Sticking to the specs means your web app can be deployed on other implementations as an alternative to Tomcat should the need ever arise.
Web Profile
The Java EE Web Profile is a specification that includes Servlet and JSP APIs along with several more, but still a subset of all the possible Java EE technologies. Apache TomEE is one implementation of the Web Profile, that starts with Tomcat and adds more libraries. Another example is Glassfish, which is/was available in either a complete Java EE edition or a stripped-down Web Profile edition. See the Question, What is different about the Java EE packages? (SDK/normal vs Web Profile).
“Full” implementations
Some products implement all (or nearly so) of the Java EE specifications.
Sometimes this is described as a "full" implementation. I consider that label misleading as it implies the subset implementations are missing or lacking something needed. Quite the opposite. You should always use the leanest implementation that includes only the parts you need. More heavily laden servers take more memory, start and stop more slowly, and may cost more money. For example, I build and deploy highly interactive desktop-style web apps using only Apache Tomcat 8 with Vaadin 7 on top of Java 8 Standard Edition (SE) on Mac OS X.
Also keep in mind that many of the Java EE technologies can standalone, separate from a full Java EE implementation. So you can start with a leaner implementation and then add the libraries for just the few individual technologies you need. For example, Bean Validation can be used on Tomcat by adding the JAR file of an implementation.
Related
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Java: A good introduction to J2EE platform for noobs
I'm not new to programming at all - I've programmed in .net for over a decade. I have dabbled now and then in java, but never at an enterprise level. Now I'd like to learn to use Java EE.
What are some good online resources, or books that I can buy? I'll need a step-by-step on what to download to set up my environment (I already have the Glassfish tools bundle for eclipse, but I'm not sure if this is what I need or where to go with it...).
I think coding a simple website to perform basic crud operations would give me a good start.
To begin with, I'd stay away from anything that says J2EE as it's an outdated uglier version. Look for Java EE 6 or at least Java EE 5.
Apart from that my recommendation would be to download the Java EE version of Netbeans
since it has everything you need. In the same site there several starting tutorials and a longer e-commerce tutorial
If you want to start with Servlets and JSPs in Tomcat, just make sure it is selected during the install procedure.
Glassfish is fine. You might consider JBOSS as well; it's another Java EE app server that's open source and won't cost you a thing to try out.
I'm not sure if WebLogic from BEA/Oracle is still available to download for developers to learn, but it's my favorite Java EE app server. Version 9/10 from BEA, before Oracle bought them, was simply the best.
You can start with a servlet/JSP engine like Tomcat or Jetty. You would begin with servlets (HTTP listeners that respond to GET/POST requests); JSPs (a templating language using tags that are compiled into servlets and executed on the server - think of them as servlet/HTML factories); and JDBC (relational database connectivity). You can go a long way with just those.
Once you've mastered those you can decide between a Java EE solution (EJBs) or Spring. Spring is not part of the Java EE spec, but it's a fine alternative. It's a combination of dependency injection, aspect oriented programming, and solid modules for persistence, remoting, messaging, web services, web MVC, LDAP, etc.
The NetBeans IDE is not so ubiquitous as eclipse (so eclipse is a very good choice), but makes Java EE 6 with Java 7 and GlassFish very easy. And netbeans.org has several tutorials.
I'm new to Java and have just started with some simple code.
I'm on a Linux machine, use the vim editor, use javac for compilation and 'java' for running
programs.
Basically, for the time being, I am looking for building a desktop application using Java. I've heard about Java (EE/SE/ME) and my assumptions about them are:
"Core Java" is the "basic" Java language(with all the rules about variables,
looping, methods classes etc).
Java SE is for Desktop Apps.
Java EE is for Web apps (using the HTTP protocol).
Java ME is for Mobile Apps.
However, I came to know that the difference among them is that "specification", from Difference between Java SE & Java EE
So my question is, can I create Desktop Apps using Java EE as well? Or are they only for creating Web Apps?
Java EE is a large collection of technologies that together forms a more or less coherent framework for building enterprise applications.
Now in the enterprise, server applications are used a lot and so many technologies focus on server functionality and/or multi-user. Serving web requests is but a part of this, there's also functionality for e.g. processing messages (JMS) and server remote method calls (remote EJBs).
A complete Java EE implementation like GlassFish or JBoss AS is not that often used for desktop applications (unless it's an application intended for personal desktop used, but that's browser based).
HOWEVER...
Nearly all of the technologies that make up Java EE can be independently used on top of Java SE and in combination with a graphical user interface.
For instance, there's an ORM framework in Java EE called JPA that makes it rather easy to store objects inside a database. A database, possibly an embedded one, can of course be used with desktop applications and this often makes sense. E.g. an email application might store mails in such a database. JPA explicitly has a section in its spec about being useable in Java SE.
There's also a framework for dependency injection in Java EE called CDI. This among others makes it easy to isolate dependencies and get hold of them. It's a natural fit for MVC graphical applications to e.g. get hold of the model in a controller. Like JPA, CDI has explicit support for Java SE.
As the last example, Java EE by default requires JMS to be present, but in this case JMS is not even specifically a Java EE sub-spec. Java EE only requires a JMS provider to be present, so naturally Java SE can use JMS (there is even API in JMS that is only legal to be used in Java SE). Messaging in a way can be part of an architectural pattern that is just as useable in desktop applications as it's in server applications (the desktop toolkit Cocoa for example uses it intensively).
There are more Java EE technologies useable in desktop applications, but I hope the above has given you some idea.
Java EE is a collection of technologies, including web apps.
Most of it isn't, though--things like JMS and JPA are part of Java EE, and are application-type-neutral.
Java EE is Java SE + enterprise technologies. So yes, you can build desktop app using java EE.
Java EE is just a set of specifications. Most of its implementation need something more than Java Runtime Environment used for JSE.
Different parts of Java need different kinds of containers.
Parts of Java EE 6 You can run on JRE:
Note about JSR 299 from the Weld website:
But the specification does not limit the use of CDI to the Java EE
environment. In the Java SE environment, the services might be
provided by a standalone CDI implementation like Weld (see Section
18.4.1, “CDI SE Module”), or even by a container that also implements the subset of EJB defined for embedded usage by the EJB 3.1
specification.
GlassFish can also run Java SE app in Embedded Enterprise Bean Container within the same JVM as Java EE app, so You can for example access Java EE's EJB using local interfaces.
Souroce of the images
Okay guys, I was new to Java and now I have become a bit "old". So I could figure it out.
This is it :
The ONE AND ONLY ONE required thing to Java development is a Java compiler which we get if we install a JDK and the thing we need to run a Java utility is a JVM. So these are the only things we require for ANY sort of Java Development(No matter Desktop, Web or mobile).
Then what is Java SE, Java EE and Java ME ?
Those are the above mentioned two things(Java compiler + JVM) plus a set of libraries(SE for Desktop, EE for Web, ME for mobile). So if any of us have enough time and have got a Java Compiler + JVM, we can build our own libraries for all those functionalities.
But following the concept "Don't reinvent the wheel" and because we'll be better off using a library/tool that has been running smoothly for years we all use the tools/libraries provided by SE, EE and ME.
So the answer is, I can develop any sort of applications with just a Java compiler(/usr/bin/javac on a Linux machine). The only thing is that there will be a lot of 'reinvention of the wheel'. And all java apps run on the same JVM(no matter what sort), in case of linux(/usr/bin/java).
I am developing a web application using JSP, but it seems that Java EE is very big for my application. I'm only doing something like a blog.
Can I use a pure JSP and ignore Java EE and the JavaBean and start a pure JSP project?
JavaSE on its own is not sufficient to use JSP, you need at least some components of JavaEE. Specifically, you need a servlet container, such as Jetty or Tomcat.
Neither of these requires (or even contains) the rest of the baggage that comes with a full JavaEE stack.
You don't need to download the huge Java EE packages as offered by sun.com/oracle.com. All it basically contains is the Glassfish server and eventually the Netbeans IDE. Glassfish is a fullfledged and heavyweight Java EE server.
The minimal requirement to develop and run JSP/Servlet is the following:
JDK (click the first Download JDK button) - about 75MB.
A JSP/Servlet container, I'd suggest Apache Tomcat - only about 7MB.
That's all. You have only to choose a development editor, which can be just Notepad. However to ease and speedup development, I'd recommend using an IDE like Eclipse for Java EE. It offers code completion, automatic builds (compilation), easy debugging, deploying to integrated server, etc.
That said, Javabeans is just a specification, say, a style of coding. Public classes with private properties and public getters/setters which represent real world data e.g. Person, User, Product, Order, etc. It doesn't require a download. You just have to write it yourself. However, to ease development and maintenance it's strongly recommend to use Javabeans in your code.
See also:
Is the sun tutorial the best way to learn how to make a Java webapp
Java web development - What skills do I need?
What is a Javabean and where are they used?
JSP tag info page
There's no requirement you use all the features of the Java EE server. There's also stand-alone servlet containers like Apache Tomcat.
What has me going is the degree of web application development we are talking about.
There are different levels of web application development. For example, if I was asked to develop a web application to deal with housing customer information for a small mom and pop bakery (definitely not a enterprise situation), is there anything wrong with using Java EE as opposed to Java SE if I really want to.
I know you might say that it would be overkill, and I can understand that, however, am I going to run into development issues that I would not run into using Java SE? In other words, I am trying to determine when does a small business web application turn into a enterprise web application. It seems to me that I should be able to use Java model that I want.
Am I wrong in my thinking here?
Need clarification here if you can help me.
There seems to be some confusion over the usage of Java EE and Java SE terminologies. Just because EE expands to Enterprise Edition, it does not mean that it is used only by enterprises.
Java EE happens to be a set of specifications that are bundled together to form a platform. The moment you need to write a web application, you need to use the Servlet + JSP specifications at a bare minimum, which is a subset of the Java EE specification.
Java SE, on its own is usually used to write standalone applications. It is better to refer to Java SE more as an API or a library, rather than an as specification, in contrast to Java EE. It can be considered as a platform for the "non-enterprisey" applications.
Don't take Java EE literally. Java EE is not just enterprise development, per-se.
Java EE gives you the entire stack for building web apps on Java. You just can't do web development on Java otherwise.
Bottom line - you need the Java EE stack, even if you are a small/medium business. Don't let the name fool you.
Theres nothing wrong with using a full Java EE container. However this usually comes at the cost of complexity.
The minimum you need is a servlet container which is a subset of the Java EE specifications.
Full Java EE containers tend to have more to configure in them than simple servlet containers which may add overheads that are not worth it.
The other thing to consider is If you do use just javax.servlet to compile .war files then these are compatible with full Java EE containers so there is nothing to stop you upgrading at a later point.
Another point to keep in mind is JBOSS / GlassFish which implement the full Java EE stack use more memory and may have longer startup times than say tomcat.
If however you know that you will be using more of Java EE at a later point such as EJB; then I would start out with the full Java EE container.
To Summarise
Personally I would start out using just a servlet container. (not full Java EE). If and only if I needed a full Java EE stack then I would move to a full Java EE container.
I am little confused about Java frameworks (I am coming from .NET). Do you need different server setups to run Java, J2EE and JSP? Does Java make a distinction in frameworks for enterprise and non-enterprise deployments? Beans? Struts?
Can someone make sense of this for me?
.NET has:
Windows development (Winforms, WPF)
web:
i) webforms
ii) mvc
These are the most commonly used terms that correspond to your "Java versions":
JRE: Java runtime environment, what's needed to run Java programs
JDK: Java development kit, a JRE plus compiler and some additional tools
Jave SE: Standard Edition, the API library that comes with every JRE and JDK for desktop use
Jave EE: Enterprise Edition, additional APIs that extend the J2SE for business use, meaning mainly server applications - this includes JSPs
Jave ME: Mobile Edition, a set of APIs (mainly a subset of J2SE) for mobile devices like phones
(The latter three are often also written as J2SE, J2EE and J2ME meaning "Java 2 ___ Edition" - Sun's naming and versioning convention are rather confusing)
Note that all of these are basically specifications, and there are implementations from different vendors. For example, you can get a J2SE 6 JDK not only from Sun, but also from IBM and Oracle.
There's a few different ways of looking at this.
Firstly, the only current version of Java is Java 6 currently at Update 17 or so. Java 5 and earlier have all been end-of-lifed. What's a little confusing is that starting at version 1.2 Java adopted the name "Java 2" (and was referred to as J2SE or "Java 2 Standard Edition") so it was Java 2 version 1.2. After Java 2 version 1.4 (or more simply Java 1.4). Version 1.5 became Java 5 or J5SE although J2SE is still pretty common.
The other version of Java that's relevant is Java Enterprise Edition ("Java EE"), formerly J2EE ("Java 2 Enterprise Edition") with version 6 being imminent. Java EE specifies a set of standards for server apps. The most important part is the servlets specification, which is the basis for 99.9% of Java Web frameworks. It has versions and is currently at either version 2.5 or 2.6 (I forget). Apache Tomcat is the reference implementation of the servlets specification.
Another part is EJB ("Enterprise Java Beans") currently at EJB3/3.1. It's a component architecture and really heavyweight. It's not used anywhere near as often as the base servlets specification.
Whereas Tomcat is a Web container, full Java EE supports is provided by what's called an application server. Examples include Glassfish, JBoss, Weblogic and Websphere.
Java classes are often packaged as JARs ("Java ARchives"), which is simply a zipped file with a specified directory structure.
Web applications are packaged as wars ("Web ARchive"), which is just a jar with a different extension. WARs may contain libraries in JAR form.
Full Java EE apps are packaged into EARs ("Enterprise ARchives"), which again is just a different file extension and it may contain war and other files.
Now to complicate this there are about a bazillion Java Web frameworks such as Struts, Spring MVC, Tapestry, Wicket and many, many others.
Also, it's fairly common for Java Web and enterprise apps to use the Spring framework. Spring is (imho) a must-have for Java serverside development as it simplifies a lot of vendor and library differences and makes your application far more pluggable.
Confused yet?
There are several versions of the JDK (1.4, 5, 6), much like there are several versions of .NET (1.1, 2.0, 3.0, 3.5). J2SE and J2EE are really just different packagings of the same version. J2EE includes some extra namespaces that aren't in J2SE.
From wikipedia:
Java Platform, Enterprise Edition or Java EE is a widely used platform for server programming in the Java programming language. The Java platform (Enterprise Edition) differs from the Java Standard Edition Platform (Java SE) in that it adds libraries which provide functionality to deploy fault-tolerant, distributed, multi-tier Java software, based largely on modular components running on an application server.
If you are going to implement a web application with Java, you can use Apache or Tomcat as a webserver.
To develop in Java, I suggest downloading NetBeans from here:
http://netbeans.org/downloads/
I prefer NetBeans than Eclipse because it is more similar to .NET's IDE, which basically means, it is more helpful.
With NetBeans, you can program every type of Java application, from a client java application, to a servlet, applet, etc...
There are 3 main Java platforms:
Java SE (standard edition)
Java ME (mobile edition)
Java EE (enterprise edition)
They all have the Java programming language in common, but differ in terms of APIs and libraries included in them.
From your question I'm guessing you're looking at Java EE?
Although it is possible to code an enterprise application in Java SE, Java EE is the natural choice because it takes care of many things you would face and allows you to focus on the interesting and useful parts of your application.
Java doesn't really distinguish from enterprise and nono-enterprise, in fact, you can use the APIs from Java SE in Java EE, and it's possible to use Java EE APIs in Java SE programs.
So what's the difference then?
Essentially, they are all platforms, execution environments. Java EE is more suited to developing big projects than Java SE, and as such includes various servers and things to help you code those big applications.
Beans, Servlets, Apache Tomcat server, Glassfish server all fall under the Java EE platform.
First you have the Java SE which contains the standard Java API. You can download it as JRE (only runtime) or as JDK (includes developer tools like java compiler).
Then you have the Java EE which contains the enterprise Java API. Java EE is in fact an abstract API (exist of almost only interfaces, abstract classes and API contracts). You need a concrete implementation to get a running Java EE platform. In case of JSP/Servlet you basically need a servlet container. Commonly used ones are Apache Tomcat and Sun Glassfish (which is bundled in Sun Java EE download).
You do NOT need to download the Java EE from Sun when you need Apache Tomcat. Just the Java SE is enough. The Sun Java EE download contains basically the Glassfish server and is also available as a bundle with Netbeans IDE (which I personally don't recommend for web development; Eclipse or IntelliJ are better choices for web development).
Let assume you would like to use Eclipse and Tomcat, then to get started with web development you basically need the following:
Java SE JDK 1.6
Apache Tomcat 6.0 (core, binary distributon)
Eclipse IDE for Java EE developers
jstl-1.2.jar (standard JSP taglib, use it instead of scriptlets!)
To kickoff with all:
Install Java SE.
Extract Tomcat zip and put it in desired location.
Extract Eclipse zip and run eclipse.exe.
In Eclipse's Servers view, add new Tomcat server and point to the Tomcat location.
In project explorer, create new Dynamic Web Project and pick the Tomcat from the list.
In the created project, drop the JSTL JAR in /WEB-INF/lib.
That should be it. You can create JSPs in /WebContent folder and create classes (servlet, filter, bean, domain, utility, etc) in src folder.
As to Struts, it has nothing to do with Sun. It's a component based MVC framework of Apache which is roughly said the competitor of Sun JSF. You can download it separately, put the libraries in WEB-INF/lib and use it in the project.
There is one JDK (only JDK 6 is supported today) and the Java Runtime Environment (JRE 6).
Typically you need only the JRE, but some frameworks need the tools.jar (i.e. javac) to run.
Even server and client modes can be detected and the Java EE libs come with the application server (or web server) you use.
Actually java has many other editions but normally we did not use that in applications ,
list given below :
JavaSE
JavaME
JavaEE
JavaFX
JavaCard
JavaDB
JavaTV
JavaEmbeded
and we can have 4 types of files in java :
Jar (Java archive)
War (Wep applications archive)
Ear (Enterprise application archive)
Rar (Resource adapter archive)
sorry for speling mistakes ,,,,