Warsztat.GD

Programowanie => Językoznawstwo => Java => Wątek zaczęty przez: Rokuzo w Sierpień 13, 2010, 22:51:44

Tytuł: Kilka pytań dotyczących javy
Wiadomość wysłana przez: Rokuzo w Sierpień 13, 2010, 22:51:44
Witam ...
Chciałbym się Was zapytać o kilka rzeczy związanych z Javą.

1.Java to maszyna wirtualna -> Java SE to standardowa wersja Javy -> Java EE to dodatkowe klasy Javy bazujące na wersji SE dodające kilka możliwości -> Java ME to wersja klas javy przeznaczonych na urządzenia mobilne -> JavaFX to język skryptowy mający mniej więcej takie możliwości (z założenia) jak Flash czy Silverlight ?
Jeżeli coś tutaj się nie zgadza to proszę poprawcie mnie ;) (trudno było mi się połapać w tych nazwach i pojęciach a na każdej stronie piszą co innego ;p)

2.Czy warto się uczyć Javy (a dokładnie JavyME znanej jako J2ME) ? (Co do wydajności to wiem, że wcale wolna Java nie jest a podobno czasem szybsza niż c++ ;p).

3.Czy może jednak pozostać przy C++/WinApi/DirectX ?

4.Pytam się głównie z ciekawości bo mam możliwość nauki JavyME (posiadam książkę).
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: Minus w Sierpień 13, 2010, 23:13:23
2.Czy warto się uczyć Javy (a dokładnie JavyME znanej jako J2ME) ? (Co do wydajności to wiem, że wcale wolna Java nie jest a podobno czasem szybsza niż c++ ;p).
ME? Nie, nie jest :)

http://www.youtube.com/watch?v=A-Rp6wMZ1-s
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: Avaj w Sierpień 13, 2010, 23:18:23
Jak chcesz to się ucz. Ja tam Javę całkiem lubię, ma niestety też parę rzeczy, których brakuje mi z C++a (a konkretnie ich nie ma) np. przeciążanie operatorów i szablony.
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: Xion w Sierpień 13, 2010, 23:52:00
Czy Java ME przypadkiem nie zdycha słuszną śmiercią od czasu, gdy upowszechniły się bardziej zaawansowane platformy mobilne (iOS, Android, nowy system od Nokii)?...
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: MadBonsai w Sierpień 14, 2010, 00:41:19
1.Java to maszyna wirtualna -> Java SE to standardowa wersja Javy -> Java EE to dodatkowe klasy Javy bazujące na wersji SE dodające kilka możliwości -> Java ME to wersja klas javy przeznaczonych na urządzenia mobilne -> JavaFX to język skryptowy mający mniej więcej takie możliwości (z założenia) jak Flash czy Silverlight ?
Jeżeli coś tutaj się nie zgadza to proszę poprawcie mnie ;) (trudno było mi się połapać w tych nazwach i pojęciach a na każdej stronie piszą co innego ;p)
Flash i Silverlight nie są nazwami języków skryptowych, a technologii składających się z paru rzeczy więcej, więc nie da się tego bezpośrednio porównywać. Tym bardziej, że siłą Flasha (tudzież AIR, Flex, ActionScript) są mocno rozwinięte narzędzia developerskie. JavaFX dorobiła się wsparcia w IntelliSense NetBeansa (może i Eclipse, nie sprawdzałem), paru prostych narzędzi i nic więcej. Język sam w sobie bardzo fajny, ale nic poza tym ;)
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: Rokuzo w Sierpień 14, 2010, 10:01:36
Aha no ok dzięki za odpowiedzi. Co do zdychania JavyME przeciesz podobno można ją uruchomić na iphonie, androidzie itp ^^.A ten filmik też fajny jest. Nie no ogólnie kilku rzeczy się dowiedziałem, dzięki.
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: counterClockWise w Sierpień 14, 2010, 10:35:24
Aha no ok dzięki za odpowiedzi. Co do zdychania JavyME przeciesz podobno można ją uruchomić na iphonie, androidzie itp ^^.A ten filmik też fajny jest. Nie no ogólnie kilku rzeczy się dowiedziałem, dzięki.

To niestety prawda. JavaME zdycha, można ją uruchomić, ale programistów JavaMe rynek już prawie wcale nie szuka.
Popyt na programistów danego języka to całkiem znośna miara oceny jego żywotności. Owszem, istnieją jeszcze firmy celujące w stare telefony, albo potrzebujące ludzi do zarządzania istniejącymi już produktami, ale to brzmi mało przyszłościowo.

Na takim iPhonie na samym początku nie można było uruchomić J2ME, poza tym jakie ma szanse przeciwko aplikacjom napisanym na jego natywnym API? 
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: Wyszo w Sierpień 14, 2010, 21:59:05
Jak chcesz to się ucz. Ja tam Javę całkiem lubię, ma niestety też parę rzeczy, których brakuje mi z C++a (a konkretnie ich nie ma) np. przeciążanie operatorów i szablony.

Szczerze mówiąc też mi tego brakowało... nawet na jednej z rozmów kwalifikacyjnych prowadziłem dyskusję na temat "co mi się nie podoba w Javie i dlaczego".

Brakowało mi tych rzeczy... dopóki nie zacząłem na poważnie pracować (czyli od bardzo niedawna). Im prostszy kod, tym łatwiejszy do utrzymania. Jasne, przeciążenie operatorów - fajna sprawa, ale daje pole do popełniania błędów i komplikuje kod klas. A poprawianie cudzych błędów nie jest fajne - im mniej możliwości do ich popełnienia, tym lepiej dla wszystkich. Prawdę mówiąc jak kodzi się w grupie, to najlepiej, żeby nie było żadnych wskaźników, template'ów, a cały kod był wykonywany sekwencyjnie (żadnych elementów współbieżnych) ;)
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: kamykadze w Sierpień 16, 2010, 15:40:30
Chyba rzeczywiście JavaME jest w fazie schyłkowej. Moim zdaniem jej główne zastosowanie to pisanie prostych aplikacji z nadzieją, że pójdą na dużej liczbie telefonów/smartfonów ( poza Androidem i iPhonem wszystkie istotne platformy mobilne jeszcze wspierają JavęME ) lub pisanie pod starsze modele telefonów. Za kilka lat nie będzie przydatna, chyba że Sun/Oracle dokona jakiegoś cudu (w co nie wierzę...).

Ale nauczyć się można, bo:
- technologia jest bardzo prosta,
- przy okazji nauczysz się Javy (okrojonej, ale jednak), co może Ci się przydać gdzie indziej.
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: MadBonsai w Sierpień 16, 2010, 15:47:28
Ale nauczyć się można, bo:
- technologia jest bardzo prosta,
- przy okazji nauczysz się Javy (okrojonej, ale jednak), co może Ci się przydać gdzie indziej.
Np. przy aplikacjach na Androidy  ::)
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: kamykadze w Sierpień 16, 2010, 16:10:32
Ale nauczyć się można, bo:
- technologia jest bardzo prosta,
- przy okazji nauczysz się Javy (okrojonej, ale jednak), co może Ci się przydać gdzie indziej.
Np. przy aplikacjach na Androidy  ::)

Chyba że Oraclowi uda się to:
http://www.scribd.com/doc/35811761/Oracle-s-complaint-against-Google-for-Java-patent-infringement

