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).
Related
As a Java EE newbie having a background in Java SE, I don't quite understand what the Java EE, especially those buzzwords like web container,Jave EE container mean.
What I know that to run a java program, you need to call java with classpath set to dependencies (normally .jar) and an also an entry class with static main method.
I think to start Java EE programs, there is no difference than calling java, right? So are containers most of the time just .jar files that contains implementation of Java EE standard annotations?
Are containers like JBOSS just a bunch of libraries that are used to support the so-called "enterprise applications" involving transactions, security and so on?
Java SE = Standard Edition. This is the core Java programming
platform. It contains all of the libraries and APIs that any Java
programmer should learn (java.lang, java.io, java.math, java.net,
java.util, etc...).
Java EE = Enterprise Edition. From Wikipedia:
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. In other words, if your application demands a very
large scale, distributed system, then you should consider using Java
EE. Built on top of Java SE, it provides libraries for database access
(JDBC, JPA), remote method invocation (RMI), messaging (JMS), web
services, XML processing, and defines standard APIs for Enterprise
JavaBeans, servlets, portlets, Java Server Pages, etc...
Source: Difference between Java SE/EE/ME?
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.
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.
Please confirm the above statement?
I need to know what they are referring to when they mention JDK.
Java Development Kit is the way we usually refer to a set of tools to create Java applications, including the Java Compiler (to translate your JAVA Source classes into .class bytecode files), the Java Virtual Machine (to execute those .class files), the JAR tool to ZIP applications (or extract them) and so on.
The Java Standard Edition usually refers to the core classes that make up the foundation of most Java programs, such as the Collections API (List, Map, Set, etc.), the classes in the java.lang package, the I/O classes, the Threading API, the RMI packages and classes, the i18n (internationalization) classes, the JDBC API and, of course, the AWT and Swing classes to create desktop applications and applets. These APIs are the very foundation of all other programs you can write 'in Java', such as the IntelliJ IDEA IDE, Servlet Containers (like Tomcat), RDBMS (like Apache Derby) or custom standalone clients such as SQuirreL. These classes you get as part of the JDK (just crack-open the src.zip file right under your JDK folder and see what you find there :) )
Java EE is a specification with sub-specifications that, as a whole, define a set of services that implementations (such as GlassFish or IBM's WebSphere) should provide in order to be in compliance with the spec. These 'implementations' are the so-called Java EE Containers. When you hear people saying that 'GlassFish is a Java EE 1.6 implementation' they mean that GlassFish (a Java program written using the Java Standard Edition classes) provides all the features that the Java EE 6 family of specifications define.
The Java EE specifications are supposed to cover a particular need within the field of 'enterprise' application development, such as the Servlet specification for HTTP request-response processing, the EJB specification for transaction management and component life-cycle management, the JMS specification for messaging services and so on. The Java EE containers (WebLogic, WebSphere, Tomcat) provide actual implementations of these specifications as classes. In an overly simplified statement, these containers provide the JARs for the Java EE APIs. The classes within these JAR files make use of the Java SE core classes. I think this last sentence makes the connection between Java SE and Java EE.
To wrap this up, I would say that the JDK is just a set of programs you download and execute to create and execute your programs 'written in Java'. If you have a Java program that only makes use of the 'core classes' and requires no 'enterprise services' you execute your Java program on top of the JSE. Finally, if you need to provide some functionality and any of the Java EE specification's implementations cover any of your needs, say you need to process HTTP requests; you create a component as dictated by the spec (a Servlet in this case) and deploy it into your Java EE container -Tomcat, for example-.
Hope this helps
When you download the standard Java development kit, you get the standard edition of Java (Java SE) in a development form (JDK). The Java runtime (JRE) is the same set of libraries etc. without the development tools (compiler etc.)
Java EE is a set of additional APIs/interfaces (and most usually, some implementations of these). These are APIs for web applications, EJBs etc. You can use the JDK to build for this, provided you have the additional APIs and the implementations. Most usually a Java EE application will run in an application or web container.
Note (also) that until very recently, Java SE was known as J2SE, and Java EE was known as J2EE. The situation is confused further by the fact that many people (especially recruiters) confuse J2EE with EJBs (which are only one of the technologies in Java EE).
You're not alone in being confused by this. I regularly encounter experienced professionals who struggle with precisely what these mean, and Sun doesn't help by introducing Java 2 v1.6 (or is it Java 6?), and renaming J2EE to Java EE.
Using the definitions above, you will find a JDK for Java SE (a set of java features) and a JDK for the Java EE (the features in Java SE + some "enterprise" features).
The Java Standard Edition and Java Enterprise Edition are the definition and APIs of the Java language, and the JDK are the tools you need to develop something using those features.
To be more clear
Java SE -- Java Standard Edition, it happens to come in two versions: the JDK and JRE. JDK has the compiler and other tools.
Java EE -- Java Enterprise Edition is simply a standard, and a couple of libraries consisting mostly of just interfaces. While there are 'stand alone' components that can be downloaded for Java EE, alone they're of little value (again, being mostly just interfaces), and are typically bundled with the container you use to deploy or develop Java EE applications on. Plus Java EE comprises as an umbrella of many standards (JMS, JSF, etc. etc.).
In general JDK refers to the Java SE Development Kit. You can also see the abbreviation on the respective download page and not on the one for the Java EE Development Kit or the Java ME Development Kit.
JDK = java development kit.
Java SE = java standard edition (aka JRE)
Java EE = java enterprise edition (aka J2EE)
Update: Sun isn't well known for their clear naming conventions (Java 1.5 and Java 5.0 are the same thing, for example).
It boils down to this:
If you want to run java applications, go to http://www.java.com and click on the Download button.
If you want to write java applications, go to http://developer.sun.com and wade through it until you find a download that's about 80 MB called "JDK". There are several different versions of the JDK based on what kinds of stuff you're developing (web applications, console applications, etc.).
JDK = Java Development Kit
Java SE = Java Standard Edition
Java EE = Java Enterprise Edition
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 ,,,,