Dlaczego Java nie ma przyszłości?

Po pierwsze nie rozumiesz czym są formatery i do czego służą. Zapewne nie rozumiesz też modelu wielowątkowości w javie. Ale pocieszę cię. W C++ też nie ma bezpiecznej obsługi dat dla aplikacji wielowątkowych.
Co do luk krytycznych, to java nie jest ich w sumie dużo. Na przykład w FF 27 (update w tym tygodniu do tej wersji był) masz już cztery krytyczne > http://www.mozilla.org/security/known-vulnerabilities/firefox.html, a cykl wydawniczy jest znacznie krótszy.

Swoją drogą wyczuwam tu raczej niezaliczony przedmiot i wylewanie żali na "gupio dżawe"...

Nie ma przyszłości, bo singletona trzeba implementować przez enum (a i tak nie wiem czy będzie mógł mieć w tym wypadku lazy initialization).

http://java.dzone.com/articles/singleton-design-pattern-%E2%80%93

Jakaś masakra. Niech mi ktoś wyjaśni jak to jest możliwe że to musi być tak skomplikowane - w Javie.

@vpiotr, po co w ogóle implementować singletona "na twardo"? Nie tylko w Javie? Od tego jest DI. Zresztą jakaś dzika mania z tym wzorcem jest.

Koziołek napisał(a):

@vpiotr, po co w ogóle implementować singletona "na twardo"? Nie tylko w Javie? Od tego jest DI. Zresztą jakaś dzika mania z tym wzorcem jest.

Nie wiem czy o tym samym myślimy, ale...
Wręcz przeciwnie. W zasadzie nigdy nie miałem potrzeby na singletona "na twardo". Nawet mnie to wk... jak gdzieś widziałem.

Przez "na miękko" rozumiem dwa case'y:

• pytam się o obiekt z klasy (getInstance) ale nie obchodzi mnie czy to jest klasa potomna czy nie (nawet lepiej jeśli może być potomna)
• pytam się o obiekt pod określoną nazwą string, jak go nie ma to wywałka, może być potomny

Z tym że jak już jeden jest to ma się więcej nie tworzyć.

Coś jak ManagedBean z AppScoped. Tylko bez JSF/CDI etc.

Oba przypadki masz zazwyczaj robione przez fabryki. Co więcej można np. użyć Springa czy Guice w aplikacji JSE i nawet nie będziesz widział różnicy.

Singletony w Javie:
http://en.wikipedia.org/wiki/Singleton_pattern

Jeśli ktoś chce mieć leniwie ładowane singletony, thread-safe i bez zbędnej synchronizacji to ma co najmniej dwa wyjścia:

1. Użycie enuma. Enumy są leniwie tworzone, a w zasadzie to pół-leniwie. Chodzi o to, że wszystkie instancje enuma są tworzone naraz przy pierwszym użyciu któregokolwiek. W przypadku gdy jest tylko jeden enum (co czyni z enuma singletona) wtedy nie ma to znaczenia. Zaletą enuma-singletona jest to, że jest zwięzły. Wadą jest to, że nie może dziedziczyć po żadnej klasie.
2. Użycie "Initialization On Demand Holder Idiom" od Billa Pugha. To jest moje ulubione. Jest trochę więcej linijek niż przy użyciu enuma, ale za to nie ma WTFa (enum-singleton?) oraz zostaje nam możliwość dziedziczenia.

Zabawy z 'volatile' teoretycznie skutkują zmniejszonymi możliwościami optymalizacji - zmienne typu volatile nie mogą być przechowywane (keszowane) w rejestrach procesora.

Mi się osobiście w javie nie podoba to, że wymusza na nas programowanie obiektowe.