;)
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: krychu88 w Sierpień 16, 2010, 16:17:50
Tylko chciałem dodać, że co prawda szablonów takich jak w c++ nie ma, ale za to są typy generyczne. Co prawda akurat w J2ME tego nie ma, ale generalnie w Javie jest (w Androidzie też).
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: JasonVoorhees w Sierpień 16, 2010, 17:29:47
http://www.youtube.com/watch?v=1JZnj4eNHXE - ten filmik o Javie jest dobry :D

Co do samej Javy... Co kto lubi. Ja np. nie przepadam za Javą, chociaż mało w niej robiłem, to raczej działała na mnie odpychająco... Tam wszystko to przerost formy nad treścią. Przykładowo mam sobie Google App Engine i robię w nim aplikację internetową (czyli stronka z jakimiś tam mechanizmami, jak chociażby Shoutbox). No i jako, że wcześniej robiłem w Google App Engine pod Python'em, to myślałem, że niewiele się będzie to różniło i równie łatwo mi przyjdzie pisanie aplikacji. Nic bardziej mylnego, w Google App Engine konkretną tabelę w bazie danych definiujemy jako klasę z odpowiednimi polami. W Javie trzeba tam się babrać z jakimiś adnotacjami, dodać gettery i settery, obsługę do tej klasy trzeba też pisać - zero intuicyjności. Tak wygląda przykładowa klasa tabeli z mojego jednego projektu w Javie:
Kod: (java) [Zaznacz]
package jpastebin;

import javax.jdo.annotations.IdGeneratorStrategy;
import javax.jdo.annotations.PrimaryKey;
import javax.jdo.annotations.PersistenceCapable;
import javax.jdo.annotations.Persistent;
import com.google.appengine.api.datastore.Key;


@PersistenceCapable
public class Czlowiek {
@PrimaryKey
    @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
    private Key key;
@Persistent
private String nazwisko;
@Persistent
private String imie;
@Persistent
private String telefon;
public Czlowiek(String nazwisko, String imie, String telefon) {
        this.setNazwisko(nazwisko);
        this.setImie(imie);
        this.setTelefon(telefon);
}
public void setNazwisko(String nazwisko) {
this.nazwisko = nazwisko;
}
public String getNazwisko() {
return nazwisko;
}
public void setImie(String imie) {
this.imie = imie;
}
public String getImie() {
return imie;
}
public void setTelefon(String telefon) {
this.telefon = telefon;
}
public String getTelefon() {
return telefon;
}
}
Do takiej tabelki jeszcze trzeba napisać klasę obsługującą:
Kod: (java) [Zaznacz]
package jpastebin;
import javax.jdo.JDOHelper;
import javax.jdo.PersistenceManagerFactory;

public final class PMF {
    private static final PersistenceManagerFactory pmfInstance =
        JDOHelper.getPersistenceManagerFactory("transactions-optional");

    private PMF() {}

    public static PersistenceManagerFactory get() {
        return pmfInstance;
    }
}
A tak wygląda dodanie nowego wpisu do tej tabelki:
Kod: (java) [Zaznacz]
public void doPost(HttpServletRequest req, HttpServletResponse resp) throws IOException {
Czlowiek czlowiek=new Czlowiek(req.getParameter("nazwisko"), req.getParameter("imie"), req.getParameter("telefon"));
PersistenceManager pm = PMF.get().getPersistenceManager();
///*
try {
            pm.makePersistent(czlowiek);
        } finally {
            pm.close();
        }//*/
}

W Python'ie z użyciem tej samej technologii (Google App Engine) tak wygląda deklaracja tabelki:
Kod: (python) [Zaznacz]
from google.appengine.ext import db
from Lista_podstron import Lista_podstron
class Pojedyncza_strona(db.Model):
nazwa = db.StringProperty(multiline=False)
zawartosc = db.TextProperty()
data_modyfikacji = db.DateTimeProperty(auto_now=True)
opis = db.TextProperty()
A tak wygląda dodawanie wpisu do niej:
Kod: (python) [Zaznacz]
ps=Pojedyncza_strona()
ps.nazwa="jakas nazwa"
ps.zawartosc="jakas tresc"
ps.opis="jakis opis"
ps.put()
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: Liosan w Sierpień 16, 2010, 17:36:44
W Javie trzeba tam się babrać z jakimiś adnotacjami, dodać gettery i settery, obsługę do tej klasy trzeba też pisać - zero intuicyjności.
To kwestia JDO, w JPA ani Hibernate takiej potrzeby nie ma, a wykonanie zapisu do bazy to mniej więcej:
entityManager.persist(czlowiek) W ogóle przykłady są tendencyjne, bo kodzie pythonowym tworzyć "foo" "bar", a w Java'owym wyciągasz dane z requestu. No ale adnotacje, gettery i settery nadal trzeba dodawać; i straszne on ma jakieś fanaberie na ten temat.

Liosan
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: JasonVoorhees w Sierpień 16, 2010, 18:08:18
Przykłady wyglądają na tendencyjne dlatego, że Pythono'wy z głowy pisałem, a Javowy kopiowałem z malutkiego projektu, który kiedyś pisałem ;)
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: JCoder w Wrzesień 02, 2010, 11:26:49
JavaME raczej zdycha. Ale za to Android ma się dobrze i pretenduje do najpopularniejszego OSa na rynku Smartphone'ów. Liczba sprzedanych telefonów z Androidem przekroczyła liczbę sprzedanych IPhone'ów w USA niedawno. Dlatego Java: tak, JavaME: zdecydowanie nie. Zresztą w ogóle JavaME to dla mnie od początku był niewypał. To co udało się Sunowi z desktopową Javą, kompletnie nie udało się w przypadku ME - producenci dostarczali niekompatybilne JVMy, z bugami, głupimi ograniczeniami. W ogóle programowanie telefonów to był straszny syf (nie ważne czy w ME, bo np. Symbian - syf jeszcze większy).

A o to że Oracle ubije Google'a za Dalvika, to bym się nie martwił. Raczej będzie ugoda i pewnie skończy się na tym, że zmuszą Googla do zapewnienia pełnej zgodności swojego toolchaina ze specyfikacją Javy, co tylko wyjdzie developerom na dobre.

@JasonVoorhees: przerostu formy nad treścią nie ma w Scali, która też działa na GoogleAppEngine i Androidzie. No i ma znacznie lepsze przeciążanie operatorów niż C++ (a zarazem o wiele prostsze koncepcyjnie), a o szablonach / genericsach już kiedyś dyskutowaliśmy (co kto lubi, ale uważam, że możliwości biblioteki standardowej Scali świadczą o sile właśnie genericsów i przemyślanego systemu typów - na pewno jest to jeden z najlepiej zaprojektowanych statycznych systemów typów, godny naśladowania).
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: vashpan w Wrzesień 02, 2010, 12:11:00
Android powinien miec przyszlosc, tylko czy ta przyszlosc bedzie dobra dla deweloperow i userow to w sumie niewiadomo :) To ze przescignal iPhone'a to raczej oczywiste i dziwne ze tak pozno, przeciez iPhone to jeden telefon, od jednego producenta, wiec nie rozumiem tej calej radosci Androidowcow :) Poza tym iOS i jego AppStore nie smiga tylko  na iPhonach, ale do tego trzeba doliczyc tez iPady i iPody touch... ( Na wczorajszej konferencji Apple cos wspominal ze do tej pory zarejestrowano ~120 mln urzadzen z iOS na pokladzie ) Do tego problemy z wersjami Androida - producenci robia sobie w zasadzie co chca, nie ma supportu na uaktualnienia do nowszych wersji od wielu producentow... Z iOS to w ogole nie jest problem - uaktualnienia sa dostepne dla wszystkich supportowanych urzadzen - od razu, lifecycle produktow jest w miare krotki - bolesne moze dla niektorych, ale powoduje ze platforma rozwija sie stabilnie, bez specjalnej koniecznosci "kompatybilnosci wstecznej" - Android moze przescignac iOS w ilosci, ale z jakoscia moze byc roznie. Dzis zobaczylem techdemo portu Unreal Engine 3 dla iOS ( kazdy moze sobie sciagnac za darmo i zobaczyc, ale potrzebuje OpenGL ES 2.0, a wiec >=3gen ) , wczesniej podobna prezentacje zrobil Carmack ze swoim Rage... Czy cos takiego w ogole moze zaistniec na Androidzie ?

