OK stupid question but...
I realize that literally it translates to java 2 enterprise edition. What I'm asking is what does this really mean? when a company requires j2ee experience what are they really asking for? experience with ejb's? experience with java web apps?
I suspect that this means something different to different people and the definition is subjective, so please try to upvote rather than reposting something already in another answer.
There are 2 version of the Java Environments, J2EE and Se. SE is the standard edition, which includes all the basic classes that you would need to write single user applications. While the Enterprise Edition is set up for multi-tiered enterprise applications, or possible distributed applications. If you'd be using app servers, like tomcat or websphere, you'd want to use the J2EE, with the extra classes for n-tier support.
Yes, experience with EJB, Web Apps ( servlest and JSP ), transactions, webservices, management, and application servers.
It also means, experience with "enteprise" level application, as opposed to desktop applications.
In many situations the enterprise applications needs to connect to with a number of legacy systems, they are not only "web pages", and with the features availalble on the "edition" of java that kind of connectivity can be solved.
It's meaning changes all the time. It used to mean Servlets and JSP and EJBs. Now-a-days it probably means Spring and Hibernate etc.
Really what they are looking for is experience and understanding of the Java ecosystem, Servlet containers, JMS, JMX, Hibernate etc. and how they all fit together.
Testing and source control would be an important skills too.
J2EE is actually a collection of technologies and APIs for the Java platform designed to support "Enterprise" Applications which can generally be classed as large-scale, distributed, transactional and highly-available applications designed to support mission-critical business requirements.
In terms of what an employee is looking for in specific techs, it is quite hard to say, because the playing field has kept changing over he last 5 years. It really is about the class of problems that are being solved more than anything else. Transactions and distribution are key.
J2EE traditionally referred to products and standards released by Sun. For example if you were developing a standard J2EE web application, you would be using EJBs, Java Server Faces, and running in an application server that supports the J2EE standard. However since there is such a huge open source plethora of libraries and products that do the same jobs as well as (and many will argue better) then these Sun offerings, the day to day meaning of J2EE has migrated into referring to these as well (For instance a Spring/Tomcat/Hibernate solution) in many minds.
This is a great book in my opinion that discusses the 'open source' approach to J2EE http://www.theserverside.com/tt/articles/article.tss?l=J2EEWithoutEJB_BookReview
I would say that J2EE experience = in-depth experience with a few J2EE technologies, general knowledge about most J2EE technologies, and general experience with enterprise software in general.
J2EE is a collection of specifications for developing and deploying enterprise applications.
In general, enterprise applications refer to software hosted on servers that provide the applications that support the enterprise.
The specifications (defined by Sun) describe services, application programming interfaces (APIs), and protocols.
The 13 core technologies that make up J2EE are: JDBC, JNDI, EJBs, RMI, JSP, Java servlets, XML, JMS, Java IDL, JTS, JTA, JavaMail, and JAF.
The J2EE product provider is typically an application-server, web-server, or database-system vendor who provides classes that implement the interfaces defined in the specifications. These vendors compete on implementations of the J2EE specifications.
When a company requires J2EE experience what are they really asking for is experience using the technologies that make up J2EE. Frequently, a company will only be using a subset of the J2EE technologies.
J(2)EE, strictly speaking, is a set of APIs (as the current top answer has it) which enable a programmer to build distributed, transactional systems. The idea was to abstract away the complicated distributed, transactional bits (which would be implemented by a Container such as WebSphere or Weblogic), leaving the programmer to develop business logic free from worries about storage mechanisms and synchronization.
In reality, it was a cobbled-together, design-by-committee mish-mash, which was pushed pretty much for the benefit of vendors like IBM, Oracle and BEA so they could sell ridicously over-complicated, over-engineered, over-useless products. Which didn't have the most basic features (such as scheduling)!
J2EE was a marketing construct.