Jak to jest z programami napisanymi pod starsze wersje Javy

Witajcie.
Spodobał mi się język programowania Java i mam chęć na początek nauczyć się w nim podstaw programowania.
Tylko mam takie pytanie. Powiedzmy zacznę się uczyć Javy w wersji 7. To gdy wyjdzie wersja 8 i zainstaluje nową wersję wirtualnej maszyny Javy to moje wcześniejsze aplikacje będą na niej działać?

Uogólniając pytanie: Czy programy napisane pod starszą wersję Javy będą działać na najnowszej wirtualnej maszynie Javy w wersji 8?

A jeżeli odpowiedź brzmi "nie" to czy jest sens zaczynać naukę Javy w wersji 7 gdy zaraz jak czytałem wejdzie wersja 8?

Mam nadzieję, że nie odeślecie mnie do Wszechwiedzącego Wujka Google jeśli sam powinienem już na wstępie umieć odpwiedzeć na to pytanie.
Zadałem je dlatego, że wyczytałem na stronie poświęconej językowi Java, że warto wybrać tą technologię bo jest duża społeczność, która przychylnie patrzy na nowicjuszy i zawsze znajdzie się ktoś kto udzieli sensownej odpowiedzi albo wskaże źródło gdzie szukać i nie będzie to tylko adres szukajki od Google. I to stwierdzenie, choć jeszcze nie wiem czy prawdziwe, ośmieliło mnie do zadania tego pytania.

Pozdrawiam

nowicjusz_javy napisał(a):

To gdy wyjdzie wersja 8

yhy... czyli nie zaznałeś się nawet z historią języka

Będą działać aplikacje napisane w 7 na 8. Można się domyślać że nawet gdyby nie miały działać to zmiany do wprowadzenia będą tak małe że nie ma co się obawiać. Tak było z 6 na 7- bardziej polegało to na zaleceniach z czego powinno się korzystać a z czego nie, co było używane w starszej wersji. W tym zalecenia do wprowadzenia poprawek dla optymalizacji.

Java stara sie być wstecznie kompatybilna więc jak nie będziesz korzystać namiętnie z rzeczy @deprecated i nie będziesz czytać kursu dla javy < 1.5 to powinieneś być bezpieczny.

kę napisał(a):

yhy... czyli nie zaznałeś się nawet z historią języka

Masz rację. Bo jak donosi serwis [url=http://www.dobreprogramy.pl/Java-8-debiutuje-duzy-krok-w-strone-programowania-funkcyjnego-ale-wciaz-brak-modularnosci,News,53038.html]dobreprogramy.pl[/url] Java 8 już jest. Jednak książek do niej jak na razie na polskim rynku jeszcze nie ma, a większość materiałów dotyczy starszych wersji.
Dlatego myślę, że moje pytanie było uzasadnione, bynajmniej według mnie :) A chęć nauki Javy naszła mnie jeszcze przed premierą 8 ;) jakieś dwa miesiące temu i dopiero dziś powróciła.

[b]@Kandif, Shalom[/b] serdecznie dziękuję za rzeczowe odpowiedzi i wyrozumienie. Zatem przystąpię do nauki podstaw programowania w tym języku. Gdyby nie ta kompatybilność pewnie wybrałbym język Ruby. Jednak wsteczna zgodność i duża ilość dostępnych materiałow zdecydowały o wygranej Javy.
I dziękuję za bardzo szybkie odpowiedzi.

1. kompatybilność wsteczna jest.
2. Kompilator nie potrafi zweryfikować kompatybilności w zakresie metod tzn. jeżeli w javie 8 doszła metoda stream w interfejsie Collection to nawet po ustawieniu odpowiednich flag by kod skompilować zgodnie ze starszą wersją kompilator nie będzie informował iż w starszej wersji biblioteki standardowej nie ma tej metody w interfejsie.

Zatem jeżeli chcesz się uczyć to zainstaluj javę 8. Nie zaszkodzi. Jeżeli chcesz pracować to używaj javy 7, bo ta jest jeszcze popularniejsza.