Owszem istnieje NDK ( przeciez nie napisza UE3 od poczatku w Javie... ) ale nie bardzo rozumiem jak ma wygladac programowanie w tym, tam jest dostep do OpenGL, bibliotek systemowych ? Bo z tego co rozumiem, NDK sluzy do kompilowania bibliotek potrzebujacych wyciagnac maks ze sprzetu, a wiec np. silniki fizyczne, kodeki etc. Jak to z tym jest ?


Wracajac do tematu, czy warto uczyc sie Javy ? Oczywiscie ze warto, Java to najpopularniejszy jezyk programowania, z multum zastosowan w biznesie, w gamedevie o wiele mniejszy, ale warto go znac. Mi osobiscie Java nie przypada do gustu za bardzo ( po prostu sa IMO lepiej rozwiazane jezyki - np. C# ) ale jest dosc wygodna, ma doskonaly support i narzedzia. Jave po prostu wypada znac ;)
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: Dab w Wrzesień 02, 2010, 13:21:31
Cytuj
Prawdę mówiąc jak kodzi się w grupie, to najlepiej, żeby nie było żadnych wskaźników, template'ów, a cały kod był wykonywany sekwencyjnie

I pod żadnym pozorem interakcji z użytkownikiem. Oni wszystko psują!

:D

Cytuj
aktualnienia sa dostepne dla wszystkich urzadzen - od razu

Nie do końca, iPhone 2G nie jest już supportowane przez iOS4.
iPhone 3G jest co prawda obsługiwany, ale bez paru istotnych zmian (np. "massive single-taskingu" ;) )
Dopiero 3GS i 4G mają pełną obsługę.

(w przypadku iPodów analogicznie)
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: vashpan w Wrzesień 02, 2010, 14:58:02
Cytuj
aktualnienia sa dostepne dla wszystkich urzadzen - od razu

Nie do końca, iPhone 2G nie jest już supportowane przez iOS4.
iPhone 3G jest co prawda obsługiwany, ale bez paru istotnych zmian (np. "massive single-taskingu" ;) )
Dopiero 3GS i 4G mają pełną obsługę.

(w przypadku iPodów analogicznie)

Wiedzialem ze tutaj niedokladnie sie wyrazilem ;) Ale napisalem pozniej ze lifecycle produktu jest dosc krotki, co implikuje brak supportu dla starszego sprzetu. To tez jest dobre - brak 'wiekszych' problemow z "wsteczna kompatybilnoscia" Np. pewnie za ~2 lata rozdzialka 480x320 odejdzie juz w iOS do lamusa...

Co do braku "massive single-taskingu" w urzadzeniach 2gen, mysle ze to dosc dobre posuniecie, w moim zjailbreakowanym ipodzie 2gen odblokowalem sobie multitasking i musze przyznac ze w sumie to dosc srednio to dziala ( choc dziala ) Za to nie bardzo rozumiem czemu zablokowali tez tapety ;) ( wystarczy wyrzucic cienie spod ikon i smiga wszystko normalnie ) a co gorsza takie dosc pozyteczne funkcje jak blokada orientacji czy dostep do odtwarzacza muzyki ( co siedzi w nowym taskbarze; bez odblokowania multitaskingu jakos specjalnie nie znalazlem opcji by to miec )

No ale to nie forum o urzadzeniach Apple'a ;)
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: JCoder w Wrzesień 02, 2010, 17:09:23
Cytuj
Cytuj
Prawdę mówiąc jak kodzi się w grupie, to najlepiej, żeby nie było żadnych wskaźników, template'ów, a cały kod był wykonywany sekwencyjnie

I pod żadnym pozorem interakcji z użytkownikiem. Oni wszystko psują!

Eee tam od razu psują. Błędy są w każdym sofcie (z wyjątkiem TeXa i HelloWorld).

Jednak błędy różnią się kalibrem. Są takie, które się poprawia 5 minut i takie na które potrzeba tygodnia. Lepiej mieć dużo tych na 5 minut niż tych na tydzień, zwłaszcza że w przypadku tych drugich w ogóle ciężko cokolwiek powiedzieć o terminie ich poprawienia. Mechanizmy, które uniemożliwiają błędy tego drugiego rodzaju, to duża zaleta, właśnie w dużym projekcie zespołowym, gdzie jest deadline i gdzie niespodzianki się nie powinny zdarzać. W językach, w których dopuszcza się, że każdy moduł może sobie niejawnie grzebać w prywatnych bebechach innego modułu, i nie ma twardej enkapsulacji, prawdopodobnieństwo walnięcia takiego trudnego błędu rośnie wykładniczo ze wzrostem wielkości projektu.
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: Dab w Wrzesień 02, 2010, 17:15:38
Cytuj
W językach, w których dopuszcza się, że każdy moduł może sobie niejawnie grzebać w prywatnych bebechach innego modułu, i nie ma twardej enkapsulacji, prawdopodobnieństwo walnięcia takiego trudnego błędu rośnie wykładniczo ze wzrostem wielkości projektu.

A co ma do tego język? Pomijam już sensowność "problemu" (w gamedevie), ale równie dobrze możesz zrobić relację "każdy z każdym" w C++, Javie, Pythonie czy Brainfucku. Nie wiem jaki język by tu pomógł -- chyba tylko HQ9+ ma wystarczający poziom enkapsulacji :)
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: JCoder w Wrzesień 02, 2010, 17:20:51
No właśnie ma bardzo dużo, bo język może dostarczać mechanizmy kontroli tego syfu, albo nie, oraz może promować pewien styl programowania, w którym ten syf zależności robi się łatwiej, albo i nie.
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: Liosan w Wrzesień 02, 2010, 17:24:42
W językach, w których dopuszcza się, że każdy moduł może sobie niejawnie grzebać w prywatnych bebechach innego modułu...

Właśnie, w Javie jest to wyjątkowo proste dzięki użyciu refleksji!
            Method getMethodResolverMethod = this.getClass().getSuperclass().
                    getDeclaredMethod("getMethodResolver", Object.class);
            getMethodResolverMethod.setAccessible(true);
::)

Liosan
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: siso w Wrzesień 02, 2010, 17:28:04
Ale przecież każdy gentelmen wie, że używanie refleksji w ten sposób jest... nieeleganckie ;)
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: JCoder w Wrzesień 02, 2010, 17:59:22
Takie coś w kodzie łapie się odpowiednim skryptem, a autora killuje, aby nie przeszkadzał innym kodować. :D

