Co się pisze w Javie?

0

Witam,
Interesuje mnie jakie są główne zastosowania Javy? Jakiego typu soft głównie się pisze w Javie (np. strony webowe, aplikacje użytkowe itp)?
Czy jest jakaś lista w której są wymienione aplikacje napisane w Javie (dla C++ taką listę znalazłem, dla Javy jakoś nie widzę)

0

Aplikacje mobilne, aplikacje przenośne (niezależne od platformy), obsluga portali internetowych (JSP, itp), aplikacje korporacyjne, narzedzia...

Jedynie gier o wysokich wymaganiach w tym nie napiszesz, bo by dzialaly za wolno.

0

@up - zapomniałeś o najważniejszym, w Javie piszę się programy w javaszkołach :)

0

Gier w Javie się nie pisze ponieważ nie ma np sprzętowego wsparcia dla sprawdzania granic tablic, a komunikacja z opengl odbywa się poprzez ślamazarne jni. Podobno w takim C#owym XNA da się pisać dość wydajne aplikacje C# + DirectX Managed. Gdyby OpenGL był wbudowany w Javę to wtedy w Javie można by tworzyć mniej skomplikowane gry (aplikacje w Javie zużywają dużo więcej pamięci niż natywne).

0
donkey7 napisał(a)

Gier w Javie się nie pisze ponieważ nie ma np sprzętowego wsparcia dla sprawdzania granic tablic, a komunikacja z opengl odbywa się poprzez ślamazarne jni. Podobno w takim C#owym XNA da się pisać dość wydajne aplikacje C# + DirectX Managed. Gdyby OpenGL był wbudowany w Javę to wtedy w Javie można by tworzyć mniej skomplikowane gry (aplikacje w Javie zużywają dużo więcej pamięci niż natywne).

Czasem zamiast pisac glupoty lepiej nic nie pisac. Gry w javie tworzy sie na platformy mobline i to w duzych ilosciach. Jni wcale nie jest bardziej slamazarne niz C# i jedyna przewaga C# jest tutaj mozliwosc pisania na xbox'a. W javie da sie pisac rowneiz gry komputerowe na pc i pare takich powstalo(runescape, wurm online i pare innych) i predkosc dzialania wcale nie jest tutaj przeszkoda.
W ramach ciekawostki paru osobom sie chcialo przeportowac silnik quake II na jave i jest on w zasadzie rownie wydajny co wersja napisana w c: http://bytonic.de/html/benchmarks.html .

Wracajac do tematu posta w javie glownie pisze sie nudne aplikacje webowe i wybierajac te droge to jest najbardziej prawdopdobona sciezka kariery ;).

0

Wracajac do tematu posta w javie glownie pisze sie nudne aplikacje webowe i wybierajac te droge to jest najbardziej prawdopdobona sciezka kariery

Patrząc globalnie pewnie masz rację. Ale nie oznacza to, że nie ma firm, które w Javie robią ciekawe projekty. W Javie pisze się obecnie całkiem dużo kodu do zastosowań naukowych (np. CERN, NASA), jak również dużo innowacyjnych projektów (Google ma ok. połowy rzeczy na Javie, w tym AdWordsy i GMail).

Gier w Javie się nie pisze ponieważ nie ma np sprzętowego wsparcia dla sprawdzania granic tablic

LOL.

Gdyby OpenGL był wbudowany w Javę to wtedy w Javie można by tworzyć mniej skomplikowane gry

O JOGLu słyszał?

aplikacje w Javie zużywają dużo więcej pamięci niż natywne

Proszę o linka do artykułu w recenzowanym czasopiśmie albo uzasadnienie. Inaczej to czcze gadanie.
Owszem, można zgodzić się, że wymagają te kilka MB więcej na runtime JVM. Ale co to jest kilka MB jak obecnie większość ludzi ma GB w swoich maszynach, a sam OS pożera setki MB.

0

http://shootout.alioth.debian.org/u64q/benchmark.php?test=binarytrees&lang=all
Wystarczy wybrać dowolny benchmark - programy w Javie zajmują ok 5x więcej pamięci niż te w C++ (np zamiast 100 MiB zajmują 500 MiB).

Kod w którym jest dużo odwołań do elementów tablic jest wyraźnie wolniejszy w Javie, nawet kilkadziesiąt procent (z wyjątkiem jakichś egzotycznych kompilatorów optymalizujących takie odwołania). Jak ktoś chce to mogę poszukać stosownych porównań.

