Google pokazał Androida!

Co maja klapki do dostrzegania ilosci sprzedanych egzemplarzy? To, ze iPhone ma szanse stac sie w ciagu najblizszego pol roku najlepiej sprzedajacym sie telefonem jasno pokazuje, ze "otwartosc" wiekszosc klientow ma gdzies.

Otwartość, zamkniętość, półotwartość – wszystko to większość klientów ma gdzieś. To co piszesz o iPhone można odnieść do iPoda i innych iProduktów ze stajni Apple. Większość ludzi idzie za reklamą, modą, i tym co mają znajomi. Większość z nich ma głęboko gdzieś co siedzi w środku, byle by działało i ładnie wyglądało. Działać, działa, a że ładnie wygląda – o tym chyba nie muszę nikogo przekonywać, bo produkty Apple'a mają niezły "dizajn".

@rjc: Ano maja. I funkcjonalnosc tez maja fajna – nie maja bajerow w rodzaju obslugi niszowych formatow zapisu, ale to, co ma robic odtwarzacz MP3 – od sposobu wyszukiwania muzyki i zarzadzania nia, az po czas pracy miedzy ladowaniami akumulatora – robia lepiej od konkurencji. Podobnie z iPhonem. A iPhone to ich pierwsze podejscie, wiec nalezaloby go oceniac z pewna rezerwa.

Jesli otwartosc naprawde okaze sie istotna zaleta, to Apple po prostu otworzy iPhona. Co za problem wypuscic SDK, ktore dotychczas bylo uzywane tylko wewnatrz firmy?

Tak naprawde Android moze przebic sie na dwa sposoby. Po pierwsze, cena – jesli Chinczycy zaczna produkowac badziewne, ale tanie telefony, to swoj kawalek rynku ugryza, tak jak w odtwarzaczach MP3. Po drugie, Google ma sile i pewne rzeczy moze metodami zwykle kojarzonymi z Microsoftem przepchnac.

Microsoft zwykle nie kojarzy się mi się z Open Source. :]

z jednej strony przyklad bardzo zabawny, z drugiej…

Java właśnie nie zmusza człowieka do myślenia

Ale bredzisz to Ty dziś 3-po-3

Wez sobie wsadz w d…ten swoj dotNet. Java rzadzi i jest pomocnym narzedziem ludzi myslacych.

Zaadaptowanie Javy do tego projektu to genialny ruch ze strony GG. Tak trzymac!!!

.NET to kopia Javy więc nie wiem dlaczego miał by być szybszy, a już na pewno nie jest bardziej przenośny (kompilacja programów do EXE-PE o przenośności bynajmniej nie świadczy).

Java to o wiele bardziej poważne rozwiązanie, jej przenośność została sprawdzona i na przestrzeni lat wiele błędów zostało poprawionych. Koledzy którzy używają .NET mówią, że jest tam bardzo dużo bugów i tracą sporo czasu na głupie ich obchodzenie (może i aplikacje pisze się szybko, ale żeby jeszcze działały tak jak powinny…)

"Java właśnie nie zmusza człowieka do myślenia"

Każdy język programowania zmusza człowieka do myślenia. Nie ważne czy to LOGO, Basic, Java, C, Asm, Prolog – każdy z nich, tylko w niektórych dodatkowo musisz się skupiać na technikaliach nie związanych z logiką działania Twojego programu. Java ma tę zaletę, że w niewielkim stopniu trzeba się skupiać na technikaliach i kwestiach nie związanych z logiką programu, który piszesz – ale wcale to nie oznacza, że nad tą logiką nie musisz myśleć.

Co do prędkości, to telefonik z androidem może mieć jakiegoś procka, który 90% kodu Javy wykonuje sprzętowo. Są wersje procesorów ARM, które to potrafią – instrukcją maszynową o mnemoniku bj skacze się do kodu Javy .

@mario: Jesli .NET jest kopia Javy, to Java jest kopia Smalltalka. Srednio udana. ;-P