A nawet jeśli się prześliźnie to i tak ryzyko wprowadzenia w ten sposób trudnego do złapania błędu jest o wiele niższe niż np. wykonanie delete w złym momencie w C++. Programiści są leniwi. Dla 90% koderów Javy jakich miałem okazje egzaminować, używanie refleksji to czarna magia - nie wiedzą jak używać, bo nie potrzebują. Refleksja jest potrzebna do pisania frameworków, więc spokojnie można jej zabronić w projekcie całkowicie i problem z głowy.

Z kolei w C++ jest na odwrót: 90% programistów nie wie jak **nie** używać wskaźników. Zabroń zespołowi całkowicie wskaźników, dynamicznej alokacji, rzutowania, dostępu do tablic i paru innych rzeczy, które w sposób niejawny potrafią doprowadzić do naruszenia systemu typów, i powiedz czy będą Cię lubić.
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: Dab w Wrzesień 02, 2010, 18:11:53
Cytuj
Dla 90% koderów Javy jakich miałem okazje egzaminować, używanie refleksji to czarna magia

To faktycznie wybitnych programistów miałeś okazję egzaminować :)
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: Liosan w Wrzesień 02, 2010, 18:14:21
Cytuj
Dla 90% koderów Javy jakich miałem okazje egzaminować, używanie refleksji to czarna magia

To faktycznie wybitnych programistów miałeś okazję egzaminować :)
Ta, bo w C++ to każdy egzaminowany zna standard na wyrywki... :D

Liosan
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: Dab w Wrzesień 02, 2010, 18:16:40
Ci którzy nie znają pracują jako programiści Javy ;)
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: JCoder w Wrzesień 02, 2010, 20:01:46
Oj, zdziwiłbyś się. Akurat na programistę C++ też miałem okazję rekrutować i było b. podobnie.
Zresztą poziom projektów studenckich pisanych w C++ sam mówi za siebie.

Chcesz jakiś kawałek kodu, by się popastwić?
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: siso w Wrzesień 02, 2010, 20:22:37
@Dab
Javowy świat wcale nie musi nagminnie używać refleksji, by dobrze radzić sobie z typowymi problemami. Nietypowe faktycznie rozwiązuje się czasami nietypowymi metodami. Gdy trzymasz się zasad OOP i używasz narzędzi w sposób właściwy, refleksja jest postrzegana jako błąd projektowy. Po co miałbyś grzebać w bebechach, hę? To dlatego w większości programiści Javy nie muszą się w tym babrać i często nie znają tego tematu.

Gdy natomiast zaistnieje konieczność jej użycia, bo już nie ma innego wyjścia, każdy jest w stanie szybko się tego nauczyć, bo, jak wszystko inne, także i to jest w Javie dziecinnie proste.
Java to ekstremalnie prosty język. To stanowi wprost o jego sile.
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: Avaj w Wrzesień 02, 2010, 20:32:48
Że projekty studenckie w C++ są słabe to nie masz się co dziwić. U mnie na studiach cały C++ opierał się na tym, że 2 wykłady o STLu i przeciążaniu funkcji mieliśmy ;]
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: Kos w Wrzesień 02, 2010, 21:03:00
A u nas był ze szczegółami, podstawowe zastosowania szablonów wliczając (a wykładowca mówił że już powoli przerabia slajdy pod C++0x) :). Guru nie powstanie, ale przekazano wystarczająco dużo wiedzy do "normalnego" programowania.

(żeby nie było tak kolorowo - totalnie u mnie olano narzędzia :) zero słów na temat współczesnych IDE, systemów budowania, nawet "szczegółów kompilatora" typu include path; z plusów: obsługa valgrinda (yeah), gdb (z konsoli, yeah) i makefile (retro! yeaah :)).
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: JCoder w Wrzesień 02, 2010, 23:11:50
Cytuj
Że projekty studenckie w C++ są słabe to nie masz się co dziwić.

Zobacz, jaka jest typowo kolejność nauki języka C++, a jaka Javy. W C++ ludzie o wskaźnikach, new, delete, rzutowaniu, tablicach itp. dowiadują się stosunkowo wcześnie. Właściwie to nawet często jest to realizowane w ramach kursu C. Dosyć wcześnie ludzie dostają takie tematy do zrobienia jak zaimplementowanie listy jednokierunkowej, czy drzewa. Czyli uczą się metodą bottom-up. W pewnym momencie załapują, że w sumie mogą tak napisać teoretycznie każdy program, i zatrzymują się na tym poziomie, przenosząc poznane techniki do dużych projektów. Wychodzą z tego maszkarki, w których wszystko zależy od wszystkiego a wskaźnik pogania wskaźnik. O mechanizmach, które pozwalają pisać w sposób bezpieczniejszy (STL, Boost, wzorce projektowe) dowiadują się zwykle znacznie później. I wielu uważa to za nudy.

Z kolei w Javie jest dokładnie na odwrót. Ludzie najpierw poznają jak zrobić jakiś program z użyciem biblioteki standardowej, a dopiero później uczeni są rzeczy, w których potencjalnie mogą sobie narobić problemów tj. refleksji, przeciążania equals, wątków, JNI, pisania własnych kontenerów itp.

Inna rzecz, że nieprawdą jest, jakoby optymalny zespół to był taki, który składa się z samych guru programistów. Taki zespół pracuje niewiele lepiej niż zespół składający się z jednego, dwóch świetnych programistów + kilku przeciętnych, za to znacznie tańszych. Pilnowanie tych przeciętnych, żeby nie narobili w projekcie jakiejś poważnej biedy właśnie powinno spadać w dużej części na język / narzędzia, które zrobią to za darmo. Ktoś chce użyć pola statycznego aby ułatwić sobie dostęp do czegośtam (w środowisku wielowątkowym) - a tu Zonk, w języku nie ma pól statycznych ;) Ktoś chce sobie zrobić własny wątek, a tu bach po łapach, nie wkomituje kodu - pakiet obsługujący wątki jest zbanowany. Jeszcze inna sprawa, że zespół składający się ze zbyt wielu guru programistów może tkwić w miejscu, bo każdy będzie uważał że jego "projekt" jest jedyny słuszny...
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: Dab w Wrzesień 02, 2010, 23:30:44
Cytuj
Ludzie najpierw poznają jak zrobić jakiś program z użyciem biblioteki standardowej, a dopiero później uczeni są rzeczy, w których potencjalnie mogą sobie narobić problemów tj. refleksji, przeciążania equals, wątków, JNI, pisania własnych kontenerów itp.

Tak -- a potem wyrastają "koderzy" dla których lista i wektor to jeden pies. "Przecież przejście po jednym i drugim to O(n)!"

Cytuj
O mechanizmach, które pozwalają pisać w sposób bezpieczniejszy (STL, Boost, wzorce projektowe)

Ostatnio integrowałem język skryptowy Lua ze swoim silnikiem. Postanowiłem spróbować z gotowym wrapperem (Luabind). Jednak kiedy zobaczyłem, że do użycia go potrzeba 1500 (PÓŁTORA TYSIĄCA) nagłówków Boosta to podziękowałem -- zamierzony efekt osiągnąłem w... 400 linijkach kodu.

