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.
Related
If I'm simply running a prebuilt Java EE (server) application, does it run on Java SE's JRE, the one found here?: http://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html
You have asked two different questions:
Does Java EE run on Java SE's JRE?
Assuming that you mean an implementation of the Java EE specifications (e.g. Glassfish, JBoss, Glassfish, WebSphere, etc), then the answer is Yes.
All of these will run on a Java SE JRE. Indeed, you typically need to download a JRE separately from the Java EE implementation that you are using.
If I'm simply running a prebuilt Java EE (server) application, does it run on Java SE's JRE?
The answer to that is No. The web application needs a web container; e.g. Glassfish, JBoss, Glassfish, WebSphere, etc.
The webapp runs in a Java EE web container and the Java EE web container runs on a JRE.
Hopefully, the above will help you understand why the two questions you asked are different.
It should also be said that not all Java EE implementations are "equal". Some of them (for example Tomcat) only implement a subset of the Java EE specifications. However, a typical web application only requires a subset of Java EE; e.g. the Servlet, JSP and JSTL frameworks / implementations.
The question is, why would you try to run a JavaEE application without J2EE-Server.
If you want to do module tests, a subset of the functionality is sometimes enough to run limited parts of the application including h2-database access, message queuing in memory, asynchronous and timer-simulation, resource-injection ... together with a JUnit-Testrunner.
look for ejb-cdi-unit
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.
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 have decided to learn another language and am in the picking phase.
Currently looking into Java and C#, but leaning towards Java because it is cross-platform. I will be mostly building web based apps, but the variety of Java editions scares me. Java EE, SE, ME, FX, what are they differences? Are there any advantages of using one to another?
Okay, FX is for desktops, ME for mobile, SE and EE are the same, but one is for "business" the other is not. So, if I learn SE for example, what would it take to switch to EE? Or FX? My problem is that I can't really understand why SE, EE and FX are separate products? They both run same JVM, and both can do the same resulting apps. Why they are separated then?
Think of them a bit like this:
ME ~= Compact framework
SE ~= .NET client profile
EE ~= full .NET framework (and some extra bits :)
FX ~= Silverlight
It's not an exact comparison, but it's a close enough start...
It is not so devastating.
Java SE is the standard for normal applications.
Java ME is for mobile telephones, a subset without floating point for instance.
Java EE is an addition for Java SE for web applications and web servers.
Java FX is a flash player alternative, but now with java bindings/integration.
Hence Java SE forms the basics. Java EE is for web applications.
In future java will get a modular system, and the distinction will be just on library level.
When you say editor, i think you mean IDE(Integrated Development Environment).
The reason why Java has so many editors and C# doesn't, is because Java is opensource, while C# is not. So the only real good IDE you are going to find out there for C# is called "visual studio"(It is not free)
I would highly recommend you to go for java, because almost all of the tools are free to use, and even the application servers where you deploy your apps.
Don't be affraid of the java editions, if you would like to build web apps, you will need to go for JavaEE(Enterprise Edition).
Anyway this is what each of them does:
SE(Standard Edition): It contains the most basic libraries, often used in desktop apps, but it is part of the Enterprise Edition too.
EE(Enterprise Edition): Used for enterprise apps(not just web apps), so that means distributed programming, from web apps, desktop to web services...
ME(Micro Edition): Is meant for mobile technologies, not just phones, also vending machines, smart tvs, missile guidance... ;)
FX: Is a rich development platform for developing powerful clients in an easy way.
Regarding to your question, the differences between EE and SE, i already answered, in other words:
EE is an extension of SE, that includes EE and allows you to program enterprise apps.
So if you want to program in EE, you need to have SE installed(Just think about it as a system requirement).
I don't really understand what do you mean by bussiness. What i can tell you is that the Enterprise Edition, has in its libraries integrated a tool for developing bussiness components, called EJB(Enterprise Java Beans).
The reason why EE, SE and FX are separet products is because a separation of concerns is needed.
Example: Maybe you create a desktop app that does not need at all to communicate via internet. Why would you have in it enterprise libraries for distributed programming?
Whit all respects, but the last question is a bit of no sense.
The different versions (SE, EE, ME and FX) are all just different APIs that sit on top of the JVM (you can find full descriptions here: Your First Cup). They are not different languages so there's no new syntax to learn switching between them, just different API calls.
Personally I prefers C# for developing web apps because of it's integration with ASP.NET and the MVC frameworks.
See the description here Java perspective
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).