luser:
Java w tym zestawieniu jest "szybsza" bo kod Javowy jest lepiej napisany niż ten w C - ten w C jest bardzo stary.

0

Gier w Javie się nie pisze ponieważ nie ma np sprzętowego wsparcia dla sprawdzania granic tablic

LOL. Nie ma czegoś takiego jak 'sprzętowe' sprawdzanie granic tablic. W C++ w ogóle nie ma sprawdzania indeksów: gdy odwołasz się poza zakres tablicy to albo dostaniesz segfaulta (gdy odwołasz się poza pamięc przydzieloną dla procesu) albo nadpiszesz sobie kawałek pamięci używanej przez twój program.
Dostęp do tablic jest tylko dlatego wolniejszy, że Java sprawdza indeksy a C/C++ tego nie sprawdza.

0
donkey7 napisał(a)

http://shootout.alioth.debian.org/u64q/benchmark.php?test=binarytrees&lang=all
Wystarczy wybrać dowolny benchmark - programy w Javie zajmują ok 5x więcej pamięci niż te w C++ (np zamiast 100 MiB zajmują 500 MiB).

Kod w którym jest dużo odwołań do elementów tablic jest wyraźnie wolniejszy w Javie, nawet kilkadziesiąt procent (z wyjątkiem jakichś egzotycznych kompilatorów optymalizujących takie odwołania). Jak ktoś chce to mogę poszukać stosownych porównań.

No to wyzywam Cie znajdz kod w ktorym kod odwolania do talibc sa w javie o kilkadziesiat procent wolniejsze niz w c++. Czekam.

0
rnd napisał(a)

Nie ma czegoś takiego jak 'sprzętowe' sprawdzanie granic tablic.

Mhm, wolna jak cholera i starsza niż 90% użytkowników tego serwisu instrukcja bound? Może i mało użyteczna, ale istnieje.

rnd napisał(a)

W C++ w ogóle nie ma sprawdzania indeksów

Mhm, tylko w czystych tablicach, wszelkie kontenery jak najbardziej to oferują. FFI (JNI, unsafe etc.) pozwala na dostęp do pamięci poprzez pointery - masz te swoje 'tablice' z C++.

rnd napisał(a)

Dostęp do tablic jest tylko dlatego wolniejszy, że Java sprawdza indeksy a C/C++ tego nie sprawdza.

Mhm, VM ma piękną przewagę nad C++ - może oferować sprawdzenia i eliminować je kiedy poprawność indeksów będzie zagwarantowana, aplikacja natywna albo zawsze będzie sprawdzać albo nigdy.

0

Mhm, tylko w czystych tablicach, wszelkie kontenery jak najbardziej to oferują. FFI (JNI, unsafe etc.) pozwala na dostęp do pamięci poprzez pointery - masz te swoje 'tablice' z C++.

Wiem o tym, że w kontenarach jest taka opcja (np. at w vectorze) ale jeszcze nie widziałem kodu, który by tego używał.

VM ma piękną przewagę nad C++ - może oferować sprawdzenia i eliminować je kiedy poprawność indeksów będzie zagwarantowana

Raczej chodziło mi o ogólny przypadek.

0

Wystarczy wybrać dowolny benchmark - programy w Javie zajmują ok 5x więcej pamięci niż te w C++ (np zamiast 100 MiB zajmują 500 MiB).

No, to znaczy tyle, że C++ marnuje pamięć. Pamięć nieużywana, to pamięć zmarnowana. :P

A tak serio, ważne jest, czy dany program ładnie oddaje pamięć, gdy inne aplikacje jej potrzebują. Tego te benchmarki nie testują. Zresztą ogólnie część pamięciowa tego benchmarku jest g***o warta, bo nie opisano nawet metodyki pomiarów. Pozostała część tego benchmarku zresztą też :P

Daj linka do artykułu w czasopiśmie recenzowanym, to wtedy pogadamy. Nie ma żadnego powodu aby programy w Javie zużywały 5x więcej RAMu niż odpowiedniki w C++.