@tomi0001 gdyby Java wymuszała, tak naprawdę takie prawdziwe programowanie obiektowe to dział jej poświęcony świecił by pustkami. Serio. Nie podoba się programowanie obiektowe? Programuj proceduralnie (jest goto i nawet działa) czy też strukturalnie. Chcesz programować funkcyjnie? Też się da. Co prawda składnia będzie ekstremalnie obrzydliwa, ale jakieś takie LISPo podobne rzeczy da się uzyskać. Chcesz aktorów? Masz Akkę. Chcesz aspekty? Można użyć aspectJ, obiektów proxy i kilku innych rozwiązań.

tomi0001 napisał(a):

Mi się osobiście w javie nie podoba to, że wymusza na nas programowanie obiektowe.

Nie wymusza. Zdarzają się tacy co robią większość programu na staticach.

James Gosling też jeszcze żyje :D
Zaczynam się obawiać o C...

Idąc tym tokiem rozumowania Apple nie ma przyszłości ;)

Kolosalną zaletą Javy jest to, że jest wieloplatformowa.

Zaletą nie jest to, że jest wieloplatformowa... jak seks analny... zaletą jest sama maszyna wirtualna pozwalająca na ujednolicenie kodu wykonywalnego.

W przypadku naprawdę zaawansowanych aplikacji zawsze przychodzi moment gdzie trzeba sięgnąć do API systemu i wtedy kończy się "wieloplatformowość" Javy. O C++ też już dawno temu mówiono że to jego koniec a w tej chwili rozwija się chyba najdynamiczniej z pozostałych( włączając w to biblioteki ) więc i Java ma "jakąś" przyszłość. A jaką? to zależy od rynku a dokładniej od firm, programistów którzy wybiorą ( lub nie ) tą technologie do swoich projektów. Ja miałem okazję poznać podstawy Javy - nie spodobała mi się i na szczęście nie muszę jej używać.
W zaawansowanych aplikacjach i tak króluje Windows więc C++ / C# w zupełności wystarcza.
Ale Flame! xd

Czy ja wiem czy trzeba sięgać do platformy? Napisałem w życiu trochę kodu i jedynym przypadkiem gdy musieliśmy grzebać się w API systemu był projekt z wykorzystaniem czytnika RS232. Zresztą w przypadku Javy jest JNA/JNI i przygotowanie sobie wrapera na popularne systemy nie jest problemem.

Kozioł to z C to ironia tak? :D prawdopodobnie dziś nie mógł bym nawet bez C użyć kalkulatora.

@jokelikethat, czy nazwisko Dennis Ritchie coś ci mówi?

@n0name_l nie chce zaczynać kolejnego Flama ale tak jest. Oczywiście zawsze znajda się odpowiedniki danych programów na inne platformy a to czy są gorsze czy lepsze to już zdanie bardzo subiektywne. Zależy też o czym myślimy mówiąc "zaawansowane" - Photoshop, Corel, można by mnożyć przykłady programów które ( według mnie ) nie maja równego sobie odpowiednika. Poza tym większość firm w Polsce używa tego systemu niezależnie czy jest to Desktop czy coś przenośnego a że Tobie się to nie podoba no cóż - przykro mi ;)

@vpiotr programistyczną "karierę" uzależniasz od znajomości Javy? Nie zgadzam się. A jeśli nawet by tak było to dam ogłoszenie "oddam karierę programistyczna w dobre ręce" a sam zostanę po prostu przy programowaniu ;)

Koziołek napisał(a):

@jokelikethat, czy nazwisko Dennis Ritchie coś ci mówi?

Chodzi o to że on umarł i C wraz z nim? :D

Ja się zastanawiam, kiedy niektórzy ludzie zrozumieją, że nie każdy program to jakieś okienko pod jakimś Windowsem.

@emacs, słyszałeś może o czymś takim jak aplikacja webowa albo usługa sieciowa?

