Zacznijmy od zmiany filozofii patrzenia na samą technologię Java EE. Dotychczas była ona traktowana jako sztywny zestaw technologii, z których każda miała swoje miejsce i powinna być użyta w określonym celu. Na szczęście, ze względu na elastyczność Java EE, nie było problemów z tym, żeby posługiwać się tylko wybranymi elementami JEE, albo używać alternatywnych rozwiązań. Programiści nagminnie wybierali na przykład Hibernate zamiast komponentów encyjnych EJB albo używali wyłącznie technologii webowych SUN-a plus Spring Framework, lub w ogóle stosowali jeden z wielu dostępnych szkieletów aplikacyjnych (począwszy od Struts, a kończąc na JBoss Seam).

Przede wszystkim wprowadzono możliwość definiowania profili serwerów aplikacyjnych. Dotychczas serwer mógł uzyskać certyfikację wyłącznie wtedy, gdy implementował wszystkie technologie Java EE, w rezultacie takie popularne serwety aplikacji WWW jak Jetty czy Tomcat nie istniały z punktu widzenia Java EE. Profile serwerów definiują zestawy technologii, które muszą wejść w skład profilu, by być uznane za zgodne z nim. Obecnie jedynym, bo najbardziej potrzebnym, jest profil dla aplikacji WWW – Web Profile. Z czasem można sobie wyobrazić powstawanie profili powiązanych z jakimiś bardziej specyficznymi typami aplikacji, na przykład telekomunikacyjnych, bankowych, itp.

Kolejna zmiana to ukłon w stronę szkieletów aplikacyjnych. Dotychczas użycie szkieletu pociągało za sobą konieczność samodzielnego skonfigurowania aplikacji do pracy ze szkieletem. Zazwyczaj polegało to na wprowadzeniu zmian do pliku konfiguracyjnego aplikacji webowej web.xml. Obecnie każdy szkielet aplikacyjny może zawierać jako swoją część potrzebny mu fragment pliku web.xml (web fragments).