JVM daje tę przewagę, że daje się stroić - masz dużo RAMu, to dajesz mu dużo RAMu i przyspieszasz program. Masz mało RAMu, to ograniczasz zużycie odpowiednimi opcjami i masz tak oszczędny program jak w C albo nawet i bardziej, bo GC potrafią defragmentować pamięć. Domyślnie JVM serwerowy jest ustawiony w tryb "działaj szybko, żryj dużo RAMu", bo to jest jedno z typowych zastosowań Javy - na maszynach, które mają b. dużo RAMu, dużo rdzeni i muszą obsłużyć setki tysięcy żądań na sekundę. Dorzucanie RAMu jest jednym z najtańszych sposobów zwiększania wydajności. W drugiej kolejności jest dorzucanie więcej rdzeni / procesorów. Tu też C++ wypada kiepsko, bo wielowątkowość jest tam.... zaraz, jaka wielowątkowość? :D

Wiem o tym, że w kontenarach jest taka opcja (np. at w vectorze) ale jeszcze nie widziałem kodu, który by tego używał.

Bo prawdziwi programiści C++ zawsze piszą prawidłowy kod i nigdy sprawdzanie nie jest im potrzebne.
Java i inne takie wynalazki są dla mięczaków. :D

0

Bo prawdziwi programiści C++ zawsze piszą prawidłowy kod i nigdy sprawdzanie nie jest im potrzebne.

Taak, niedawno mi jeden taki mówił, że błedy typu odwołania poza tablice robią tylko ci najbardziej początkujący :]

0

Segmentation fault kiedyś śnił mi się po nocach ;)

0

GC gdzieś musi przechowywać informację które obiekty są już niepotrzebne, które części kodu natywnego odpowiadają poszczególnym metodom, itp itd. Dochodzi sporo informacji które nie są potrzebne (lub niewspierane standardowo) w C++.

Odnośnie sprawdzania indeksów to:
http://lingpipe-blog.com/2009/03/30/jdk-7-twice-as-fast-as-jdk-6-for-arrays-and-arithmetic/
http://www.stefankrause.net/wp/?p=9

  • komentarze.

Instrukcja bound jest skopana. Gdyby była jakaś normalna (tzn wydajna) to sprawdzanie indeksów pewnie byłoby włączone domyślnie w np Pascalu.

Nie wiem dokładnie jak duży jest narzut pamięciowy w Javie ale niedługo to sprawdzę (tzn będę robił pewien program w ciągu kilku tygodni).

0

ale macie czasem problemy... seg fault bo buffer overflow lub underflow pff... prosty reprodukowalny problem - prosty test jednostkowy powinien zalatwic sprawe, gorzej jak blad jest cholernie ciezko z reprodukowac bo doslownie zalezy randomowo od maszyny, przykladowo: watki i taka glupota jak zmutexowany singleton uzywany w wielu watkach naraz - okazuje sie ze nawet tak teoretycznie trywialne rzeczy jak konstruktor singletona moze nie byc thread safe i juz masz blad jak cholera ktory moze sie pojawi lub moze nie... TO sa problemy z C++ a nie zapisanie czegos w pamieci z d**y :p

0

TO sa problemy z C++ a nie zapisanie czegos w pamieci z d**y

To są problemy z C++, Javy i wszystkich języków które dostarczają w jakiś sposób wielowątkowość :P
A buffer overflowy są charakterystyczne dla C++ i też potrafią być wredne. Wystarczy, że od czasu do czasu nadpisujesz sobie losowo zmienną, która sąsiaduje w pamięci z tablicą i już masz losowe błędy :P
Skoro tak łatwo wykryć buffer overflow to powiedz mi cepa czemu tyle serwerków pisanych w C++ nie jest odparna na tego typu atak?

0

GC gdzieś musi przechowywać informację które obiekty są już niepotrzebne, które części kodu natywnego odpowiadają poszczególnym metodom, itp itd. Dochodzi sporo informacji które nie są potrzebne (lub niewspierane standardowo) w C++.

Please, poczytaj najpierw coś o tym zamiast dalej się pogrążać.

To sporo informacji to 4B w nagłówku każdego obiektu na flagi dla zaznaczania obiektów. :D

Reszta informacji jest trzymana per klasa a nie per obiekt, podobnie jak w C++ i jest zaniedbywalna w porównaniu z wielkością kodu klasy. Inna kwestia, że dzięki tym informacjom Java i inne języki tego typu mają porządne RTTI/refleksję a nie protezę jak w C++. I dzięki temu da się napisać takie fajne rzeczy jak ORMy, kontenery IoC czy remoting oparty o dynamicznie generowane stuby (jak np. Hessian). Coś o czym w
C++ możesz sobie pomarzyć.