Dalej nie rozumiesz różnicy między silnikiem/grą a "aplikacją biznesową". W zasadzie gry to jeden z niewielu rodzajów aplikacji które przy dużym skomplikowaniu logiki muszą jednocześnie być bardzo szybkie. Użycie STL, Boosta, wzorców projektowych, enkapsulacji, stutuacji doprowadza do tego że 95% kodu to tzw. "glue code" który nic tak naprawdę nie robi. A na to w grach nie ma po prostu czasu.

Cytuj
Inna rzecz, że nieprawdą jest, jakoby optymalny zespół to był taki, który składa się z samych guru programistów.

To jest oczywiste, ale czy ktoś kto liznął szablony i dziedziczenie to od razu guru?
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: Avaj w Wrzesień 02, 2010, 23:43:43
@Dab: jak używasz STL/Boosta itp. ot tak to wiadomo, że ten kod będzie nieprzydatny. Ale np. lepiej wziąć gotowca, który na pewno działa w ciężkich warunkach niż tracić czas na pisanie własnej implementacji. A wzorce projektowe i enkapsulacja nic nie kosztują, a pomagają ogarnąć kod.
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: JCoder w Wrzesień 02, 2010, 23:51:48
Cytuj
Użycie STL, Boosta, wzorców projektowych, enkapsulacji, stutuacji doprowadza do tego że 95% kodu to tzw. "glue code" który nic tak naprawdę nie robi.

Coś w tym jest. Na pewno trzeba uważać, aby nie przesadzić z poziomem abstrakcji.
Z drugiej strony i tak najwięcej roboty ma sam silnik graficzny + fizyka, a wyższe warstwy już nie muszą być jakieś bardzo szybkie, bo liczba obiektów na których pracują jest znacznie mniejsza (LUA jest znacznie powolniejsza od wszelkich Javopodobnych wynalazków, a jednak jej używasz).
Sam fakt stosowania gotowego silnika grafiki / fizyki to już jest pewien rodzaj enkapsulacji ;)
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: Dab w Wrzesień 03, 2010, 00:01:33
Cytuj
Z drugiej strony i tak najwięcej roboty ma sam silnik graficzny + fizyka, a wyższe warstwy już nie muszą być jakieś bardzo szybkie, bo liczba obiektów na których pracują jest znacznie mniejsza.

No widzisz. Problem w tym że wyższe warstwy też mają co do roboty. Logika/mechanika gry to zazwyczaj bardzo pokaźny kawałek kodu, a czy pracuje na mniejszej ilości obiektów? Nie powiedziałbym, to renderer może sobie wyciąć wszystko czego nie widać -- logika zasadniczo musi przetwarzać wszystko (a przynajmniej sprawiać takie wrażenie). Dodatkowo weź pod uwagę że logika musi uwzględniać interakcje między obiektami, czego renderer zasadniczo nie robi (no, chyba że doczekamy się RTGI).

Na wszystko jest miejsce i czas. W pracy (aplikacje iPhonowe) mogę sobie pozwolić na parę dodatkowych wywołań żeby mieć np. kilka kontrolerów pod wspólnym interfejsem. W porównaniu do czasu oczekiwania na dane z sieci te kilka wywołań więcej jest nieodczuwalne -- zresztą sam język i framework są dość ciężkie. Ale gry to inna bajka. Tutaj na "virtual void Draw()" daleko nie zajedziesz :)

Cytuj
(LUA jest znacznie powolniejsza od wszelkich Javopodobnych wynalazków, a jednak jej używasz).
Jesteś pewien? :) http://shootout.alioth.debian.org/u32/lua.php (pomijam już rozmiar biblioteki i łatwość integracji Lua&C++ z Java&C++)
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: yarpen w Wrzesień 03, 2010, 00:03:57
Cytuj
Użycie STL, Boosta, wzorców projektowych, enkapsulacji, stutuacji doprowadza do tego że 95% kodu to tzw. "glue code" który nic tak naprawdę nie robi.

Coś w tym jest. Na pewno trzeba uważać, aby nie przesadzić z poziomem abstrakcji.
Z drugiej strony i tak najwięcej roboty ma sam silnik graficzny + fizyka, a wyższe warstwy już nie muszą być jakieś bardzo szybkie, bo liczba obiektów na których pracują jest znacznie mniejsza (LUA jest znacznie powolniejsza od wszelkich Javopodobnych wynalazków, a jednak jej używasz).
Skad takie teorie? Obiektow fizycznych/renderowanych jest w wiekszosci przypadkow duzo mniej niz tych, ktorymi musi sie zajac AI/logika.
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: bies w Wrzesień 03, 2010, 02:09:10
Java to ekstremalnie prosty język. To stanowi wprost o jego sile.
Omów różnicę w dostępie do pamięci z volatile przy przejściu z 1.4 na 1.5. Ekstremalnie prosty, tia...
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: JCoder w Wrzesień 03, 2010, 10:20:17
@bies: przykład z volatile jest o tyle nietrafiony, że:
1. programowanie wątków zawsze było, jest i będzie trudne, niezależnie od języka
2. C++ ma pod tym względem o wiele większe grzechy; łącznie z przenikaniem stanu do osobnego wątku poprzez zmienne, które są częścią współdzielonej struktury, a same nie są współdzielone.
3. 1.4 to prehistoria; to tak jakbym powiedział, że GCC 2.95 nie umiało kompilować template'ów.

@yarpen:
Cytuj
Skad takie teorie? Obiektow fizycznych/renderowanych jest w wiekszosci przypadkow duzo mniej niz tych, ktorymi musi sie zajac AI/logika.

Oh, really? A jeden renderowany obiekt fizyczny to zapewne jest jeden trójkąt, tak? :D
Slajdy Carmacka o UE potwierdzają to co napisałem. Nie mówiąc o tym, że AI wielu niewidocznych obiektów nie musisz analizować co klatkę.

@Dab:
Jak się chce wykazać, że Java jest powolna, to się robi porównania do Java z opcją -Xint. Tyle, że na taką socjotechnikę nas nie nabierzesz.

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=lua&lang2=javasteady
Ja tu widzę różnice 15x-50x na niekorzyść LUA.
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: Liosan w Wrzesień 03, 2010, 10:30:22
3. 1.4 to prehistoria; to tak jakbym powiedział, że GCC 2.95 nie umiało kompilować template'ów.
I oba argumenty byłyby równie dobre - ostatnio gadałem z kolesiem, który pisał soft na jakieś urządzenia podłączane do telewizorów, i tam mieli tylko javę 1.3 ;)

Oh, really? A jeden renderowany obiekt fizyczny to zapewne jest jeden trójkąt, tak? :D
Slajdy Carmacka o UE potwierdzają to co napisałem. Nie mówiąc o tym, że AI wielu niewidocznych obiektów nie musisz analizować co klatkę.
Nie uważasz, że nierenderowanie niewidocznych obiektów jest jednak trochę prostsze niż nieanalizowanie AI niewidocznych obiektów? ;)
Zresztą, pomijasz argument Daba - obiekty fizyczne i logiczne to przede wszystkim interakcje par obiektów, w renderingu pod tym kątem przetwarza się tylko grupy obiektów.

Liosan
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: bies w Wrzesień 03, 2010, 10:38:53
@bies: przykład z volatile jest o tyle nietrafiony, że:
1. programowanie wątków zawsze było, jest i będzie trudne, niezależnie od języka
Trafiony. Opis działania volatile jest trudny. I to nie chodzi o wątki bo synchronized jest o rząd wielkości łatwiejszy do zrozumienia niż DCL-pattern na przełomie 1.4/1.5. Ale żeby to wiedzieć trzeba napisać w Javie kiedyś coś więcej niż FooSmooBullshit extends HttpServlet.

