We wszystkich wątkach typu JEE vs Spring powtarzane jest, że JEE to standard, standaryzacja itp. Czyli mam rozumieć, że Spring nie jest tym "standardem"?
Dlaczego Spring nie jest standardem?
0
0
Java (także EE) leży w rękach Oracle.
Spring to framework od Pivotal Software, Inc.
0
Dlaczego Spring nie jest standardem?
Co to jest standard ? zdefiniuj
0
Dobrze, że mamy JEE i Springa, dobrze, że mamy taką 'konkurencję' .
0
maryiusz napisał(a):
Dlaczego Spring nie jest standardem?
Co to jest standard ? zdefiniuj
Właśnie to ja chce się w tym poście dowiedzieć co jest "standardem" a co nie. Określenie "standard" pochodzi z tego forum. Mogę tu przytoczyć mnóstwo wątków.
Dowiedzieć się co to znaczy, że JEE jest standardem, a Spring nie.
0
Bo JEE należy do specyfikacji API dla języka Java i jest rozwijane razem z nim. Spring to po prostu pewien framework, jak wiele innych.
To trochę jakbyś chcia porównywać klasę String z java.lang z klasą MyCoolString z jakiejś zewnętrznej biblioteki.
Niemniej JEE jest rozwijane trochę "oddolnie" tzn wprowadza się do niego elementy oparte o popularne frameworki. JPA powstało na bazie Hibenate (i kilku innych podobnych rozwiązań), tak samo CDI było częściowo wzorowane na Spring DI.
Fakt że Spring jest niezależnym frameworkiem pozwala mu rozwijać się szybciej.
0
Inaczej:
Oracle stworzyło Java EE, jej specyfikacja (JPA EJB JMS JMX...) mówią jak powinno wyglądać API/interfejsy i dopiero serwery jak Glassfish Tomcat posiadają ich implementację według tej specyfikacji, nie mogą one działać bez tych kontenerów, ale dzięki specyfikacji możemy przenosić nasze programy między tymi serwerami, bo te serwery widzą tylko API i wywołują swoje implementacje według tych interfejsów.
Pivotal twórca Spring'a nie będzie mówiła przecież programistom jak mają tworzyć technologię którą wymyślili, więc sami tworzą jej implementacje i ci ją dostarczają
0
A to przykład, wyobraź sobie, że Glassfish tworzy sobie taki interfejs dla JMS:
public interface JMS {
public void metoda1();
}
A JBoss:
public interface JMS {
public String A();
public int B();
}
Są to dwa różne interfejsy więc Oracle tworzy swój interfejs i narzuca użycie go glassfish i jbossowi, jeżeli mają te same interfejsy nie ważne jak wygląda ich implementacja będzie to zazwyczaj działać
0
Filozofia JEE to standaryzacje tego co już jest (wychodzi to raz lepej, raz gorzej). W springu jest znacznie więcej opcji jak w JEE, jest też więcej innowacyjności. JEE nie ma być innowacyjne. Ma być przyjazne również programistom za 10 lat bez konieczności uczenia się zbyt wielu nowych rzeczy. Udało sie to np. w EJB między 3.0, a 3.2 nie ma aż tak dużych różnic. Oczywiście serwery aplikacyjne oferują funkcje, których nie ma ani w Springu ani w JEE. Np. taki WebLogic integruje masę własnościowego middleware od Oracle.
0
Może JEE jest "standardem" ale i tak Spring się mocno wybił. Ja szukam pracy głównie po tym czy jest Spring czy JEE
0
scibi92 napisał(a):
Może JEE jest "standardem" ale i tak Spring się mocno wybił. Ja szukam pracy głównie po tym czy jest Spring czy JEE
Żeby jeszcze w ogłoszeniach wyraźnie rozróżniano JEE i Springa to byłoby fajnie. A tak to jest: wymagana JavaEE 8 w szczególności Spring i Hibernate :)
1
Krzywy Mleczarz napisał(a):
Inaczej:
Oracle stworzyło Java EE (...)
To był Sun :)
3
To jest zaszłość historyczna. Specyfikacja J2EE/JEE są znacznie starsze niż Spring. Ich pierwotna forma od strony prawnej i biznesowej była oparta o sprzedaż, bardzo drogich, licencji i certyfikatów zgodności. Po pewnym czasie Sun Microsystem odszedł od tego modelu na rzecz otwarcia standardu. Jednak poczynione szkody w architekturze były bardzo duże. Mniej więcej w 2002-2003 roku pojawiła się pierwsza testowa wersja Springa, która była próbą implementacji wzorca IoC. W 2004 pojawiła się wersja 1.0... ciekawostka – pierwsza wersja springa „ważyła” około 480KB. Była to też próba stworzenia narzędzia, które będzie lepiej pasowało do małych projektów, które nie wykorzystywały pełnego stosu EE. BTW, twórca Springa Rod Johnson był współwinny części specyfikacji J2EE :)
Następnym krokiem było EJB 3.0, które inspirowało się Springiem i Hibernatem. Jednocześnie nie zrywało z architekturą EE. Dlaczego? Przyzwyczajenie :) Później pojawiły się standardy JSR-330 (DI) i JSR-220 (JPA 1.0), które były już mocno wzorowane na hibernate i spring. A potem Spring uzyskał zgodność z JSRem i dziś jest jedną z implementacji standardu.
0
Koziołek napisał(a):
(...)
Następnym krokiem było EJB 3.0, które inspirowało się Springiem i Hibernatem. Jednocześnie nie zrywało z architekturą EE. Dlaczego? Przyzwyczajenie :) Później pojawiły się standardy JSR-330 (DI) i JSR-220 (JPA 1.0), które były już mocno wzorowane na hibernate i spring. A potem Spring uzyskał zgodność z JSRem i dziś jest jedną z implementacji standardu.
Może nie tyle przyzwyczajenie co JEE stara się być bardzo kompatybilna wstecznie (trochę za bardzo IMO). Natomiast to co chciałem zaznaczyć to że JSR330 to "Dependency Injection for Java", specyfikacja bazowa dla "Contexts and Dependency Injection" ( 1.0-JSR299 i 1.1-JSR346).
0
JavaEE to nie standard, to raczej Standard_de_facto
Chyba dopóki są firmy którym zależy na certyfikacji swoich serwerów, to ma to sens.
Standardy (JSRy) powstają w procesie nazwanym Java_Community_Process. Samo JCP ma również swój własny standard/JSR, np. Java Community Process 2.6 -JSR215. Ostateczne zatwierdzenie JSRa należy do Executive Committee.
Ciekawostką jest, że Apache które jako jedne z niewielu ma swoje implementacje Java-Enterprajsowych JSRów, np. Apache MyFaces (JSF), OpanJPA, BVal (Bean validation), OpenWebBeans (CDI), zrezygnowało z członkostwa w JSP Executive Committee :c
JSRów jest znacznie więcej niż te które wchodzą w skład SE/EE.
JavaEE sama w sobie też jest "standardem"- ma swoje JSR, np. JEE6(JSR316), JEE7(JSR342).
JSR nie może "zaistnieć" bez referencyjnej implementacji, a specyfikacja JEE nie może istnieć bez referencyjnego serwera aplikacyjnego który ją implementuje- na to akurat nie mam teraz linka, ale gdzieś tak przeczytałem :p Zgodność implementacji ze specyfikacją weryfikuje "Technology Compatibility Kit", który również jest wymagany dla każdego JSRa.