BTW: Nigdzie nie ma informacji, które obiekty są niepotrzebne. GC nie dotyka niepotrzebnych obiektów w procesie ich zwalniania. GC w Javie/.NET działa zupełnie inaczej niż myślisz.

@cepa: masz rację, że problemy związane z wielowątkowością są najtrudniejsze.
Przy czym problemem nie są wątki per se. Problemem jest współdzielenie mutowalnego stanu przez więcej niż jeden wątek. Rozwiązań jest kilka: używanie obiektów niemutowalnych, funkcyjność + komunikaty ala Erlang, pamięć transakcyjna (IMHO poroniony pomysł, ale ostatnio modny). Ogólnie ciekawy temat. Jak jesteśmy już przy platformie Javy, to wprawdzie Java nie oferuje tu jakiś nowinek (no, monitory + java.util.concurrent i tak jest znacznym postępem względem np. pthreadów w C, ale nie jest to rewolucja), ale już np. Scala idzie mocno do przodu, czerpiąc garściami z Erlanga.

0
rnd napisał(a)

Skoro tak łatwo wykryć buffer overflow to powiedz mi cepa czemu tyle serwerków pisanych w C++ nie jest odparna na tego typu atak?

pokaz mi serwer ktory jest w pelni pokryty testami (code coverage), nawet apache httpd nie jest,
java faktycznie daje przewage ze zostanie zgloszony wyjatek, ale jezeli nie ma kodu ktory go obsluzy to serwer zostanie pewnie wylaczony, wiec atak po niekad skuteczny

0

Wątpie żeby został wyłączony - co najwyżej wątek przetwarzający request się wysypie a to nie jest wielki problem. A nawet temu można zapobiec łapiąc po prostu wszystkie RuntimeExceptiony.
Przy aplikacji w C++ miałbyś crash całego procesu.

0
donkey7 napisał(a)

Java w tym zestawieniu jest "szybsza" bo kod Javowy jest lepiej napisany niż ten w C - ten w C jest bardzo stary.

ty za to jestes chyba mlody i glupi :p

nie kod jest stary tylko zarzadzanie pamiecia w kazdym kodzie jest inne. C jest k*rewsko szybkie, problemem jest malloc & free

0
rnd napisał(a)

Wątpie żeby został wyłączony - co najwyżej wątek przetwarzający request się wysypie a to nie jest wielki problem.
Przy aplikacji w C++ miałbyś crash całego procesu.

po to sie testy pisze zeby takiej d**y nie bylo, poza tym pisanie oprogramowania serwerowego w C++ to imho conajmniej marny pomysl, C jest lepsze do tego

0

Tak, pisze się testy. Pisze taki cepa, potem przychodzi gość z branży/jakiś abuser i rozkłada system przechodzący wycacane testy. To tyle w temacie.

Druga sprawa - ludzie, buffer overflow w kodzie pracującym pod VM to zupełnie inna sprawa niż 'ten sam' błąd w kodzie natywnym, inne przyczyny, inne możliwości wykorzystania, inne efekty...

C wcale nie jest szybkie, nie istnieje coś takiego jak szybkość języka. Dobre VM zoptymalizuje kod podczas działania, pozwala nawet na aktualizowanie kodu i struktury obiektów, w językach natywnych jest to nieosiągalne. Dobry GC zaś daje cholernie szybką alokację i zerowy koszt zwalniania obiektów, poza tym potrafi optymalizować ułożenie danych i zapobiegać fragmentacji pamięci.

Niech nawet VM będzie te 10% wolniejsze od kodu natywnego. Kod natywny choćby nie wiem jak udziwniony będzie miał szansę zgubić pamięć, zdechnąć z powodu fragmentacji, uszkodzić dane, na których pracuje bo zamiast rzucić wyjątek zacznie losowo po pamięci pisać...

Języki wysokiego poziomu powstały przede wszystkim dla bezpieczeństwa i rozwiązania problemów nierozwiązywalnych (sensownie) na niższym poziomie. Ciekawe dlaczego nawet NASA nie programuje swoich sond w C++ tylko w Common Lispie...

0
cepa napisał(a)

poza tym pisanie oprogramowania serwerowego w C++ to imho conajmniej marny pomysl, C jest lepsze do tego

Cepa, weź idź wyrwij bezzębną panienkę może lepiej, co?