Odnosnie powagi rozwiazan – znam kilkanascie osob, ktore w ciagu ostatnich paru lat przeszly z pisania pod J2EE na .NET. Nie znam zadnej, ktora przeszla w druga strone. Z owych kilkunastu raptem dwie nie uwazaja (jeszcze , ze pod .NET pisze im sie lepiej.

Widac mamy diametralnie rozne odczucia.

Pamietam jak gdzies w okolicach roku 2000, rowniez na linuxnews.pl wychodzily rozne trole wieszczace upadek javy i sukces .net w 3 lata. Mamy rok 2007, java ma sie swietnie, a ja nie zauwazam obecnosci .netu przynajmniej na rynku aplikacji webowych. Nie jest to autosugestia bo ja nie jestem zawodowym developerem i jesli o mnie chodzi to moga sabie te tiery pisac nawet w pythonie. Cieszy jednak fakt ze malo kto dal sie zlapac na ten badziew z m$.

I tu (niestety) się mylisz. Dużo instycucji, firm (i to bardzo poważnych) migruje na .NET-a. Niestety ale .NET jest dla nich po prostu tańszy.

I właśnie dzięki .NET MS w serwerach(szczególnie www) ma coraz szybszy wzrost.

A co do javy i C# to w zasadzie są dość podobne oczywiście jeż też J#

@mzobniow: Jakbys byl zawodowym developerem, to bys zauwazyl.

Upadek COBOL-a tez wieszczyli dawno temu. I tez w sumie COBOL ma sie swietnie, dwadziescia lat pozniej. Ciekawe, gdzie bedzie Java za dwadziescia lat?

Nie jestem developerem ale tez czasem developuje i pracuje z developerami. Jesli zapytacie ktory jezyk jest najwiekszym wygranym w segmencie web aplikacji to powiem ze php. Jest znacznie tanszy od javy i .netu niestety i dlatego robi tu furore. dotNetu, jak juz pisalem, prawie w ogle nie tu nie wiedze (Niemcy) no ale moze u was sa inne mody.

@mzobniow: Bardziej chodzi o segment rynku niz o kraj. PHP to "klasa ekonomiczna", .NET – nie.

Ja oczywioscie pisze o segmencie ASP i innych firm ktorych modele biznesowe bezposrednio zaleza od technologi. Mysle ze ten segment jest najbardziej miarodajny – tu zreszta najwiecej sie dzieje w tej materi. W tym wlsnie segmencie php rzadzi, a potem java.

Inee segmenty: np. banki i korporacje maja czasem .net na swoich wewnetrznych systemach, ale gdy potrzebuja niezawodnej aplikacji wystawionej na Swiat, to oczywiscie siegaja po outsourcing lub consulting i tak wracamy do php i javy.

w takim przypadku wraca sie do javy, ale juz nie do php…

trash: .net to wlasnie klasa ekonomiczna. moze i w .necie latwiej/szybciej cos napisac ale kto w powaznej firmie zdecyduje sie na serwer oparty o ms? niby z .net mozna sie polaczyc do normalnych baz, ale "programisci" .netowi dosc mocno sa przywiazani do mssql, a kto to w powaznym zastosowaniu ustawi jak baze danych?

jak takie rozwiazania sie skaluja?

w przypadku javy – mimo ze wydaje sie bardziej ociezala niz .nety, dosc latwo mozna zaplanowac rozwoj srodowiska serwerowego, w przypadku wzrastajacego zapotrzebowania na moc obliczeniowa. j2ee zarowno w przypadku suna, ibma, oracla – jest jak najbardziej do tego przygotowana/sprawdzone/wdrazane z wieloletnim doswiadczeniem.

podobnie w przypadku baz danych – oracle@hpux, oracle@aix, db2@aix – tu masz jasne plany rozwoju, np. poprzez zwielokratnianie ilosci prockow (np. hp superdome – gdyby tylko orakiel pod tym tak czesto nie sral ora-00600 ).

Uwierz ze nader czesto niestety do php. Przyznam ze ostanio czesto spotyka sie rowniez model: interface w php+middleware w javie. Poprostu czysty rachunek ekonomiczny. Za wyplate jednego dobrego programisty javy zatrudnia conajmniej dwoch stikaczy php i czesto nie wazna jest tu jakos produktu koncowego.

Dodaj jeszcze ze ci stukacze od PHP są każdy 2x bardziej wydajnego od tego wydajnego programisty Javy …

Póki on napisze te 50 linii na każdy drobiazg, poki skompiluje, zdeplojuje i zrobi masę innych rzeczy to

minie godzina …

Tymczasem gostek od PHP poprawi ten drobny babol w 45 sekund ….

Sorry ale 90% zastosowań na rynku to są proste rzeczy do których PHP (+pewnie Zend) spokojnie wystarczy …

Byle mieć dobrą bazkę pod spodem która sobie poradzi z masą prostych zapytań …

@trasz: "Jesli .NET jest kopia Javy, to Java jest kopia Smalltalka. Srednio udana. ;-P"

Java to nie tylko język + API, ale też środowisko uruchomieniowe – maszyna wirtualna. Popatrz na rozkazy bytecodeu Javy i wirtualnej maszyny CLR (.NET) – podobieństwo jest ogromne, praktycznie ponad 90% rozkazów jest takich samych, albo bardzo podobnych. Warto dodać że MS zdecydował się na własną maszynę wirtualną po tym jak przegrał proces z Sun Microsystems o Javę – dokładniej o wprowadzenie niezgodnej ze standardem VM Javy, wiadomo jakie to miało by skutki dla rynku podczas gdy ta Java była by standardem w Windowsach – zresztą swego czasu czat onet'u działał tylko na MSJavie. .NET to kopia Javy + odwet za przegrany proces i tyle.

Jesteś w błędzie… też tak uważałem, aż nie sprawdziłem "na sobie". Może nie nadaje się do sekcji krytycznych, gdzie naprawdę trzeba pojechać low-level, ale gwarantuje Ci, mechanizmy języka są już znacznie szybsze niż kiedyś. Najważniejsze jest to, że 2 największe zmory programistów C i C++ są ubite: Memory Leak i Core Dumped…

Memory Leak ? I Core Dump ?

ha, znam dużą aplikację Java od jednej z największych polskich firm developerskich i….

Od memory Leak aż się roi … nie na najniższym poziomie ale na wyższym poziomie – masy powiązanych obiektów z którymi GC sobie nie radzi … po 3h aplikację należy restartować na maszynach z

@IRo

Kompletna bzdura. Żeby zrobić wyciek pamięci w Javie, wystarczy (trywialny przykład) napisać stos i zapomnieć o ustawianiu na null referencji w metodzie pop (do zdejmowania ze stosu obiektów). Odśmiecacz pomaga w zarządzaniu pamięcią, ale nie jest panaceum na wszystkie problemy związane z zarządzaniem pamięcią w Javie.

public Object pop() {

if (size==0) throw new EmptyStackException();

Object result = elements[--size];

elements[size] = null; //bez tej linijki wystąpi wyciek pamięci

return result;

}

Pełny kod w książce pt. Efektywne programowanie w języku Java, str. 24, Helion.

Z tym kodziem t_ziel to nie do końca prawda. Tzn ten "wyciek" (jak to nazywasz) to po prostu obiekt, do którego nadal istnieją odnośniki w systemie, więc nie może być poddany działaniu garbage collectora. W momencie gdy ostatni odnośnik do result zniknie (np przez wyjście z bloku w którym ten obiekt był stworzony), pamięć zostanie odzyskana.

To się ma nijak to prawdziwych wycieków z C, gdzie nie zdekonstruowany obiekt do którego nie ma się już jak odwołać wisi w próżni.

Co oczywiście nie zmienia faktu że w Javie jak w innych językach programować należy z głową.

Jeśli trzymamy tysiące odnośników do dużych obiektów to nie ma się co dziwić że nasza aplikacje powoduje swapowanie

a jesli zrobimy cos takiego:

obiekt A z referencja na obiekt B, obiekt B z referencja na obiekt A a nastepnie porzucimy posiadane referencje do obiektow A i B

GC poradzi sobie z tym? w koncu na obiekt A i na B wskazuja jakies referencje.

tradycyjny przyklad… garbage collector nie ma szans sobie z tym poradzic…

jesli czlowiek popelni dostatecznie duzy blad – automat tego nie naprawi.

gc jest udogodnieniem, ale nie panaceum.

przyklad t_ziela wlasnie pokazuje typowy blad programistyczny przez ktory dochodzi do wycieku pamieci (tak michuk, to jest wyciek – spowodowany blednym algorytmem/niedopatrzeniem programisty).

@michuk

Oczywiście nie chodziło o result, tylko o elements. Rzecz w tym, że bez linijki elements[size] = null, obiekty będą zdejmowane, ale nadal będziemy trzymali do nich referencje. Innymi słowy chodzi o to, że stos najpierw rośnie a potem zmniejsza się, natomiast po zrzuceniu obiektów, nadal przechowujemy do nich referencje, co uniemożliwia odśmiecaczowi zwolnienie pamięci.

obiekt A z referencja na obiekt B, obiekt B z referencja na obiekt A a nastepnie porzucimy posiadane referencje do obiektow A i B

GC poradzi sobie z tym? w koncu na obiekt A i na B wskazuja jakies referencje.

Javowy GC sobie z tym poradzi. Oczywiście jeśli rzeczywiście do A i B nie mamy referencji żadnych w innych obiektach w nieumarłych wątkach.

Analogiczna sytuacja: tablica z referencjami do obiektów — jak tracimy referencję do tablicy, GC ją pożera.

@michuk

Oczywiście nie chodziło o result, tylko o elements.

Tak, mi też oczywiście chodziło o elements.

Potencjalnie można prawie kontrolować poprzez wpisywanie null do nieużywanych odnośników.

Kiedyś implementowałem prosty GC dla C++. Najbardziej czasochłonne jest poszukiwanie wzajemnych referencji dwóch obiektów i czy żadna referencja programu nie wskazuje na którykolwiek z tych obiektów.

Rozwiązaniem jest więc wpisywanie null do referencji w porzucanych obiektach. Bardzo pomaga to GC.

Cały czas nie to. Tj. GC daje pewien narzut pamięciowy nad ręcznie zarządzaną pamięcią (teoria kolejek, jakby się kto pytał). Ale problem Javy to java.lang.Object z którego dziedziczy wszystko i który jest ,,tłusty'' do przesady.

sporo racji…

co do GC to ztcp w javie kiedys byla mozliwosc recznego jego wywolania (moze jest dalej?), po czym chyba zlikwidowali ja… moge bredzic – za trzezwy jestem :/

Jellonek jest nadal: System.gc();

Bies: "Ale problem Javy to java.lang.Object z którego dziedziczy wszystko i który jest ,,tłusty” do przesady."

Nie zgadzam się z tym, klasa Object ma pola: referencję do obiektu klasy jekiej jest, sygnalizer, mutex. Pamięć w zaalokowanym obiekcie zajmują tylko pola klasy, nie metody, więc Object praktycznie nie zajmuje NIC. Metody to:

clone() – zwraca kopię

equals(Object obj) – zwraca true jeśli referencja jest taka sama

finalize() – handler wywoływany przez GC

getClass() – zwraca referencję do klasy jakiej jest ten obiekt

hashCode() – zwraca hash code – domyślnie jest to adres obiektu

notify() – sygnalizuje oczekujący wątek przez sygnalizer (metoda wait())

notifyAll() – sygnalizuje wyszystkie oczekujące wątki

toString() – domyślnie zwraca hashCode@nazwa_klasy, więc też nie jest to pole

wait() i warianty – czeka na sygnał

To są metody, które w pamięci są w jednej kopii (występują w kontekście klasy nie obiektu), w postaci kodu bajtowego Javie i ew. skompilowane przez JIT, a sama klasa ma niewiele pól (pola występują w kontekście obiektu i zajmują pamięć proporcjonalnie do ilości obiektów).

@dna: zgadzam się w 100% wpisywanie null do nieużywanych referencji to dobra praktyka. Wpisanie null i wywołanie System.gc() daje taki sam efekt jak free w C, albo delete w C++, tylko niepotrzebnie odpala się dealokacja, podczas gdy program może potrzebować czasu procesora – lepiej aby GC zrobił to inteligentnie – wtedy gdy aplikacja nie ma dużych potrzeb, lub gdy naprawdę brakuje pamięci.

o, dzieki za przypomnienie

System.gc() to nie tyle jak free w C, tylko przeszukanie wszelkich zmiennych pod katem mozliwosci zwolnienia pamieci, po czym na kazdej z nich free…

tak wiec roznica jest bardzo duza…

jellonek napisałem, że wpisanie do referencji null I ZARAZ PO TYM wywołanie System.gc() daje taki sam efekt jak jawna dealokacja w C/C++. Tylko po co to robić, skoro GC powstał właśnie po to aby w najbardziej krytycznych momentach nie bawić się w zwalnianie pamięci? Z drugiej strony algorytmy wymagające dużej mocy obliczeniowej powinny mieć pamięć przygotowaną wcześniej, ale nie zawsze się tak da.

Oczywiście wiem jak działa System.gc(), zresztą gdybym nie wiedział to nie odpowiedział bym na Twoje pytanie .

wiesz (co widac) ale i tak sie plunczesz w zeznaniach

taki sam efekt – jesli chodzi o zajetosc pamieci, ale nie taki sam, jesli chodzi o wywolanie free na konkretnej danej. wywolanie system.gc, to wywolanie kobyly w porownaniu do mrowki w postaci free

@jellonek: Przeczytaj jeszcze raz moj komentarz powyzej.

Nie mowie o porownaniu predkosci wykonywania kodu kodu natywnego na kazdej z maszyn. Mowie o porownaniu predkosci emulacji kodu na inna architekture _procesora_ z predkoscia wykonywania bytecodu.

Inaczej – w skomplikowany sposob probuje dac wam do zrozumienia, ze bytecode wykonuje sie szybciej niz emuluje sie inna achitekture procesora.

przeczytaj jeszcze raz moj komentarz powyzej.

dosc jasno i wyraznie pisze o tym co Ty. tj. o wykonywaniu BYTECODE przez MASZYNE WIRTUALNA LLVM.

przeciez jestes oratorem apple – powinienes wiec slyszec o zaletach llvm bardzo mocno wspieranym ostatnio przez apple…

jesli chodzi o p. 5 – troche za bardzo uprosciles java nie zapewnia ci ani wydajnosci, ani niezaleznosci od sprzetu, a tym bardziej od platformy programowej (bo narzuca swoja wlasna). to o czym piszesz zapewnia forth – dobre implementacje sa na o wiele wiekszej liczbie platform zarowno sprzetowych, jak i programowoch – niz java. tak wiec masz zarowno wiecej platform (wspomniana wieksza niezaleznosc) a i znacznie lepsza wydajnosc.

btw. sa tez specjalizowane pod fortha procesory

chętnie podpiszę!

takie petycje sa bez sensu. jak chcesz – mozesz sie zglosic do polskiego przedstawicielstwa googli, ale nie spodziewaj sie za wiele

poki co masz srodowisko w ktorym mozesz tworzyc oprogramowanie.

przypomina mi to sytuacje z procesorami amd64, na ktore linux powstal ztcp pol roku wczesniej niz procesory pojawily sie w sprzedazy procesory te byly dostepne wczesniej w postaci… emulatora

amd odnioslo dzieki temu spory sukces – czy uda sie to rowniez googlom?