Czasami programy są pisane wprost w taki sposób, że zależą od szczegółów implementacyjnych lub od rzeczy które są wprost określone jako te które mogą się zmienić. A zmienić się może np format bajtkodu, tzn mogą dojść nowe instrukcje czy konstrukcje. Wtedy biblioteki mielące kod się wysypują i ma się wrażenie, że nowa Java nie jest kompatybilna ze starą Javą. Szczegółem implementacyjnym jest chyba np kolejność metod zwracanych przez refleksję - w nowej Javie jest chyba losowo, a w starych nie i niektóre programy oczekiwały nielosowej kolejności.

Czasami może być też tak że starsze wersje Javy pozwalały na błędy, a nowsze już nie, np: http://stackoverflow.com/questions/9486605/comparison-method-violates-its-general-contract-in-java-7
Podobnie jest w przypadku np Windowsa, gdzie są programy które działają na starszych Windowsach bez problemu, ale na nowszych już nie i to właśnie dlatego, że starsze wersje Windowsów były mniej 'gorliwe'.

Rozwiązaniem jest czytanie dokumentacji. Generalnie jeśli w dokumentacji jest zaznaczone, że coś tam może się zmienić to nie powinno się zakładać, że się nie zmieni. Podobnie jeżeli coś tam działa w określony ale nieudokumentowany sposób to też nie powinno się na tym polegać. Kontrakty są publiczne i tych kontraktów trzeba się trzymać. Wykorzystywanie nieudokumentowanych szczegółów implementacyjnych to proszenie się o problemy.

@koziolek: oczywiscie ze kompilator bedzie informowal. Dostaniesz warning ze target jest mniejszy niz obecna java i ze powinienes zastapic rt.jar z obecnej javy na tego z tej starej za pomoca bootstrapclaspath czy jakos tak. Dokladnie nie pamietam jaki ten warning ma teskst, ale jednak taki warning jest.

@mućka, nie mówię o różnicach w składni np. użyciu forEacha w 1.4, czy defaultów z interfejsów w starszych wersjach . Zrób taki test:

public class A {

    public static void main(String[] args) {
        System.out.println("".isEmpty());
    }
}

Skompiluj w Javie 1.6+ z opcjami na 1.5. Następnie uruchom na 1.5. Otrzymasz MethodNotFound ponieważ metoda isEmpty została dodana w API 1.6. Kompilator nie jest wstanie sprawdzić tego czy w starszej wersji javy istniała określona metoda. Sprawdza tylko czy metoda istnieje w ramach obecnego classpath-u. Rozwiązaniem była by adnotacja @since, ale użyta w kodzie, a nie tylko w javadocu.

Panowie dzięki wielkie za odpowiedzi. Teraz widzę, że to co było napisane o społeczności Javy było prawdą. Tym bardziej cieszę się że wybrałem Jave.

Koziołek napisał(a):

Skompiluj w Javie 1.6+ z opcjami na 1.5. Następnie uruchom na 1.5. Otrzymasz MethodNotFound ponieważ metoda isEmpty została dodana w API 1.6. Kompilator nie jest wstanie sprawdzić tego czy w starszej wersji javy istniała określona metoda. Sprawdza tylko czy metoda istnieje w ramach obecnego classpath-u. Rozwiązaniem była by adnotacja @since, ale użyta w kodzie, a nie tylko w javadocu.

Właśnie mi chodzi o to samo tylko w drugą stronę. Nauka Javy jest mi potrzebna żeby w przyszłości napisać dla siebie taki mały program powiązany z bazą danych w MySQL. W zasadzie mógłbym zrobić to w zwykłej bazie danych Base OpenOffice'a bo i nawet to już zrobiłem w 10 minut :) no ale używanie takiej bazy to żadna frajda.
I z tego powodu zacząłem się martwić wersja Java 8. Bo nauczyć się chcę programować w Java 7 (bo jest dużo materiałów i książek do wersji 7) i swój mały projekcik wykonać właśnie na tej wersji 7. Tylko zacząłem się martwić tą nową Javą 8, że projekt wykonany w technologii nr 7 nie zadziała na najnowszej maszynie Java 8, gdy np: będę chciał komuś pochwalić się swoim programikiem kto będzie miał wirtualną maszynę Java 8.