Co do C++: ,,a u was biją murzynów'' -- nie wspominałem o C++.

3. 1.4 to prehistoria; to tak jakbym powiedział, że GCC 2.95 nie umiało kompilować template'ów.
Primo umiało (jakoś). Secundo circa 50%*) firm z polskiego (a pewnie na świecie też, ale klientów mam zazwyczaj w Polsce) Top500 używa 1.4 na serwerach. Są tacy co używają nawet 1.1 (bez JITC) z powodu specyficznego sprzętu i JVM. Ale znów to zazwyczaj nie jest FooShmooBullshit.

*) Tj. o tych firmach wiem. Ile naprawdę nie mam pojęcia, te procenty można traktować jako dolną granicę.
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: JCoder w Wrzesień 03, 2010, 11:04:11
Cytuj
Nie uważasz, że nierenderowanie niewidocznych obiektów jest jednak trochę prostsze niż nieanalizowanie AI niewidocznych obiektów? Wink
Zresztą, pomijasz argument Daba - obiekty fizyczne i logiczne to przede wszystkim interakcje par obiektów, w renderingu pod tym kątem przetwarza się tylko grupy obiektów

Tak, tylko że mimo wszystko w renderingu nadal masz miliony obiektów, a w AI kilka rzędów mniej. Co do interakcji, to jeśli musisz przetwarzać każdą parę obiektów, aby uwzględniać ich interakcje to masz coś zrąbane z algorytmiką. Najczęściej obiekty reagują z obiektami sąsiadującymi. Czyli koszt jest nadal proporcjonalny do łącznej liczby obiektów.

Poza tym LUA jest jakieś 15-50x powolniejsza niż Java/C/C++, a mimo to jest bardzo popularna do realizacji najwyższych warstw gier.  Dlatego słowa o narzutach wywołań wirtualnych czy innych abstrakcyjnych konstrukcji w C++ (gdzie one są stosunkowo tanie) w ustach kogoś, kto wykorzystuje LUA w swoich produkcjach, brzmią co najmniej śmiesznie. A taki był oryginalny kontekst mojej wypowiedzi (a nie licytowanie się o liczbę obiektów czy szybkość LUA ws. reszta świata). Są miejsca w grze, gdzie wyższy poziom abstrakcji jest bardzo wskazany, nawet kosztem niewielkiego narzutu na wywołanie wirtualne czy inną wartwę pośrednią.

@bies: Stare wersje JDK są używane, tylko nie bardzo widzę sens porównywać je z technologiami współczesnymi. Jeśli robimy takie wybiegi, to może porozmawiamy o programowaniu w C++ 15 lat temu? Na niektóre platformy jak masz GCC 2.95 to jesteś farciarz. Nadal wiele projektów musi się kompilować na zabytkach, na które jedyne co jest to kompilator C z klasami, który wysypuje się przy obsłudze wyjątków a o szablonach w ogóle nie słyszał. Ilość problemów, na jakie trzeba być przygotowanym, jest wieloktrotnie wyższa niż wszystkie zmiany specyfikacji Java 1.1 do 6. Kod pisany pod 1.1 nadal w większości przypadków uruchamia się pod 6.0.

Cytuj
Primo umiało (jakoś)

"Jakoś" jest tu kluczowym słowem. Kompilowało najprostsze konstrukcje, czasem produkowało błędny kod.

Cytuj
Co do C++: ,,a u was biją murzynów'' -- nie wspominałem o C++.

Problem z DCL, który opisujesz dla Javy pre 1.5, jest jeszcze większy w C++ i wielu innych językach. Generalnie DCL jest "fundamentally broken" i nie powinno się tego w ogóle używać.

http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf

Cytuj
Nothing you do can alter the fundamental problem: you need to be able
to specify a constraint on instruction ordering, and your language [C++] gives you no
way to do it.

W Java 1.5 to jest rozwiązane, ale i tak nie ma sensu stosować DCL, bo Java natywnie obsługuje singletony i są one thread-safe.
DCL musieli wymyśleć programiści C++. Masz pretensje, że niedziałający wzorzec w C++, nie działa również w Javie < 1.5?

Cytuj
Finally, DCLP and its problems in C++ and C exemplify the inherent difficulty
in writing thread-safe code in a language with no notion of threading (or
any other form of concurrency). Multithreading considerations are pervasive,
because they affect the very core of code generation. As Peter Buhr pointed
out [3], the desire to keep multithreading out of the language and tucked away
in libraries is a chimera. Do that, and either (1) the libraries will end up putting
constraints on the way compilers generate code (as Pthreads already does) or
(2) compilers and other code-generation tools will be prohibited from performing
useful optimizations even on single-threaded code. You can pick only two of
the troika formed by multithreading, a thread-unaware language, and optimized
code generation. Java and the .NET CLI, for example, address the tension by
introducing thread-awareness into the language and language infrastructure,
respectively [8, 12].
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: bies w Wrzesień 03, 2010, 12:28:43
Odstaw chochoły, nie rozmawiamy o C++. Nie rozmawiamy o DCL (to przykład na którym dobrze widać problem z membarriers). Rozmawiamy o tym, że Java jest trudna. Innym przykładem byłby np. tuning GC -- też rzecz o której typowy javowy średniak nie ma bladego pojęcia. A właściwie to w ogóle nie rozmawiamy bo wciąłeś się w odpowiedź nie do siebie...

A jeśli już koniecznie chcesz dowiedzieć się czegoś o C++: w C++ masz rozszerzenia kompilatora (w tym __asm__ __volatile__) które pozwalają (od wielu, wielu lat) napisać DLCP poprawnie na dowolną platformę. Standard języka nie precyzuję wątków, środowiska (system, kompilator, runtime) o bardzo dawna.

A jak już piszesz o 2.95 to dawaj konkrety -- na jakie platformy używa się jeszcze 2.95?
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: Dab w Wrzesień 03, 2010, 12:33:26
Cytuj
Tak, tylko że mimo wszystko w renderingu nadal masz miliony obiektów, a w AI kilka rzędów mniej.

Jakie miliony, kolego, chyba żeś się z komputera kwantowego urwał. Jeżeli liczysz trójkąt jako obiekt to fajnie -- może w logice/AI liczmy każdy bajt jako obiekt? :D

Cytuj
Jak się chce wykazać, że Java jest powolna, to się robi porównania do Java z opcją -Xint. Tyle, że na taką socjotechnikę nas nie nabierzesz.

Nie znam się na Javie i w szczególności nie mam pojęcia co to za opcja. W każdym razie moje doświadczenia jakoś nie pokazują że Lua jest szczególnie wolna a Java szczególnie szybka. Weź pod uwagę, że 99% skryptów to:

sprawdź globalną zmienną
jeżeli 0 to pokaż komunikat
jeżeli 1 to
{
ustaw animację Foo
przesuń światło Bar
}