Widzę że muszę doprecyzować swoją wypowiedź bo chyba zostałem źle zrozumiany ;)
@somekind oczywiście że słyszałem ;) oczywiste jest też to że z tym "królowaniem Windowsa" to był flejm bo wydawało mi się że w tym dziale mogę sobie na to pozwolić.
Co do Javy tak jak pisałem miałem okazje poznać podstawy - napisać prosty programik na zaliczenie, aplet i sam język nie przypadł mi do gustu ale przecież nie atakuje ani Javy ani osób które ja wykorzystują - kto co lubi.
@n0name_l masz rację wziąłem pod uwagę tylko Desktop zapominając o urządzeniach mobilnych gdzie Windows już nie ma największego udziału, ale jeszcze raz chciałbym podkreslić że ja tutaj nie porównuje systemów jakościowo nie chce zaczynać kłótni, to tak jak z językami - każdy używa tego co lubi, mi chodziło tylko o ogólny udział systemu Windows w rynku.
Pewnie są firmy które w ogóle nie używają Windowsa i ok ;) być może takich miejsc jest dużo ale biorą pod uwagę kryterium które podałem to tak czy inaczej wychodzi Windows > reszta systemów. ( ILOŚCIOWY UDZIAŁ W RYNKU )
I teraz dlaczego to mówię? A no dlatego że w momencie gdy piszesz nowy projekt i chciałbyś całkowicie "olać" systemy Windows to tak naprawdę automatycznie tracisz ponad połowę wszystkich urządzeń które mogłyby się zainteresować Twoim systemem. I to by było tyle ;)

gdy piszesz nowy projekt i chciałbyś całkowicie "olać" systemy Windows to tak naprawdę automatycznie tracisz ponad połowę wszystkich urządzeń które mogłyby się zainteresować Twoim systemem

Właśnie po to stworzono Javę, żeby można było ominąć ten problem. Dla drobnych klepaczy piszących "notatniki" na desktop jest to problem, który nie istnieje.
W przypadku tworzenia rozbudowanych i krojonych na miarę systemów biznesowych, z bazami danych itd. itp. również nie ma tego problemu, bo pisze się pod już istniejącą infrastrukturę.

emacs napisał(a):

I teraz dlaczego to mówię? A no dlatego że w momencie gdy piszesz nowy projekt i chciałbyś całkowicie "olać" systemy Windows to tak naprawdę automatycznie tracisz ponad połowę wszystkich urządzeń które mogłyby się zainteresować Twoim systemem. I to by było tyle ;)

Tak, ale to jest wyłącznie problem programistów desktopowych. Webowców nie obchodzą systemy operacyjne ani API systemowe. (Mają większe problemy. :P)

Jak zaczynam (powiedzmy, ze zaczynam choc w przypadku wiekszosci projektow to dalekie od jakiegokolwiek stanu faktycznego) projekt, to z mojego punktu widzenia jest kompletnie obojetne jakiego systemu klient bedzie uzywac. Z punktu widzenia marketingu natomiast, wazne jest, aby trafic do jak najwiekszej ilosci tych klientow. Sa tu dwa wyjscia:
#Pisac soft oddzielnie na kazdy system (prawdopodobnie firma zbankrutuje w miedzyczasie, albo caly personel z niej ucieknie)
#Napisac serwis z interfejsem webowym i miec gdzies czy ktos uzywa windowsa, linuxa czy wyderos (brzmi ciekawiej).

@emacs, po pierwsze 99% softu w Javie jest pisana w taki sposób, że jego uruchomienie wymaga od uruchamiającego wiedzy o "czarnej magii konsolowej", inaczej mówiąc, końcowy użytkownik korzysta z interfejsu webowego i nie wnika co jest pod spodem.
Po drugie pozostałe 1% oprogramowania jest napisane w javie i na JVM uruchamiane przez co jedynym zmartwieniem użytkownika końcowego jest dość duża paczka z programem zawierajacą zazwyczaj gotowego JVMa (jak by ktoś nie miał zainstalowanej).
Po trzecie, jeżeli piszesz soft w którym wymagane są wywołania systemowe, to
a) nie używasz javy
b) i tak jest to dedykowane pod konkretnego sysopa oprogramowanie
Po czwarte, zgodność z sysopem zapewnia JVM i zmartwieniem programistów JVM jest to by była ona zgodna z różnymi systemami.