Dodam tylko że naukę traktuję jedynie jako hobby i nie aspiruję nawet do tego żeby zostać w przyszłości programistą.

W tym kierunku zadziała. Wyjątki:

1. użyłeś czegoś mocno związanego z Java7 jako taką i oparłeś się na jej wewnętrznych mechanizmach (mało prawdopodobne).
2. użyłeś czegoś z pakietów com.sun.*, które są specyficzne dla maszyny HotSpot (też mało prawdopodobne).

@Koiolek: zrobilem i oto co dostalem:
javac: target release 1.5 conflicts with default source release 1.8
To jest wlasnie to o czym mowie - poszukaj, poczytaj, doucz sie. Tutaj oto pierwszy lepszy link:
http://fantom.org/sidewalk/topic/1765
z takim oto fragmentem:

If you specify appropriate -bootclasspath and -extdirs options pointing to older versions of the rt.jar and friends in it you will get compile errors if you try to use classes or methods added after JDK 1.5. If you don't specify the -bootclasspath and -extdirs this way you'll get an error at runtime if you try to use classes or methods not available in JDK 1.5 AND you actually run the app in JRE 1.5.

Czyli nie, nie masz racji, tak, kompilator moze i generuje ostrzezenia.

@mućka, jeszcze raz uruchom:

$ javac -target 1.5 -source 1.5 A.java

z javac 1.6 :) Wtedy nie dostaniesz ostrzeżeń. Co więcej nawet z 1.7 nie dostaniesz ostrzeżenia jeżeli używasz mavena, bo ten je zflooduje swoim logiem (build będzie ok).

A co mnie obchodzi jakas przestarzala wersja java, albo to, ze uzywasz gownianego systemu budowania ktory flooduje ci konsole i uniemozliwia czytanie informacji kompilatora? Po pierwsze primo, maven warningi robi disc widoczne z tego co pamietam poniewaz dodaje prefixy. Jak chcesz to sobie zainstaluj skrypty ktore sprawia ze linie z pewnymi regexami sa kolorowane (jeden z lepszych jakie uzywalem nazywal sie 'rainbow costam' - dodaje escape cody do kolorowania, oczywiscie jesli uzywasz jakiejs rozsadnej konsoli; jesli mi powiesz ze 'konsola windows tego nie wspiera' to sory, ale zal mi takich ludzi). Po drugie primo, mozesz uzyc lepszych narzedzi ktore wspieraja kolorowanie, np. gradle. Po trzecie primo, zal mi ciebie jesli nie wiesz jakie warningi generuje twoj build bo ci sie nie chce choc raz ich poczytac. Jak jestes taki leniwy, to zrob 'mvn clean cokolwiek > /dev/null' - warningi sa wywalane na stderr ktorego to polecenie nie przekierowuje, wiec zobaczysz bez problemu. Po czwarte primo, temat ktory podlinkowalem uzywa jdk 7 i tez koles ma taki warning wiec chyba jednak dziala. Albo nie uzywa mavena? Albo moze czyta co robi jego build? Hmmmmm.

Koziołek napisał(a):

W tym kierunku zadziała. Wyjątki:

1. użyłeś czegoś mocno związanego z Java7 jako taką i oparłeś się na jej wewnętrznych mechanizmach (mało prawdopodobne).
2. użyłeś czegoś z pakietów com.sun.*, które są specyficzne dla maszyny HotSpot (też mało prawdopodobne).

@Koziołek dzięki za tą odpowiedź. Teraz już wiem na 100% że mogę spokojnie zacząć naukę podstaw programowania na Java 7.

Teraz pozostaje mi tylko zarejestrować się oficjalnie na forum wybrać IDE i kupić jakieś książki.

Pewnie jeszcze nie raz zadam jakieś śmieszne pytanie dla doświadczony 'Javowców', ale cieszę się że społeczność jest przychylna i nie olewa czasem nawet 'głupich' pytań. (Głupich w sensie tak banalnych dla doświadczonych programistów, że o taką oczywistość nie powinno się pytać). Jednak z początkującymi zawsze chyba jest tak samo, że zachowują się jak dzieci i o wszystko pytają.

