Develop Reference

Tomcat API vs other APIs

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.

Java EE and Desktop apps

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

Java EE Open Source project to learn from?

I'am trying to dive deeper into Java EE,
so i was browsing SourceForge to look for a project
that can help me see how components fit together
so if comeone could point out a specific open source project
or any other resource that can help me with this.

The canonical sample application to learn Java EE used to be the Pet Store from the Java BluePrints program (now) at Oracle.
Check out here for a list of blueprints. The Pet Store is here

Barring a specific need, if I wanted to "learn Java EE" today, I would focus on the EJB-Lite profile of Java EE 6. Basically this is the web tier, JPA, and embedded Session Bean EJBs.
These components are the "90+%" of what folks do with a full boat Java EE server today. I don't consider learning the web tier enough to be considered "Java EE". Yea, it's a component of Java EE, but I think EJB is more important, and EJB is more "interesting" along with the web tier.
EJB-Lite hits the sweet spot of functionality and ease of deployment and packaging.

Open eSignForms by Yozons is an excellent Java EE application to learn on.
Check out their website and download their esignature and web contracting application.
You'll learn advanced topics such as sending and receiving mail, integrating with PostgreSQL, Apache Tomcat, encryption, and much more!
They also make extensive use of the Java framework Vaadin for a modern and responsive web application interface.

Alternative usage of Spring Roo

is Spring Roo supposed to be only a tool for rapid development of web applications, thanks to all that scaffolding, source code generation and similar stuff, such as grails for groovy.
Or can it be utilized as a source code generator / osgi platform for building enterprise applications ? What I mean is, that there are source code generators, that generate only domain model and light DAO layer based on metadata definition when starting a new project and you have to stick to the objective - create a web app. But there are also generators, that generate the entire DAO and service layer - fantastic for iterative dev process of bigger apps - and you are not restricted otherwise, you are just using it to build you enterprise app step by step. With this you can really build a huge enterprise applications / platforms that will be maintainable for a very long time.
Also the OSGI model could be employed in a way, that you might develop a core portal application for instance, with a package of social office addons that you may plug in, etc. etc.
My point is, that Java development needs to be "Rubyfied". I mean Ruby on Rails environment where you have everything unified and standardized. A platform that could rule the java world some time :-)

Since Thomas and #jhericks trashed Spring Roo I'm going to say I actually like it mainly because its not a framework. Roo also (now) support multi-maven modules.
To answer your question: Spring Roo is not framework. It is code generation.
So yeah it is a code generation platform not only for web apps but any Java app.
There are couple of reasons why some people don't like Roo:
It uses AspectJ
It uses Spring
It does Code Generation
After building several applications with Spring Roo I can say its greatest value is its ORM generating abilities and its DataOnDemand test generation.
Other than that Spring Roo is really just Spring *.
Frameworks like Play and Ruby on Rails are just not really the "Java Way". That is most Java (Web) Apps I see are combination of libraries and not a giant framework.

As far as I experienced, Spring Roo is meant to be a RAD/bootstrapping tool for web applications. There are some major features missing and not on the roadmap that would make it truly useful in an enterprise application context. An example being multi-module Maven support.
This rather polemic article and its follow ups summarize quite well how I feel about Roo and similar projects like Seam Forge.
If you are looking for something RoR-like for Java check out the Play Framework that currently seems to gain momentum.

What are benefits of JBoss AS-based application architecture?

I am trying to understand what does JBoss AS can bring into the project, comparing to standalone architecture?
My model application is a solid thing, starting, running and stopping as a whole and solely at the host.
It has a database storage, and communicates to user and other servers, clustering required.
It has web-part. It's just a standard big application.
JBoss for me is a shell for (in general) multiple applications, providing my application with some standard services. This shell is also a solid thing - "get all or nothing", something can be turned on/off (influencing your app unpredictably, or influencing other part of the JBoss) or replaced (very hard and is already kind a hack) with different version or other module.
Standalone application for me is something combined of pieces with glue among them (Spring if you like) with IoC wiring. We can get everything we could have with JBoss, but separately. Spring or other glue serves here like an application server, but it's thinner and we still can replace parts or even Spring itself (IoC wiring is straightforward from coding point of view).
For me, standalone, AS-free approach gives more control and flexibility. And further more, last versions of JBoss AS are purely documented, some features (most interested) are not documented at all.
So, why somebody still choose JBoss - what are benefits?
I favors more standalone application approach, but need more facts to understand better and convince others.

It seems to me that what you are describing is the classic choice between best-of-breed (collecting all the parts and glueing them together your self) versus integrated stack (JBoss wrote all the parts and integrated them for you). This is a debate that will rage on for eternity. If best-of-breed is working for you then stick with it.
JBoss is a J2EE container. Take a look at the J2EE spec if you are unfamiliar with it. Basically Sun's community process came up with an development framework that contains components that you may be interested in when creating large scale apps. J2EE contains multiple sub specs such as Servlets, EJB, JTA, JMS, and a whole host of other alphabet soup technologies. If you aren't using any of these technologies then you do not need a J2EE container. If you are just interested in using Servlets and JSPs then you are better off using a servlet container such as Tomcat, Jetty, Resin, etc.
Providing enterprise features such as scalability, transactional support, federated user management, etc. are difficult. A J2EE container provides a standard level of these features. If you can find them elsewhere to a level that meets your satisfaction then more power to you.

You can also pick and choose if you are running inside JBoss. If you are happy with the JBoss services you can use them or deploy some others if you don't like the one JBoss provides for you.
Starting from the JBoss minimal configuration and building up your own configuration should give you a setup where you don't have services running that you don't need. Personally, I like to know what my AS is running, so I prefer to start from minimal configuration adding only the necessary parts.

I would say the only reason to use JBoss is if you need to access the Java EE services (like Messaging, container-managed transactions and similar).
Keep in mind JBoss is (roughly described) Tomcat plus Java EE services (yes, yes, I know, this is a very simplified approach, just bear with me). I mention this as I would say your decision is:
If you only need IoC and some other capabilites you can get with Spring and Tomcat, go with that
If you application requires Java EE services, use JBoss
Keep in mind you can always start with the basic system (Spring + Tomcat) and move to JBoss if required later on. Nothing forbids that.And probably starting with that approach will show you if you really need the Java EE services or you were over-engineering the solution.