C to podzbiór C++, C++ pozwala ogarnąć cały ten zbędny, niskopoziomowy syf. Nie istnieje ani jeden sensowny argument za użyciem C.

0
deus. napisał(a)

Tak, pisze się testy. Pisze taki cepa, potem przychodzi gość z branży/jakiś abuser i rozkłada system przechodzący wycacane testy. To tyle w temacie.

no jak sie warunkow brzegowych nie sprawdzi to blad tak czy siak bedzie, inna kwestia ze 100% code coverage to pierunsko ciezke zadanie :<

0
deus. napisał(a)

C to podzbiór C++, C++ pozwala ogarnąć cały ten zbędny, niskopoziomowy syf. Nie istnieje ani jeden sensowny argument za użyciem C.

tak yasne, a pozniej jest "jak krwa napisac ten jbany kod aby zadzialal na 10 letnim aix'ie" :P
imho przewaga C nad C++ jest taka ze C89 to wlasciwie standard i praktycznie caly obecnie uzywany sprzet (nawet ten leciwy) jest z nim zgodny :P

0

Cóż, tak to jest jak się pracuje w muzeum... Z tego samego powodu trzyma się, jak małpy w klatkach, programistów Cobola i Fortrana.

0

No już nie przesadzajcie z tym jechaniem po C++ ;) C++ jeszcze daleko do COBOLA czy Fortrana.
C++ stosuje się tam gdzie jest potrzebna większa przewidywalność czyli w systemach czasu rzeczywistego. Jave generalnie też można stosować do soft-realtime'u ale jest to dosyć niewygodne. Brałem udział w pisaniu aplikacji w Javie, która miała działać w soft-realtime. Żeby przypadkiem nie włączył się GC alokowało się CAŁĄ pamięc przy inicjalizacji, a w runtime korzystału się już tylko z tej zaalokowanej pamięci. Jak się można domyślić nie było to zbytnio wygodne ;)
Niedawno powstała specyfikacja Java Realtime może to coś poprawi w tej kwestii.

0

jak dla mnei jest jedna dziedzina w ktorej C++ jest po prostu zajebiste i javy, c sie moga schowac :]

szybkie matematyczne/algorytmiczne aplikacje przetwarzajace duza ilosc danych, czyli gry, symulacje, mes, grafika
przeciarzanie operatorow to po prostu zbawienie jak caly program dziala na samych wektorach macierzach i innych wynalazkach :>

0

Przeciążanie operatorów masz w Scali i to dużo lepiej zrobione niż w C++. I tysiąc innych rzeczy, o których programistom C++ się nie śniło (Javy zresztą również). W ogóle jeśli chodzi o wygodę pisania i ekspresywność, to IMHO C++, Java i nawet C# z .NET 4.0 przy Scali mogą się schować. A wydajność do wszystkich zastosowań, które cepa wymieniłeś jest w zupełności wystarczająca (jak napisał Deus: 10% nie gra różnicy) - Scala kompiluje się do bajtkodu JVM, jest statycznie typowana i pieruńsko szybka.

Co do testów jednostkowych: pokrycie 100% kodu jest pieruńsko trudne a i tak Ci nic nie gwarantuje. Dałoby taką gwarancję dopiero pokrycie 100% przestrzeni problemu wejściowego dla programu. Problem w tym, że ta przestrzeń rośnie zwykle wykładniczo wraz ze wzrostem liczby i rozmiarów przypadków użycia kodu. Czyli w praktyce przetestowanie wszystkich przypadków jest niemożliwe, ba zwykle nie jest możliwe nawet przetestowanie wszystkich przypadków brzegowych, które mogą zakończyć się buffer-overflowem.

Za to zgadzam się, że C ma pewne duże przewagi nad C++:

  1. Jest prosty - to tylko przenośny assembler, nikt nie oczekuje budowania w tym wielkich systemów, więc argument że słabo nadaje się do budowania dużch rzeczy jest nie na miejscu.
  2. Dwóch programistów znających C nawzajem zrozumie swój kod. W przypadku C++ niekoniecznie, bo mogą używać innego 10% podzbioru języka.
  3. Nie sprawia takich problemów na poziomie ABI jak C++.
  4. Może być używany w takich miejscach, w których C++ nie wejdzie bo nie ma kompilatora / wsparcia itp. Np. do pisania modułów jądra w Linuksie.
  5. Nie daje fałszywego poczucia bezpieczeństwa.

1 użytkowników online, w tym zalogowanych: 0, gości: 1