P.S.
Przypomniał mi się jeszcze kawał, właściwie to nie kawał. Wiecie, że jeszcze kiedyś uważałem, że nie warto się uczyć Javy bo to beznadziejny język ?
A wiecie dlaczego? Bo stwierdziłem, że jak potrzebna jest wirtualna maszyna to programy/aplikacje napisane w Javie są mało wydajne i to nie ma przyszłości. Skoro nie nadaje sie na zbudowanie drugiego Windows'a czy Linuksa to szkoda czasu na taki język programowania.
No ale przecież, czy każdy kto zaczyna naukę programowania ma od razy zostać drugim Bill'em Gates'em czy Linusem Torvalds'em?
Chyba tylko przez takie głupie myślenie ludzie odrzucają naukę Javy czy Pythona.

Pozdrawiam i dzięki za miłe przyjęcie.

Możesz spokojnie uczyć się nawet Javy 1.5, a nawet przy pewnej ostrożności Javy 1.2 (kiedyś nazywana była "Java 2", co w przyszłości doprowadzi do pomyłek niektórych osób). Nawet gdyby obudził się jakiś hibernatus, który znał tylko Javę 1.0, to jeżeli trzymałby się wyłącznie dokumentacji mógłby tworzyć działające programy w Javie 1.8. Od najstarszej wersji Javy powstało kilka nowych paradygmatów programowania i odkryto w związku z tym kilka własności z tym związanych. Dlatego Java zmieniała się w czasie i coś co kiedyś uznawano za prawidłowe, dzisiaj takim nie jest. Mimo to środowisko tego języka pozwala nie tylko na działanie takich programów, ale nawet na ich kompilację pod nowszymi wersjami opatrując niezbyt dobre z dzisiejszego punktu widzenia elementy ostrzeżeniami z których łatwo się dowiedzieć gdzie należy dowiedzieć się więcej i jak coś poprawić zgodnie ze współczesną wersją języka.

Mi też kiedyś wydawało się, że Java jest niewydajna bo na jej starcie była językiem interpretowanym, dopiero potem kompilowanym - i to też do kodu uniwersalnego jakim jest kod bajtowy. Jednak od czasów kiedy wymyślono kompilację/konwersję kodu binarnego w locie nie ma to wpływu na degradację wydajności. Kod źródłowy Javy jest kompilowany do kodu maszynowego idealnego nieistniejącego procesora, ale potem ten kod jest jeszcze dodatkowo konwertowany uwzględniając możliwości i ograniczenia docelowego procesora. Dzięki temu CPU wykonuje swój kod maszynowy w swoim środowisku, który jest tak wydajny jak starannie udało się przełożyć niskopoziomowy kod bajtowy na równie niskopoziomowy kod CPU. Nierzadko wygenerowany kod maszyny docelowej jest nawet nieco bardziej wydajny od kodu wyprodukowanego przez generator kodu kompilatora natywnego. A przynajmniej nie gorszy. Kompilator natywny jest od razu ograniczony specyfiką docelowego CPU, a kompilator Javy jest ograniczony jedynie specyfikacją maszyny wirtualnej. To pozwala niektóre konstrukcje kodu wysokopoziomowego Javy przełożyć na kod niskopoziomowy efektywniej, a jednocześnie wciąż przenośnie. A potem następuje jeszcze drugi, opcjonalny poziom przełożenia kodu, który nie jest już przenośny i istnieje tylko w pamięci RAM docelowej maszyny. Jest pewna klasa programów wysokopoziomowych, które działają dzięki temu szybciej niż w innych językach wysokopoziomowych kompilowanych bezpośrednio do kodu natywnego. Mimo to istnieją kompilatory Javy do kodu natywnego wielu CPU.
A co do możliwości stworzenia systemu operacyjnego w Javie, to stało się to faktem, mimo to że nie użyto do tego ani razu JVM od Suna, lecz autorskie rozwiązania.