Podsumowując, jak piszesz w javie to możesz położyć lachę na system operacyjny, ponieważ twoim jedynym "systemem" jest JVM.

Tylko trzeba zadać sobie kolejne pytanie czy ta wieloplatformowość w Javie to coś co daje jej aż taka przewagę nad innymi językami? Teraz praktycznie do każdego języka są kompletne zestawy wieloplatformowych bibliotek dla przykładu to w czym ja aktualnie siedzę - C++ / boost / Qt i jedynym problemem ( jeśli tak to można nazwać ) jest konieczność kompilacji na konkretne systemy które chce obsługiwać plus ewentualnie wywołania API konkretnego systemu ale to jest 1%.
@Koziołek

końcowy użytkownik korzysta z interfejsu webowego

w przypadku aplikacji które mogą sobie na to pozwolić to faktycznie jest to duża zaleta. To wszystko zależy od konkretnego typu końcowej aplikacji. Ja obracam się raczej w aplikacjach które z webem nie mają zbyt wiele wspólnego( poza połączeniem / wymianą danych ) dlatego pewnie też ciężko dostrzec mi plusy stosowania Javy.

emacs napisał(a)

To wszystko zależy od konkretnego typu końcowej aplikacji.

OK, zgoda. Pytanie jest jedno - czy aplikacje, które piszesz naprawdę nie mogą być przeportowane na WEB. Jeżeli są to tylko okienka z formularzami to zapewne nie stanowi to problemu. Jeżeli jest to jakiś CAD, to trzeba by się było pobawić z animacjami na canvas, ale to już inna sprawa.

Pewnie są firmy które w ogóle nie używają Windowsa i ok ;) być może takich miejsc jest dużo ale biorą pod uwagę kryterium które podałem to tak czy inaczej wychodzi Windows > reszta systemów. ( ILOŚCIOWY UDZIAŁ W RYNKU )

Ilościowy udział w jakim rynku? Desktopów? Urządzeń mobilnych? Serwerów? Nawet w ramach desktopów, zupełnie inny udział Windows będziesz mieć na komputerach domowych a zupełnie inny na komputerach firmowych firm sektora IT a jeszcze innych w komputerach wydawnictw itp. Jaki jest sens wrzucać wszystko do jednego worka?

Inna rzecz, że akurat przenośność Javy nie jest jest wcale jej główną zaletą. Właściwie trudno pokazać jedną zaletę - bo dla każdej cechy zapewne znajdzie się jakiś język, który robi to lepiej. Natomiast ważne, jest, że poniższe cechy występują równocześnie:

1. w miarę prosty język, którego można się szybko nauczyć i w którym nie ma zbyt wielu pułapek i niespodzianek (pewne są, ale jest ich znacznie mniej niż np. w C++)
2. dostępność świetnych narzędzi wspomagających pisanie kodu; do tego darmowych lub bardzo tanich
3. rozbudowana biblioteka standardowa i mnóstwo bibliotek zewnętrznych wysokiej jakości (choćby od ASF czy Google)
4. ustandaryzowane ABI i API (kompatybilność wsteczna, kompatybilność między platformami)
5. dobra wydajność - w większości sytuacji nieustępująca "językom szybkim" tj. C lub C++
6. sprawdzona i stabilna platforma wykonawcza
7. na JVM są dostępne jedne z najbardziej zaawansowanych i najwydajniejszych GC
8. wsparcie dużych firm (Oracle, IBM, Google) i, mimo przejściowych problemów przy przejęciu Suna, stabilny rozwój

http://en.wikipedia.org/wiki/Usage_share_of_operating_systems jeśli chodzi o desktopy to rzeczywiście "windows" prowadzi jednak tam, gdzie liczy się kasę (serwery) to 2/3 rynku mają UXy