I teraz weź pod uwagę że sam narzut na wywołanie machiny JVM będzie dużo większy niż wywołanie kilku funkcji Lua. Jako że trzymam sobie kod źródłowy Lua to wiem że wywołanie skryptu Lua nie przekracza zagnieżdżenia 10 funkcji C -- powiesz to samo o Javie? :) Szybkość wykonywania samego skryptu nie jest istotna (no chyba że ktoś liczy w nich fizykę cząsteczkową -- powodzenia).
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: JCoder w Wrzesień 03, 2010, 13:09:04
Cytuj
Jako że trzymam sobie kod źródłowy Lua to wiem że wywołanie skryptu Lua nie przekracza zagnieżdżenia 10 funkcji C -- powiesz to samo o Javie?

Wywołanie Java->C++ zwykle jest 4-10 razy wolniejsze niż wywołanie Java->Java lub C++ -> C++. Więc remis.

Cytuj
Rozmawiamy o tym, że Java jest trudna.

Tiaa. Tylko jako przykład podałeś coś, co:
1. W C++ jest jeszcze trudniejsze.
2. W Javie nie ma racji bytu, bo konstrukcja singletonów jest przewidywalna. Nie mówiąc o tym, że problem od 1.5 w górę nie występuje.

GC trudne w strojeniu? Żartujesz. GC stroi się tak:
1. ile mamy RAMu? 512 MB. Ok to dajemy: -Xmx512M, koniec roboty.
2. hmm, zacina się -> spróbuj innego GC
3. zacina się dalej -> spróbuj innego GC
4. wypróbowałeś wszystkie GC i się nadal zacina? To nie GC. Skwasiłeś implementację. Popraw i wróć do 2.

Strojenie GC jest trudne tylko wtedy, gdy chcesz za wszelkj cenę wycisnąć z JVM aby używał minimum RAMu i równocześnie chodził szybko. Ale nadal nie jest to trudniejsze niż napisanie po prostu efektywnego kodu.

Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: bies w Wrzesień 03, 2010, 13:52:33
Cytuj
Rozmawiamy o tym, że Java jest trudna.
Tiaa. Tylko jako przykład podałeś coś, co:
1. W C++ jest jeszcze trudniejsze.
A ja nie twierdziłem, że w Javie jest trudniejsze od C++. W ogóle nie pisałem o C++. Po co mi C++ w wyjaśnianiu Siso, że Java jest trudna? Masz jakiś problem z C++, że wszędzie widzisz krzyżyki. Świat nie kończy się na C++. O co Ci chodzi z tym C++?

2. W Javie nie ma racji bytu, bo konstrukcja singletonów jest przewidywalna. Nie mówiąc o tym, że problem od 1.5 w górę nie występuje.
Kurde, potrafisz w ogóle czytać? Trudny jest opis zmiany działania volatile w 1.4 i 1.5. Sam opis działania volatile jest w ogóle trudny (bo nagle okazuje się, że trzeba wiedzieć co to jest cache procesora na którym działa JVM). DLCP to tylko przykład -- volatile używa się w wielu innych przypadkach.

GC trudne w strojeniu? Żartujesz. GC stroi się tak:
1. ile mamy RAMu? 512 MB. Ok to dajemy: -Xmx512M, koniec roboty.
2. hmm, zacina się -> spróbuj innego GC
3. zacina się dalej -> spróbuj innego GC
4. wypróbowałeś wszystkie GC i się nadal zacina? To nie GC. Skwasiłeś implementację. Popraw i wróć do 2.

Strojenie GC jest trudne tylko wtedy, gdy chcesz za wszelkj cenę wycisnąć z JVM aby używał minimum RAMu i równocześnie chodził szybko. Ale nadal nie jest to trudniejsze niż napisanie po prostu efektywnego kodu.
Skąd Ty się urwałeś? Masz serwer aplikacyjny pisany przez ostatnie 10 lat przez niezliczone rzesz programistów. Masz instrukcje wdrożenia i noty do instrukcji tak duże, że cykl szkoleniowy dla wdrażających zajmuje ponad miesiąc nie licząc żadnego doświadczenia. I masz np. notę o wdrożeniu na JVM na Solarisie na procesorach Niagara i strojeniu GC pod 64-rdzeniowy procek. Co chcesz napisać od nowa? Masz w ogóle pojęcie jak wygląda produkcyjne używanie Javy w dużych systemach (obsługujących > 2K użytkowników)?

Googlnij sobie za ,,JVM GC tuning'' -- powinieneś dostać dokumenty przynajmniej dla Oracle i IBM.
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: siso w Wrzesień 03, 2010, 14:51:14
Bies, no i po co tak się od razu denerwować? :)

Volatile nie było i nie jest nagminnie używanym feature'm języka. Rozmawiamy o twórcach aplikacji w końcu czy o twórcach frameworków, specjalizowanych bibliotek albo wręcz "bogach" kodujacych trzewia JVM? Ci ostatni to nawet nie w Javie piszą, zresztą. Wydawało mi się, że rozmawiamy o "programistach aplikacji", których jedynym celem powinno być skupienie się na spełnieniu wymagań projektowych przy zastosowaniu wszelkich możliwych środków jakie mogą to zadanie ułatwić. Pozwoliłem sobie wcześniej powołać się na taką właśnie "większość".

Jeśli volatile przed 1.5 zachowywało się odrobinę inaczej niż teraz i dodamy do tego, że było może słabo udokumentowane, a do tego jest to ciężki kawałek chleba w ogólności - to trudno. Tak jest i koniec. Ale ten jeden przykład nie pokazuje nijak, że cały język jest trudny. Bo nie jest. 99% zastosowań (że tak sobie z własnego doświadczenia oszacuję) wymaga od programisty znajomości bardzo prostych rzeczy. Piszę w Javie zawodowo bez mała już 6 lat i do tej pory miałem może jeden raz (no, niech dwa, już trudno) konieczność użycia volatile. Przyczyna? Grupy projektowe siedzą i myślą i zadają zęby tylko po to, by reszta mogła pisać komponentowe aplikacje uruchamiane w gotowych, wyspecjalizowanych serwerach aplikacji, które mają wyznaczony standardem obowiązek zapewniania bezpieczeństwa wątków, jeśli takie są wymagania. I nie dotyczy to tylko volatile. Z pozostałymi rzeczami - a zaczęło się od refleksji - jest podobnie.

W Javie schody zaczynają się zazwyczaj nie na poziomie języka, a na poziomie architektur. To jest największa bolączka javowego świata. Ale i na to są sposoby.

Jeszcze kwestia legacy code / legacy systems...
Jak masz legacy system chodzący na jakimś archaicznym/egzotycznym sprzęcie/sofcie i musisz go rozwijać o nowe feature'y, to lepiej pakuj walizki i wiej gdzie pieprz rośnie. Jedyne uzasadnienie biznesowe dla utrzymania takich systemów to ich (najczęściej wątpliwej już jakości) funkcjonalność, której "obecnie nie ma czym zastąpić". Bzdura - zawsze są lepsze alternatywy. Lub też "nie da się, bo wymiana jest za droga". Następny bullshit - utrzymanie starego gówna i tak w końcu okazuje się droższe, zaś decyzja o wymianie zapada, gdy najwyższy management zorientuje się łaskawie, jak bardzo jest w d..pie i że trzeba było tą decyzję podjąć trzy lata temu. Jeśli właściciel systemu nie ma poczucia beznadziejności sytuacji i ciągle wymaga łatania i dokładania nowych feature'ów, optymalizacji i Bóg wie czego jeszcze, wtedy patrz: uwaga o walizkach.

