Related
I've noticed recently about some APIs that are supposed to be part of Java EE, but seem to be implemented in Java SE. For example, there's JAX-WS, which is a Java EE API, but can be used completely in a Java SE project.
Is there anything I'm getting wrong? There are some APIs from Java EE implemented in Java SE out of the box? Where can I find information about what JEE APIs are available in JSE as well?
Java SE APIs are basically the Java Standard Library. There's a nice diagram on the Java Platform Docs
And here is a list of the "Base Libraries": https://docs.oracle.com/javase/8/docs/technotes/guides/index.html#langutil
which includes java.lang, math, collections, reflection, concurrency, logging, preferences, io, net .... (notice that many of these are not even widely used by the Java community, like logging - where slf4j-api is the de-factor standard).
Then, there's also the "Integration Libraries" that include things like JDBC (Database Access) and JNDI (things like LDAP), and "User Interface Libraries" (used to be Swing and JavaFX, but now it's back to only Swing).
The Java EE APIs include many other things, like email and JAX-RS as you mention, which extend the Java libraries and in theory, should interact and work on top of the SE APIs, providing a comprehensive whole suited for enterprisey development.
They are not implemented by the JavaSE runtime!
However, each JavaEE API can be implemented independently by independent organisations (or anyone that has enough spare time to spend on the effort) and be used from a mostly Java SE application on their own. This is why there's lots of Servlet containers (Tomcat, Jetty, GlassFish and many others) available which implement the Servlet API and not much else!
It should be noted that quite recently, JavaEE has become officially the JakartaEE project. There's a searchable list of projects here.
I'd also like to mention there's another big set of APIs that were developed in parallel with JavaEE in the OSGi world, by the OSGi Alliance, that focussed on modularity of dynamic Java applications.
Finally, a competing framework, Spring is quite dominant in the Java world (and has actually influenced a lot the development of JavaEE itself), and even today, with beginner-friendly projects like Spring Boot is probably more popular than JavaEE itself!
Myself, I like to stick with only Java SE, a few EE APIs like Servlets and JDBC (EDIT: jdbc is in the standard lib!) for essentials, and community driven projects (see for example Micronaut and Vert.x) which are really cool stuff and are not based on any standards at all!
In summary, the Java world is big and there's a lot of variety! JavaEE is but a small part of it.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Java EE has this "mysterious shroud" around it for younger Java developers - one that I've been trying to lift myself for quite a while with little success.
Confusion arises from:
Java EE seems to be both a library and a platform - there are multiple ways to "get" the Java EE library, typically from something like Oracle's Java EE SDK download. However, the Java EE library will not work, nor compile unless if your code is being run on or has access to a Java EE application server (such as JBoss, GlassFish, Tomcat, etc). Why? Can't the libraries function outside of the application server environment? Why do I need something massive as JBoss just to compile simple code to send an email?
Why are Java EE libraries not "standard" and included in the regular JVM download and/or the SDK?
Why are there so many Java EE offerings when there is really only two main flavors of standard Java (Oracle JVM/SDK | OpenJDK JVM/JDK)?
What can one do with Java EE that they cannot do with standard Java?
What can one do with standard Java that they cannot do with Java EE?
When does a developer decide they "need" Java EE?
When does a developer decide they do not need Java EE?
Why is Java EE library version not in sync with standard Java library releases (Java EE 6 vs. Java 7)?
Thanks for helping me clear the flog!
Why can't the libraries function outside of the application server environment?
Actually they can. Most of the libraries can be directly used standalone (in Java SE) or included in a .war (practically that's nearly always Tomcat). Some parts of Java EE, like JPA, have explicit sections in their respective specifications that tells how they should work and be used in Java SE.
If anything, it's not so much an application server environment per se that's at stake here, but the presence of all other libraries and the integration code that unites them.
Because of that, annotations will be scanned only once for all your classes instead of every library (EJB, JPA, etc) doing this scanning over and over itself. Also because of that, CDI annotations can be applied to EJB beans and JPA entity managers can be injected into them.
Why do I need something massive as JBoss just to compile simple code to send an email?
There are a few things wrong with this question:
For compiling you only need the API jar, which is below 1MB for the Web Profile, and a little over 1MB for the full profile.
For running you obviously need an implementation, but "massive" is overstating things. The OpenJDK for example is around 75MB and TomEE (a Web Profile implementation containing mail support) is only 25MB. Even GlassFish (a Full Profile implementation) is only 53MB.
Mail works perfectly fine from Java SE (and thus Tomcat) as well using the standalone mail.jar and activation.jar.
Why are Java EE libraries not "standard" and included in the regular JVM download and/or the SDK?
Java EE in a way was one of the first attempts to split up the already massive JDK into chunks that are easier to manage and download. People are already complaining that the graphical classes (AWT, Swing) and Applets are inside the JRE when all they do is run some commands on a headless server. And then you also want to include all the Java EE libraries in the standard JDK?
With the eventual release of modularity support we'll just have a small base JRE with many things separately installable as packages. Perhaps one day many or even all classes that now make up Java EE will be such package as well. Time will tell.
Why are there so many Java EE offerings when there is really only two main flavors of standard Java (Oracle JVM/SDK | OpenJDK JVM/JDK)?
There are more than just two flavors of Java SE. There is at least the IBM JDK, the previous BEA one (JRocket, which is being merged into the Oracle/Sun one because of the acquisition), various other open source implementations and a slew of implementations for embedded use.
The reason behind Java SE and EE being a specification is that many vendors and organizations can implement it and thus it encourages competition and mitigates the risk of vendor lock-in.
It's really no different with C and C++ compilers, where you have many competing offerings as well all adhering to the C++ standard.
Why is Java EE library version not in sync with standard Java library releases (Java EE 6 vs. Java 7)
Java EE builds on Java SE, so it trails behind. The versions do correspond though. Java EE 5 requires Java SE 5. Java EE 6 requires Java SE 6 and so on. It's just that mostly when Java SE X is current, Java EE X-1 is current.
Here are a few quickly composed answers to your questions...
Why can't JavaEE libraries function without an application server?
The services provided by JavaEE (container managed transactions, container managed dependency injection, timer service, etc..) inherently involve JavaEE compliant Application Servers (for example: GlassFish, JBoss, WebSphere, etc...). Therefore the JavaEE libraries serve no purpose without such a container. "Why do I need something as massive as JBoss just to compile simple code to send an email?" You don't. There are ways to send an email without JavaEE... But if you want to do it the JavaEE way, you need a JavaEE container.
Why are JavaEE libraries not included with JavaSE download?
The same reason that many libraries aren't included: it would be overkill. Since you can't even use the JavaEE libraries without an application server, why bother to include them? JavaEE should be downloaded if and when a developer installs an application server and decides to use JavaEE.
Why are there so many JavaEE offerings?
Are there really "so many" JavaEE offerings? If so, please list some of them. More accurately I believe there are multiple implementations of the same APIs.
What can one do with JavaEE that they can't do without standard Java?
Lots. You can't rely on an application server to manage transactions or persistence contexts without JavaEE. You can't allow an application server to manage EJB dependency injection without JavaEE. You can't use an application managed timer service without JavaEE. The answer to this question should make the answer to the first question quite clear... Most of the services provided by JavaEE require a JavaEE container.
What can you do with JavaSE that you can't do with JavaEE?
Um... I don't know.
When does a developer decide they need JavaEE?
This question is completely subjective... But if you need any of the services provided by JavaEE, you start to think about it. If you don't know what JavaEE is... you probably don't need it.
When does a developer decide they do not need JavaEE?
See previous answer.
Why is JavaEE library version not in sync with JavaSE version?
Good question. I won't pretend to know how to answer it... But I would guess the answer is: "because they're not in sync".
At bird's eye view, Java EE is a platform, i.e. something that we can build on.
Taking a more technical perspective, the Java Enterprise Edition standard defines a set of APIs commonly used for building enterprise applications. These APIs are implemented by application servers - and yes, different application servers are at liberty to use different implementations of the Java EE APIs.
However, the java ee library will not work, nor compile unless if your code is being run on or has access to a Java EE application server (such as JBoss, GlassFish, Tomcat, etc).
You compile against the Java EE APIs, so you only need those APIs at compile time. At runtime, you'll also need an implementation of these APIs, i.e. an application server.
Why do I need something massive as JBoss just to compile simple code to send an email?
You don't. However, if you wish to use the Java EE API for sending mail, you will need an implementation of that API at runtime. This can be provided by an application server, or by provided by a stand alone library you add to your classpath.
Why are Java EE libraries not "standard" and included in the regular JVM download and/or the SDK?
Because only the APIs are standardized, not the implementations.
Why are there so many Java EE offerings
Because people disagree on the right way to implement certain features. Because different vendors compete for market share.
What can one do with Java EE that they cannot do with standard Java?
Since Java EE implementations are built with "standard Java": Nothing. However, leveraging the existing libraries can save a great deal of effort if you are solving typical enterprise problems, and using a standardized API can prevent vendor lock-in.
What can one do with standard Java that they cannot do with Java EE?
Nothing, since Java EE includes Java SE.
When does a developer decide they "need" Java EE? When does a developer decide they do not need Java EE?
Generally speaking, the Java EE APIs solve typical, recurring problems in enterprise computing. If you have such problems, it usually makes sense to use the standard solutions - but if you have different problems, different solutions may be called for. For instance, if you need to talk to a relational database, you should consider using JPA. But if you don't need a relational database, JPA won't help you.
What is Java EE?
Let's start from canonicity definition at wiki:
Java Platform, Enterprise Edition or Java EE is Oracle's enterprise
Java computing platform. The platform provides an API and runtime
environment for developing and running enterprise software, including
network and web services, and other large-scale, multi-tiered,
scalable, reliable, and secure network applications.
The main point here is that Java EE is a platform provides an API, not some concrete library.
What for Java EE needed?
The main scope of Java EE is the network based applications, unlike Java SE oriented to the desktop applications development with simple network support. This is the main diference between them.
Scalability, messaging, transactioning, DB support for every application... the need in all of this has increased with the evolution of the network.
Of course a lot of ready solutions which Java SE provides are useful for network development, so Java EE extends Java SE.
Why do we need application servers to run our code?
Why do we need operation systems? Because there are a lot of painful work with hardware we need to do to make even simpliest application. And without OS you need to do it again and again. Oversimplified OS is just a programmatic container, which provides us a global context to run our applications.
And this is what the application servers are. They are allows us to run our applications in their context and provides us a lot of highlevel functionality which is needed for enterprise highloaded network applications. And we are don't want to write our own bicycles to solve this problems, we are want to write code which will satisfy our business needs.
Another example here could be JVM for Java.
Why Java EE doesn't contains onboard app server?
Hard to say for me. I think, it was done for more flexibility. Java EE says what they should do, they decide how to do it.
Why JVM doesn't include Java EE?
Because they directed to different market sectors. Java EE has a bunch of functionality which is doesn't need for usual desktops.
Why are there so many Java EE offerings?
Because Java EE only describes the behaviour. Everybody can implement it.
What can one do with Java EE that they cannot do with Java SE?
To conquer the internet. It's really hard to do with Java SE applets and sockets :)
What can one do with Java SE that they cannot do with Java EE?
As mentioned above Java EE extends Java SE, so with Java EE you should be able to do everything what is available for Java SE.
When does a developer decide they "need" Java EE?
When they need the power of Java EE. All what is mentioned above.
When does a developer decide they do not need Java EE?
When they write a usual console or desktop application.
Why versions of Java SE and Java EE are unsynced?
Java always had troubles with it's technologies naming and versioning. So this situation is not an exception.
Java EE is all about container concept. Container is an execution context within which will run your application and which provide this last a set of services. Each kind of service is defined by a specification named JSR. For example JSR 907, JTA (java transaction Api) which provide a standard way to manage distributed transaction against different resources. There are generally many different implementations for a given JSR, the implementation you will use depends on the container provider, but you don't really mind about that as you are sure the behavior respect the predefined contract : the JSR API. So to take advantage of Java EE, you need to run your application inside a container. The two main ones are EJB and servlet container which are both present on any Java EE certified application server.
The aim of all of this is to defined a standard execution environment to allow to package your application with only the essentials, id.est. your business. It avoids to depend on a unknown and various set of third-party libraries that you would have to package and provide with your app otherwise, and which may be sources of conflict with other apps on the server. In Java EE you know that all standard non functional requirements like security, transaction, scalability, remote invocation, and many more will be provided by the container (factorized for all apps running inside it) and you just have to base your work on its.
Now, this may be a silly question but sometimes the terms Framework and API are used interchangeably. The way I see it is that a Framework is a bigger more generic thing, containing many API's, that could be used for various programming tasks (for example, the .NET Framework.) An API is smaller and more specialized (for example, the Facebook API.) Anyone want to share their insights on the matter?
And take for instance that Microsoft call .NET a Framework whereas Sun calls theirs a Platform ... so could it be also a business/marketing decision as to how call a "collection of libraries."?
Design Patterns provide the following definitions:
toolkits: "often an application will incorporate classes from one or more libraries of predefined classes called toolkits. A toolkit is a set of related and reusable classes designed to provide useful, general-purpose functionality".
frameworks: "a framework is a set of cooperating classes that make up a reusable design for a specific class of software".
The key here is that while toolkits (APIs) can be useful in many domains, frameworks are geared to solve issues for specific classes of problems, that can be customized "by creating application specific subclasses of abstract classes of the framework".
Moreover, and maybe more importantly, "the framework dictates the architecture of your application": Inversion Of Control is one of the characteristics of frameworks (see Martin Fowler on this); instead of having your application call specific APIs to implement a specific behavior, it's the framework that calls your code.
I've always thought the framework was the whole thing, internal code, API's, etc.
While the API is just the bit you use when you want to make use of the framework.
In other words, the .NET framework consists of the .NET libraries, all the languages and so on. The API is just the way you call the functions.
A framework does introduce the notion of inversion of control
(i.e. the overall program's flow of control is not dictated by the caller, but by the framework)
When you are referring to language frameworks (such as Java Framework or .Net Framework), you actually including more than just libraries and their APIs (which would be more limited a Software Framework if those libraries provide an inversion of control).
A Language Framework includes the development and execution environments which will call your code (to compile it or to execute it).
That is why .Net Framework is a "Framework".
Java may refer to its Frameworks (JDK, JRE) as a "Java Platform" in order to emphasize its "platform independent" programming language feature.
From About the Java Technology
A platform is the hardware or software environment in which a program runs. (including Microsoft Windows, Linux, Solaris OS, and Mac OS).
Most platforms can be described as a combination of the operating system and underlying hardware.
The Java platform differs from most other platforms in that it's a software-only platform that runs on top of other hardware-based platforms.
The Java platform has two components:
The Java Virtual Machine
The Java Application Programming Interface (API)
As its name suggests (Application Programming Interface) the API is just the interface of the framework.
From my understanding, an API is basically a way of interfacing with an existing app (like Facebook), whereas a framework is basically a tool for building your own app from the ground up.
Software Framework: Is a re-usable design for a software system (or subsystem). A software framework may include programs, code libraries, a scripting language, other software to help develop and glue together the different components of a software project. Various parts of the framework maybe exposed through an API.
API (Application Programming Interface): Is a set of routines( AKA methods, functions), data structures, object classes, and/or protocols provided by libraries and/or operating system services in order to support the building of applications.
More details along with other
Link to this particular topic is
http://aprogrammersday.blogspot.com/2009/02/difference-between-framework-and-api.html
API (application programming interface): like his name means, is an interface for externe programs to interact with your inter program or library without having direct access. for example, the google map API and Facebook API give you the interface to interact with their program and library without having direct access.
In the other hand:
Framework : is a collection of libraries that can help you to build an application. you can imagine the framework as a "skeleton" where the application defines the "meat", so you can't take a human skeleton to build a hors body, so you have to choose the good framework before start programing. this is why we said : You call Library. Framework calls you.
I'd like to think that an API is a subset of a framework
In my experience, a framework often includes two things (at least) that an simple API doesn't:
Extensibility: you can compose or subclass framework components to extend or customize its functionality.
Tools for code-generation, administration, or diagnostic tasks related to application development.
A framework is basically a collection of classes that abstract away the development process and promote code reuse for example you might have database, session, and pagination classes that are independent of the application you are building. But an API is source code interface that allows two or more components of different systems to interact, for example adding the Google Maps API to your website, you and Google are two different systems, Google coded the underlying interface for incorporating its products to your website/application. All in all just go with a framework work when building your system, then develop an API when you offer extensions for other people like Facebook and Google.
I know this is an old thread and that it really doesn't matter, but I just can't help but to chime in with my own views. An API (e.g. device driver API, Windows API, etc.) provides the basic and essential functions for a platform such that a programmer can exercise his creativity and do something with the platform - yes, including using it to build a framework. A framework is higher level in function and abstraction, and provide a set of reusable and convenient functions/classes/conventions to facilitate the development of applications that share certain common attributes (e.g. iPad apps, web services, etc.)
A framework implements a very important option called IoC (Inversion of Control) which means in a nutshell that your code has, no more, things in hand.
While in an API your code calls other codes (libraries), when you use a specific framework, it's the framework who is in control of the application flows.
This question already has answers here:
Difference between Java SE/EE/ME?
(14 answers)
Closed 7 years ago.
What's the main difference between Java SE and Java EE?
Java SE (formerly J2SE) is the basic Java environment. In Java SE, you make all the "standards" programs with Java, using the API described here. You only need a JVM to use Java SE.
Java EE (formerly J2EE) is the enterprise edition of Java. With it, you make websites, Java Beans, and more powerful server applications. Besides the JVM, you need an application server Java EE-compatible, like Glassfish, JBoss, and others.
Java SE stands for Java standard edition and is normally for developing desktop applications, forms the core/base API.
Java EE stands for Java enterprise edition for applications which run on servers, for example web sites.
Java ME stands for Java micro edition for applications which run on resource constrained devices (small scale devices) like cell phones, for example games.
http://www.dreamincode.net/forums/topic/99678-j2se-vs-j2ee-what-are-main-differences/
As far as the language goes it is not as though java changes. Java EE has access to all of the SE libraries. However EE adds a set of libraries for dealing with enterprise applications.
Java EE is more like a "platform" or an general area of development.
In Java SE you write applications that run as standalone java programs or as Applets. In JavaEE you can still do this, but you can also write applications that run inside of a Java EE container. The container can do a great amount of management for you such as scaling an application across threads, providing resource pools, and management features.
Java EE has a web framework based upon Servlets. It has JSP (Java Server Pages) which is a templating language that compiles from JSP to a Java servlet where it can be run by the container.
So Java EE is more or less Java SE + Enterprise platform technologies.
Java EE is far more than just a couple of extra libraries (that is what I thought when I first looked at it) since there are a ton of frameworks and technologies built upon the Java EE specifications.
But it all boils down to just plain old java.
Java SE refers to the standard version of Java and its libraries. Java EE refers to the Enterprise edition of Java which is used to deploy web applications.
Java EE is enterprise edition.
Includes jsp, servlets, beans, and some other stuff for server programming.
Java SE is standard edition. This is plain old Java. Includes GUI stuff.
First, J2SE and J2EE have been renamed. They're now Java SE and Java EE.
Essentially, Java SE is your standard Java designed for end-users. That's what you'd develop to for desktop applications. Java EE is the enterprise edition, designed for server programming, such as SOA and web applications.
Best description i've encounter so far is available on Oracle website.
Java SE's API provides the core functionality of the Java programming language. It defines everything from the basic types and objects of the Java programming language to high-level classes that are used for networking, security, database access, graphical user interface (GUI) development, and XML parsing.
The Java EE platform is built on top of the Java SE platform. The Java EE platform provides an API and runtime environment for developing and running large-scale, multi-tiered, scalable, reliable, and secure network applications.
If you consider developing application using for example Spring Framework you will use both API's and would have to learn key concept of JavaServer Pages and related technologies like for ex.: JSP, JPA, JDBC, Dependency Injection etc.
Java SE contains all the base packages. Some of the base packages are written in Java and some are written in C/C++. The base packages are the fastest because there are no additional layers on top of their core functionality.
Java EE is a set of specifications and the respective implementations are all built using Java SE base packages which happen to already contain everything required for any application. For example, for a web application, here is a Java SE Web Server and a Java SE Database.
Java SE 9/10 is expected to contain better support for native in order to improve the inherent performance issues it has from being an interpreted language. Using the enormous Java EE implementations implies a willingness to sacrifice performance, scalability and a lot of time and money for education and updates, in exchange for project standardization.
JavaSE and JavaEE both are computing platform which allows the developed software to run.
There are three main computing platform released by Sun Microsystems, which was eventually taken over by the Oracle Corporation. The computing platforms are all based on the Java programming language. These computing platforms are:
Java SE, i.e. Java Standard Edition. It is normally used for
developing desktop applications. It forms the core/base API.
Java EE, i.e. Java Enterprise Edition. This was originally known as
Java 2 Platform, Enterprise Edition or J2EE. The name was eventually
changed to Java Platform, Enterprise Edition or Java EE in version 5.
Java EE is mainly used for applications which run on servers, such as
web sites.
Java ME, i.e. Java Micro Edition. It is mainly used for applications
which run on resource constrained devices (small scale devices) like
cell phones, most commonly games.
In Java SE you need software to run the program like if you have developed a desktop application and if you want to share the application with other machines all the machines have to install the software for running the application. But in Java EE there is no software needed to install in all the machines. Java EE has the forward capabilities. This is only one simple example. There are lots of differences.
The biggest difference are the enterprise services (hence the ee) such as an application server supporting EJBs etc.
Why Java is still used in web development? I'm just curious..
There are a number of reasons:
1. It is by no means a dead language. There are thousands of Java developers out there.
2. Many available Java developers means that it relatively easy to find maintenance programmers if necessary.
3. The Java / J2EE architecture is robust and reasonably elegant. It makes it possible to architect well built applications.
4. The free tools available for it are enterprise ready. For example, Apache / Tomcat / JBoss are a solid foundation to build a web-app from.
5. Excellent support for developers. Eclipse is one of the best developer platforms available. Ant and Maven support for Java is excellent.
6. There is a good availability of third-party (and open-source) libraries and Eclipse plug-ins for most of the additional functionality that might be needed but does not come in the core libraries.
7. There is also great support tools from commercial vendors: ORacle; IBM / Rational; etc.
8. Updated versions with newer language constructs are constantly being developed.
In short, it is a good tool for the job. It is compares favourably to other development platforms (.Net, Ruby, etc), and perhaps is better than some.
Simple. It's a cross platform environment, that is clearly defined, and controlled. Sure, Sun has a big deal of say in what is available in the Java environment, but there is plenty of 3rd party support and development in the Java environment.
Yes, Java applications start up slightly slower than Native applications, but take a look at VUZE... Once it's started, it's nearly native speed (or at least it was when I was using it). With the JIT (Just in Time) compilers, code caching, and other features, there isn't much of a reason that there would be a major speed penalty...
One big reason I think is because it's platform independent meaning they can easily run on all operating systems as long as you have the Java Runtime Environment installed. This could allow you to, for example, compile code in Windows and deploy on Unix.
I would also add that while this is only a con against .Net, your application server doesn't have to be Windows so it is cheaper to throw more hardware at it.
For the same reason as why COBOL and FORTRAN still exist. Because the language has proven itself to be robust and reliable.
Compare it with cars. Some people want the latest models because it has more power, better speed, improved features and whatever more. Others will just use a reliable car that's made to last for many years without much need for additional maintenance. Some buy a new car every 3 years, others will use their cars for half a century or more.
When talking about Java & the web, people seem to happily mix things by concentrating on Java applications deployed with Web Start (or even Applets), and forgetting that Java is a common language for implementing plain old dynamic web sites (or web applications). The latter is especially true for larger, more "enterprisey" systems. Even if on the desktop Java never really took off, on the server side it certainly did.
Without going into much detail, a couple of reasons why Java is used for creating web sites / applications:
It's a tried and true approach for building large-scale web apps. Either using just the basic (Java EE) technologies of Servlets and JSP, or newer frameworks built on top of those, such as JSF, Wicket or Google Web Toolkit. (Just one example of high scalability: Gmail is implemented in Java, using Google Web Toolkit.)
A mind-boggling amount of Java libraries exist, for all kinds of tasks — both open-source and commercial ones. If you need some in the backend of your app it may make a lot of sense to do the whole app using the same technology.
There are a lot of skilled Java developers out there — something that may affect tech desicions when launching (larger) projects
When creating a web interface for, or integrating into, an existing Java enterprise system (which are common) it may be beneficial to use the same language
Edit: I also agree with Doug about the tools and developer support. For example, IntelliJ IDEA may well be the most advanced IDE for any language (and I've heard this also from people who've used Eclipse and Visual Studio extensively... ;-) )
It's ubiquitous. The tools are great across the board. It's powerful. The community is huge. There is an amazing amount of available libraries / products / toolkits / frameworks. The JVM is great.
You can build cathedrals with this language. Those tend to stand for centuries.
Since Java doesn't run on the iPad, doesn't that hurt Java web development? Developing a web application that supports desktop and mobile is a possible path, but if your site uses Java or Flash, you have eliminated that opportunity.
We have a web application that is for both desktop and mobile (supports swiping, zooming, and such using jQuery). We decided against Java, Flash, and Silverlight because they do not work with iPad. The iPad is a growing base and web applications will have to keep up to support it.
It will be interesting to see how this affects web development with Java... time will tell.