W moim skromnym doświadczeniu zawodowym jeszcze nie spotkałem nikogo, komu na zdrowie wyszło by w perspektywie tuningowanie GC pod jakieś dziwactwa czy łatanie jakichś choćby dziur w bezpieczeństwie tylko dlatego, że management nie chce wyłożyć kasy na przebudowę. Nie po to mamy ciągle rozwijające się standardy, żeby tkwić w średniowieczu. Albo używać produktów niszowych. Zobacz, co robi Google w kwestii serwerów - nawet serwerów nie używa, tylko ogólno dostępne, zwykłe klocki. I współczesny soft.
A jeśli nawet - są jeszcze ludzie, którzy te stare systemy pisali. Niech oni się martwią, jak to dzisiaj łatać. A jeśli sam chcesz się o to martwić - po to masz dokumentację i soft właściwy dla danego przypadku. Jeśli nie masz -> walizki.

Mówię tu oczywiście o Javie EE. Jeśli ktoś chce w SE pisać jakiś zaawansowany system, to pozostaje mu tylko współczuć. Zdecydowanie nie do tego to służy. A próba maintenace'u czegoś o wieloletniej historii to już zwyczajne proszenie się o seppuku. Przez umpa - pumpa, żeby nie było za łatwo.
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: JCoder w Wrzesień 03, 2010, 16:13:36
@bies: w każdym języku są jakieś haczyki, czy elementy trudniejsze do pojęcia. Nie chcesz porównań do C++, proszę bardzo. W Pythonie, Rubym i innych też znajdziesz kilka rzeczy, które będą względnie trudne do zakumania - szczególnie jeśli chodzi o kwestie programowania współbieżnego. Po prostu jest to trudne z definicji i tyle. Siso chodziło o to, że Java jest względnie jednym z najprostszych języków do kodowania aplikacji i ja to w pełni potwierdzam. Ale nie oznacza, to że byle debil może w tym programować, bo kończy się to źle. Tak samo jak w PHP.

Odnośnie volatile: w ciągu 7 lat użyłem może ze dwa czy trzy razy. Refleksji nieco częściej, ale tylko w kodzie jakiegoś frameworku. Zwykły koder w ogóle nie powinien się dotykać do wątków, bo predyspozycje do zakumania wątków / pisania silników ma może 2% programistów i to niezależnie od języka.

Cytuj
Masz w ogóle pojęcie jak wygląda produkcyjne używanie Javy w dużych systemach (obsługujących > 2K użytkowników)?

2K ???  Chciałeś chyba napisać 2M? :D

A wygląda to najczęściej tak, że serwery aplikacyjne (Java) się nudzą, a baza (C lub C++) się poci. Strojenie GC to pikuś przy strojeniu bazy.

Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: siso w Wrzesień 03, 2010, 16:29:56
Cytuj
A wygląda to najczęściej tak, że serwery aplikacyjne (Java) się nudzą
A jak przestają się nudzić, to się im dokłada "braci" ;) Nawet 50+ fizycznych maszyn serwerowych na jedną skalującą się aplikację to nie jest dzisiaj żaden problem.
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: Liosan w Wrzesień 03, 2010, 16:47:27
A wygląda to najczęściej tak, że serwery aplikacyjne (Java) się nudzą, a baza (C lub C++) się poci. Strojenie GC to pikuś przy strojeniu bazy.
Bo taniej dołożyć nowy serwer niż zmusić przekonać poprosić programistów aplikacji by napisali ją wydajnie?

Liosan
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: JCoder w Wrzesień 03, 2010, 17:06:11
Czasem tak, a czasem nie. Zawsze się kalkuluje koszty. Jeśli można poprawić wydajność aplikacji korygując jakieś oczywiste spowalniacze, to się robi to w pierwszej kolejności. Serwery wbrew pozorom też niemało kosztują. Jeśli jednak optymalizacja miałaby polegać na posadzeniu gościa na miesiąc lub dwa, to czasem taniej dostawić parę serwerów.
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: siso w Wrzesień 03, 2010, 17:08:00
A wygląda to najczęściej tak, że serwery aplikacyjne (Java) się nudzą, a baza (C lub C++) się poci. Strojenie GC to pikuś przy strojeniu bazy.
Bo taniej dołożyć nowy serwer niż zmusić przekonać poprosić programistów aplikacji by napisali ją wydajnie?

Liosan
Zdecydowanie taniej.
Taniej niż zmusić przekonać poprosić programistów JVM/serwera aplikacji/frameworków/bibliotek by napisali swoje rzeczy wydajniej.
A także taniej, kiedy czas programistów aplikacji jest wykorzystywany do zaspokajania celów biznesowych, zamiast jakichkolwiek innych, które da się załatwić innymi metodami.
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: Dab w Wrzesień 03, 2010, 17:09:32
No fajnie. A teraz wracamy do gamedevu. Rozumiem że minimalne wymagania gry na poziomie "farma 40 serwerów" was przekonują? :D
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: siso w Wrzesień 03, 2010, 18:05:37
Niech pomyślę...
Tak, na 40 już się powinno dać coś sensownego zapuścić ;)
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: JCoder w Wrzesień 03, 2010, 18:24:37
Witcher Versus przy ponad milionie użytkowników potrzebował 4 serwerów... :D
Z czego serwery aplikacyjne rzadko przekraczały 10% użycia CPU. A 4 tylko dlatego, żeby zapewnić odpowiedni poziom niezawodności w przypadku ewentualnego padu sprzętu. Jak padnie jeden serwer, aplikacja chodzi dalej.
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: bies w Wrzesień 03, 2010, 19:07:20
Primo nie chodziło mi o 2M tylko 2K ale jednoczesnej pracy -- wystarczy. Secundo nie piszę o legacy systems tylko (min.) o EPR SAP. Aktualnie wspierana wersja (7.0.1) wymaga JVM 1.4, nowa wersja (7.1) wymaga JVM 1.5 ale nikt jeszcze na poważnie jej nie używa produkcyjnie. Nie ma ,,lepszych alternatyw'' dla SAP. Z tego samego podwórka jest optymalizacja GC pod Niagarę. Optymalizacja Oracle'a czy systemu to inna bajka -- robi się wszystko. Tertio 50 fizycznych maszyn to jest problem -- mówi się, że to małe koszta ale policzenie sobie 50 blade'ów od IBM (czy HP, nie jestem wybredny) wraz z chassis, systemami i kosztem zasilania sumuje się ładnej kwoty.

Piszecie, że Java jest łatwa przy prostych projektach. Każdy język jest łatwy przy prostych projektach. Sam potrafię ustalić taki standard, że C++ też będzie prostym językiem (pisaliście kiedyś aplikację okienkową w Qt -- banał). Niestety to nic nie znaczy. Szybko się okazuje, że trudne projekty są trudne w dowolnym języku.
Tytuł: Odp: Kilka pytań dotyczących javy
Wiadomość wysłana przez: JCoder w Wrzesień 03, 2010, 19:42:27
Cytuj
Szybko się okazuje, że trudne projekty są trudne w dowolnym języku

Trudne projekty są trudne, ale w pewnych językach nawet trudniejsze. :P
Jak masz trudny projekt, to cokolwiek co zmniejsza Ci ilość problemów choćby trochę, to dobra rzecz.
Java jednak dosyć mocno ułatwia pisanie właśnie dużych projektów; gdzie jest dużo osób o różnym poziomie umiejętności.