- Samsung Galaxy S26 Ultra - fontossági sorrend
- Külföldi prepaid SIM-ek itthon
- Apple iPhone 17 - alap
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Xiaomi 17 - még mindig tart
- Feltalálta a Google a keresőmotort
- Samsung Galaxy S25 - végre van kicsi!
- Fotók, videók mobillal
- Megvan a Xiaomi 17 Max bemutatójának dátuma is
- Google Pixel topik
Új hozzászólás Aktív témák
-
WonderCSabo
félisten
Egyébként szerintem is tendencia, hogy Eclipse-et többen is használják, mint platformot. Előbb találok plugint egy technológiához eclipse-re, mint netbeansre. Példának okáért Activiti.org BPMN designer, vagy mondjuk Android SDK
Az Android SDK már nem sokáig lesz Eclipsen sajnos, egy customizált IntelliJ-re váltanak.
-
-
WonderCSabo
félisten
Nem voltam elég világos. A checked exception-ök hasznosságára gondoltam. És ugye throws-t csak a checked exception-ökre kötelező kiírni. Ezeket ugye aztán nyilván vagy lekezeled, vagy tovább dobod (akkor megint kell egy throws)
Aki nem hiszi, hogy vitatott kérdés a checked exception-ök használata, az járjon utána
Azért mondtam, hogy sokan nem használják jól, mert rohadt sokszor van egy api vagy lib, és tele vannak a metódusok checked pl. IOException-nel. Na hát annak aztán nagyon sok értelme van.
-
WonderCSabo
félisten
a throws kulcsszót (E/3-ban) metódus szignatúrába írjuk az argumentumlista után.
void doSuchThing(int arg0) throws BusinessException {
...
}Javában az Exception osztályból származtatott kivételek checked exceptionök. Ez azt jelenti, hogy ha egy metódus ilyen exceptiont dob, akkor meg kell jeleníteni a metódus szignatúrában a fenti módon, különben fordítási hiba lép fel. Ez elvileg arra jó, hogy a programozó felkészülhet arra, hogy milyen kivételeket generálhat egy metódus, illetve köteles is azt lekezelni, mert ha nem kapod el, vagy dobod tovább, akkor szintén fordítási hiba.
Hasznossága vitatott, általában nem használják jól
-
a throws kulcsszót (E/3-ban) metódus szignatúrába írjuk az argumentumlista után.
void doSuchThing(int arg0) throws BusinessException {
...
}Javában az Exception osztályból származtatott kivételek checked exceptionök. Ez azt jelenti, hogy ha egy metódus ilyen exceptiont dob, akkor meg kell jeleníteni a metódus szignatúrában a fenti módon, különben fordítási hiba lép fel. Ez elvileg arra jó, hogy a programozó felkészülhet arra, hogy milyen kivételeket generálhat egy metódus, illetve köteles is azt lekezelni, mert ha nem kapod el, vagy dobod tovább, akkor szintén fordítási hiba.
Hasznossága vitatott, általában nem használják jól
Lehet h van olyan, aki vitatja
Egy metódus kódjában keletkező kivételeket vagy elsikálod helyben, vagy "delegálod" a metódust hívó félnek. Ha nem foglalkozol vele metóduson belül, akkor azt deklarálni kell. Ez nem csak a fordító idegeit nyugtatja, de a QA-hoz sem árt. Önkéntelenül is leellenőrzöd, hogy megfelelő-e a kivételkezelési láncod.
Amúgy a kivételeket úgy általában sokan nem használják jól, nem csupán a deklarációt.
-
-
egyszerűbbé teheted az életed, ha csinálsz egy típust a számoknak
class Szam {
String eloado;
String cim;
int hossz; //masodperc
public Szam(String eloado, String cim, int hossz) {
// ertekadas a tagvaltozoknak
}
}Felteszem, hogy sikerült beolvasnod a sorokat. Biztonság kedvéért http://stackoverflow.com/questions/5868369/how-to-read-a-large-text-file-line-by-line-using-java Ha el akarod őket menteni a memóriában, akkor pl. (pszeudokód)
List<Szam> szamok = new ArrayList<Szam>();
while ((line = br.readLine()) != null) {
Szam aktualisSzam = parse(sor);
szamok.add(aktualisSzam);
}De elárulom neked, hogy ez egyik feladathoz sem kell.
B)
Szam elozoSzam = br.readLine(); // elso sor
while ((line = br.readLine()) != null) { // tobbi sor
Szam aktualisSzam = parse(sor);
if ( elozoSzam.hossz < aktualisSzam.hossz ) {
// nem igaz
}
elozoSzam = aktualisSzam;
}C) hasonlóan, de egy int-ben összegzed a számok hosszát (ha a sorok végére értél, elölről kezded, tehát két ciklust kell egymásba ágyaznod). A ciklusból kilépési feltétel az, a osszHossz >= K. Akkor az abban a ciklusban beolvasott szám lesz a keresett.
D) Itt már kell egy Map
Map<String,Szam> perCim = new HashMap<String,Szam>();Végigmész a sorokon, és megnézed, hogy az aktuális szám címével van-e szám a mapban. perCim.get(cim) != null. Ha nincs, beteszed.
Ha van, akkor megnézed, hogy az aktuális hosszabb-e, mint a bentlévő, és a feltételnek megfelelően cseréled.Ja, és köszönet, nagyobb nyelvtani hibák nélkül, tagolással, és az írásjelek megfelelő használatával tetted fel a kérdést. Ritkaságszámban megy az ilyen
-
WonderCSabo
félisten
egyszerűbbé teheted az életed, ha csinálsz egy típust a számoknak
class Szam {
String eloado;
String cim;
int hossz; //masodperc
public Szam(String eloado, String cim, int hossz) {
// ertekadas a tagvaltozoknak
}
}Felteszem, hogy sikerült beolvasnod a sorokat. Biztonság kedvéért http://stackoverflow.com/questions/5868369/how-to-read-a-large-text-file-line-by-line-using-java Ha el akarod őket menteni a memóriában, akkor pl. (pszeudokód)
List<Szam> szamok = new ArrayList<Szam>();
while ((line = br.readLine()) != null) {
Szam aktualisSzam = parse(sor);
szamok.add(aktualisSzam);
}De elárulom neked, hogy ez egyik feladathoz sem kell.
B)
Szam elozoSzam = br.readLine(); // elso sor
while ((line = br.readLine()) != null) { // tobbi sor
Szam aktualisSzam = parse(sor);
if ( elozoSzam.hossz < aktualisSzam.hossz ) {
// nem igaz
}
elozoSzam = aktualisSzam;
}C) hasonlóan, de egy int-ben összegzed a számok hosszát (ha a sorok végére értél, elölről kezded, tehát két ciklust kell egymásba ágyaznod). A ciklusból kilépési feltétel az, a osszHossz >= K. Akkor az abban a ciklusban beolvasott szám lesz a keresett.
D) Itt már kell egy Map
Map<String,Szam> perCim = new HashMap<String,Szam>();Végigmész a sorokon, és megnézed, hogy az aktuális szám címével van-e szám a mapban. perCim.get(cim) != null. Ha nincs, beteszed.
Ha van, akkor megnézed, hogy az aktuális hosszabb-e, mint a bentlévő, és a feltételnek megfelelően cseréled.Ja, és köszönet, nagyobb nyelvtani hibák nélkül, tagolással, és az írásjelek megfelelő használatával tetted fel a kérdést. Ritkaságszámban megy az ilyen
-
Annyit hagy kössek bele a félreértések elkerülése végett, hogy nem minden kell, amit a Java SE tartalmaz.
Ezen a [link]-en a General purpose packages az, amit tényleg tudni kell használni, de Special purpose packages már feladatspecifikus, pedig az is a Java SE része.Egy egyszerű példával élve, ha webfejlesztéssel akar valaki foglalkozni, fölösleges magába erőltetnie a Java Swing tudást.
-
Igen, itt a kérdés, hogy A osztályt ki példányosítja. Ha B, vagy már egyébként létre van hozva, és B ismeri, akkor:
public interface A {
public void processObject(Object o);
}
public interface C {
/**
* processXml(String xml, A a) feldolgozza az xml-t, és az eredményt átadja
* a-nak A#processObject(Object o)-n keresztül
*/
public void processXml(String xml, A a);
}
class B {
A a;
public void newXml( String xml ) {
new C().processXml(xml,a);
}
}
public class CImpl {
public void processXml(String xml, A a) {
Object o = parseXml(xml);
a.processObject(o);
}
}Ha C-ben még szükséged van A-ra, akkor a C konstruktorában is átadhatod, de ez így tisztább, jobban látni a függőséget. Az eredeti kérdés interfészekre vonatkozott. Azt nem tudod meghatározni interfészekkel, hogy a C#processXml() implementációja mi legyen, ezért JavaDoc-ban szokták definiálni, hogy miylen további felelőssége van egy metódusnak.
Már létre van hozva, köszönöm a választ
. -
-
WonderCSabo
félisten
Esküszöm, nem értem, mit akarsz mondani Superhun válaszára.
De pár tény:
1) A JVM k*rva okos és tele van optimalizációval. Memória allokációnak alig van költsége, persze sok kis objektum lassíthatja a GC-t. Megoldás: arra az objektumra ne veszítsük el a referenciát, amit újra fogunk használni. Ennek megkönnyítésére szoktak memory poolokat implementálni Javában úgy, ahogy C++-ban is. De ezeket elég speckó esetekben szokták használni, amikor a sebesség van mindenek felett.
2) literálokra referencia mindig ugyanarra a memóriaterületre mutat. for() { String s = "nyorr"; } nem fog új objektumot létrehozni minden egyes iterációban
3) Olyan mikro-optimalizációról beszélünk, aminél egy adatbázis lekérdezés nagyságrendekkel lassabb: semmi értelme gondolkodni rajtaCiklusban String összefűzést StringBuilderrel, mert azt a compiler tudtommal nem ismeri fel, ellenben a "egy" + "ketto" + $valami.toString; kóddal, amit StringBuilderre cserél (vagy StringBuffer, most hirtelen nem emlékszem, melyik a thread-safe)
Nem látom értelmét String helyett StringBufferben tárolni a stringet.
Szerk.:
Közben rájöttem, mit akartál mondani, de elég veszélyes. Ha Stringbuilderben tárolod a stringeket, akkor a StringBuilder mutable, és olyan helyen is megváltoztathatod a String értékét, ahol nem akarod. pl.:StringBuilder strTime = getTimeInString();
page1.setLastVisited(strTime);majd később:
StringBuilder strTime = getTimeInString();
page2.setLastVisited(strTime);no shit, lastVisited szintén frissült page1-re, mert ugyanaz az objektum. Nem hiába találták ki, hogy a String immutable.
-
előbb algoritmust kell tudni írni, (ami MINDENKÉPP folyamatábra [struktogram])
Volt, amikor én is csináltam folyamatábrát olyan problémára, aminek nehezemre esett a megértése, de egyébként az esetek 90%-ában, kigondolsz egy algoritmust, amit egyből le is kódolsz, aztán finomítod, hogy a végén az elvárásoknak megfelelően működjön. Egyből le is tudod tesztelni, hogy működik-e.
Szóval a gyakorlatban minden problémát folyamatábrával kezdeni fasság.
Amúgy meg az aknakereső pont olyan egyszerű, mint a faék. Legalábbis generálni:
Random leteszel aknákat, majd sorba mész az aknamezőn, és minden mezőhöz (ami nem akna), rendelsz egy számot, ami azt jelzi, hogy a közvetlen szomszédai közül hány mezőn van akna. Rettentő nehéz.Ami kihívást okozhat, az az aknák eloszlása, hogy szépen csoportosan legyenek.
Az még talán nem is olyan nehéz, bár nem könnyű pontozni a full randomhoz képest az alternatív megoldásokat. Szerk.: Az egy jó ötlet, ami előttem elhangzott: csak az első kattintás után kell lerakni őket, hadd higgye azt a játékos, hogy szerencséje volt
Ott van még, és tényleg bejárási algoritmust igényel annak a kezelése, hogy ha egy nullás mezőnek minden szomszédját fel akarja fedni - hasonlóan például a Windows beépített aknakeresőjéhez. De semmi durva.
Off vonalra visszatérve: sok merész, valóságtól elrugaszkodott dolgot mondanak az iskolában. Ez a fajta folyamatábra rajzolás iskolapéldája ennek (haha, szóvicc). Egyetemen már közelítenek a dolgok, de azért az első igazi munkafeladat, éles helyzetben mindig hideg zuhanyként jön.
Nem azt mondom, hogy nincs helye a folyamatábrának. De azért egy ilyen programnak fejben is el kell férnie
Ritkán ér rá az ember két és félszer annyi munkát végezni ugyanannyi eredményért, a munkáltatók meg még kevésbé hajlandóak kifizetni.
-
előbb algoritmust kell tudni írni, (ami MINDENKÉPP folyamatábra [struktogram])
Volt, amikor én is csináltam folyamatábrát olyan problémára, aminek nehezemre esett a megértése, de egyébként az esetek 90%-ában, kigondolsz egy algoritmust, amit egyből le is kódolsz, aztán finomítod, hogy a végén az elvárásoknak megfelelően működjön. Egyből le is tudod tesztelni, hogy működik-e.
Szóval a gyakorlatban minden problémát folyamatábrával kezdeni fasság.
Amúgy meg az aknakereső pont olyan egyszerű, mint a faék. Legalábbis generálni:
Random leteszel aknákat, majd sorba mész az aknamezőn, és minden mezőhöz (ami nem akna), rendelsz egy számot, ami azt jelzi, hogy a közvetlen szomszédai közül hány mezőn van akna. Rettentő nehéz.Ami kihívást okozhat, az az aknák eloszlása, hogy szépen csoportosan legyenek.
-
http://www.tutorialspoint.com/log4j/log4j_logging_levels.htm
For the standard levels, we have ALL < DEBUG < INFO < WARN < ERROR < FATAL < OFF
Ha a thresholdot INFO-ra teszed, akkor a DEBUG-ot nem engedi tovább.
Amúgy meg RTFM és azon nem javítasz a helyzeteden, hogy sértődötten beírod, hogy "nem működik", csak a 3. rákérdezésre adsz valami infót, amiből az ember leszűrhet valamit.
-
PandaMonium
őstag
Helló, Java 6-ban jött be nagyon sok minden, ami megkönnyíti a több szálú programok fejlesztését, és a Java Concurrency in Practice ezt taglalja. Nagyon jó alap. jó tömény könyv. Persze Java 7-ben biztosan volt pár feljesztés a több szálú programozás terén, de közel nem annyi, mint amit a hatos verzóba nyomtak bele. Én csak ajánlani tudom. De amúgy kétszer el kell olvasni, hogy megragadjon, plusz nem árt, ha ki is próbálod amiket ír, mert nagyon sok tudásanyag van benne, amit könnyű elfelejteni.
Rendben, köszönöm a gyors választ!
-
http://viralpatel.net/blogs/tutorial-java-servlet-filter-example-using-eclipse-apache-tomcat/
A filter kódjában chain.doFilter(req, res); a következő filtert hívja meg, legvégül a szervletet. Buta megfogalmazás. Nem végig megy fordított sorrendben a szűrőkön, egyszerűen visszatér mindegyik szűrő chain.doFilter(req, res); metódusával, így tehát amit ez után a sor után írsz, az mindig a sorban következő szűrő (legvégül a szervlet) meghívása UTÁN történik.
Így lehet az előállított választ módosítani. -
Ezt a témát pár száz hsz-sal korábban már végigjártuk, és én még mindig tartom magam ahhoz, hogy osztályon belül nyugodtan lehet konkrét implementációt deklarálni pl.: ArrayList<T>. Azért van ennyiféle implementáció, mert mindegyik másra jó. Semmi haszna nem lenne, ha az ember nem tudná kihasználni a lehetőségeit.
Ugyanakkor a burkoló osztálynak nem szabad visszaadnia konkrét List<T> implementációt. ahhoz nagyon jó ok kell.
-
javaslom, hogy olvasd el, mire jó az URLEncoder osztály http://docs.oracle.com/javase/1.5.0/docs/api/java/net/URLEncoder.html
" for converting a String to the application/x-www-form-urlencoded MIME format"
ja hát igen tehát teljesen másra való mint amire kellene. (ez urlbeni paraméterküldésre való) nekem meg url formázás kellene.
Tehát normális url-t stringből a replace-el lehet megint csak összehozni
(url pedig tartalmazhat spacet csak nem space-ként kódolva, de nem is +-ként... De éppen erről volt szó, hogy stringből kéne egy url-t csinálni)
-
akkor próbáld meg így:
byte[] md5StringToByte = new byte[md5String.size()/2];
for( int i = 2; i < md5String.size(); i+=2 ){
String stringByte = md5String.substring(i-2,i);
md5StringToByte[i/2 - 1] = Byte.parseByte(stringByte, 16);
}összehasonlítod az md5StringToByte tömböt az eredetivel. Nem vagyok benne biztos, hogy a stringben a helyiértékek ugyanabban a sorrendben követik egymást, mint a byte tömbben, mert most nem tudom végiggondolni
szerk.: ez eléggé pseudo kód, valszeg nem is a leggyorsabb, de kiindulási alapnak szerintem jó
-
akkor próbáld meg így:
byte[] md5StringToByte = new byte[md5String.size()/2];
for( int i = 2; i < md5String.size(); i+=2 ){
String stringByte = md5String.substring(i-2,i);
md5StringToByte[i/2 - 1] = Byte.parseByte(stringByte, 16);
}összehasonlítod az md5StringToByte tömböt az eredetivel. Nem vagyok benne biztos, hogy a stringben a helyiértékek ugyanabban a sorrendben követik egymást, mint a byte tömbben, mert most nem tudom végiggondolni
szerk.: ez eléggé pseudo kód, valszeg nem is a leggyorsabb, de kiindulási alapnak szerintem jó
-
GWT-ről azt hallottam, hogy nem annyira intuitív a használata, amin a Vaadin sokat segít. Nekem is tetszik, bár nem kedvelem az ötletet, hogy a GUI-t programkódban állítsuk elő, a deklaratív, JSF-es megoldás nekem jobban tetszik ebből a szempontból. Viszont Vaadinban nekem is tetszik, hogy már-már desktop szerű guit lehet létrehozni.
Nekem is tetszik, bár nem kedvelem az ötletet, hogy a GUI-t programkódban állítsuk elő, a deklaratív, JSF-es megoldás nekem jobban tetszik ebből a szempontból.
Van deklaratív lehetőség is a GWT-ben
UIBinder.Egyeébként ha GWT, akkor csak a sztenderd GWT...minden keretrendszer drámaian rontja a teljesítményt, ráadásul mindegyik bevezeti a saját kis megoldásait, amitől már teljes az inkompatibilitás.
-
A nagy DOM sajnos a kódgenerálás hátulütője, de szerintem nem akkora probléma. Egy üzleti alkalmazásnál sokkal fontosabb a funkcionalitás és a konzisztens "look-and-feel". Pixeltologatás kevésbé. Mennyit lehetne nyerni vele, ha kézzel állítaná össze valaki a html kódot, az eredeti DOM 30%-a lenne elhagyható? A böngészők gyorsak, a szerverek gyorsak, a hálózati forgalom GZip tömörítéssel megy, a renderelésben pár ms-et nyer vele az ember.
A probéma akkor van, amikor generált layoutba bele kell nyúlni saját CSS-sel, ahogy mondtad. Pl. icefaces minden köré <span> taget generál, így sokszor az xhtml-be tett style vagy styleClass elem nem azt a DOM elemet fogja változtatni, amire számítok, szóval ja, ebben igazat adok. Csak azt mondom, hogy ez nem a legfőbb probléma. -- bár annak, aki csak ezt csinálja lehet, hogy az
Egyébként pedig szerintem, ha egy egyedi megjelenésű oldalt kell készíteni, akkor csak az alap <h:> tagek és sima xhtml kód jöhet szóba a faceletben. Ennek egyébként megvan az az előnye is, hogy nem kell fogni a fejünket, amikor fejlesztés közepén derül ki, hogy bugos egy 3rd party komponens library egyik eleme
Egyetértek.
Ezért hanyagolom én speciel a JSF-et többek között. DOM fa nagyság és third party library-k
Richfacessel voltak nagyon rossz tapasztalatok...aztán lett GWT és JSP..ahogy éppen az adott feladat megkívánja.Persze, a GWT-ről lehetne komoly vitát nyitni, de okosan kell használni és akkor nincs gond
-
ezt a hashelést a szerveren egy egyszerű shell script is megoldja, azon kell gondolkodni, hogy mi van az almappákkal, azt hogyan kezeled le. meg azon, hogy ha jól értem ez egy egyszerű FTP szerver lenne? vagy mi szolgálná ki a klienst a szerver oldalon? ..szóval azon, hogy hogyan triggereled szerver oldalon, hogy ok, akkor most csináld meg a file-ok hashét. Bár ez akár lehet egy állandóan futó program is, ami változtatás esetén újra generálja a zip fájlt, amiben a többi fájl hashét tárolod. De amúgy egyszerű elgondolás, fapados, de biztos működne, én azonban ha egy mód van rá, mindenképpen legalább egy szervletet futtatnék szerver oldalon, mert jóval szofisztikáltabb megoldást és későbbi kiterjeszthetőséget biztosít.
-
vagy nem specifikáltad eléggé nekünk, vagy ez egyáltalán nem egy bonyolult feladat. Sőt, ezt nem is nevezném a klasszikus értelemben vett verziókövetésnek.
Ha csak ennyi kell, ezt egy szimpla szervlettel megoldhatod. Amikor a felhasználó kér egy fájlt, get-ben elküldi az általa ismert utolsó módosítási időt vagy a fájl hashét. A szervlet megnézi, hogy a szerveren lévő fájlnak a módosítási ideje későbbi-e, mint a requestben található, vagy nem egyezik-e a hash. Ha a fájl módosult, akkor visszaküldi a response-ban.
Pont ugyanígy működnek a cache mechanizmusok is http-ben. Erről a két megoldásról tudok. Kicsit utána kell nézi, lehet, hogy Jetty is tudja ezt alapból (lévén, hogy ő egy HTTP server) csak a HTTP headerekben van az info, mert egy decens szerver már csak tudja.
Persze ehhez egyenként kell lekérdezgetni a fájlokat.
Azt sem mondtad, hogy mennyi fájlról lenne szó, és hogy a kliens tudja-e alapból a fájl elérési útját. El kell-e tárolni a korábbi verziókat? -
Meg a hátránya, hogy ha valami olyan dolgot akarsz megcsinálni, amit nem támogat közvetlenül a component library, akkor kicsit a mélyére kell ásni a dolgoknak, hogyan tudsz megvalósítani JSF-ben egy javascriptes, ajaxos feature-t annak ellenére is, hogy séróból lekódolod a javascript részét, és egy egyszerű servlettel támogatott backendet.
Plusz a JSF tanulási görbéje eléggé lapos, ha egy kicsit is bonyolultabb dolgot kell megcsinálni, például 3 input mezőből kettőt egyszerre kell validálni, és annak függvényében automatikusan kitölteni a 3. input mezőt, az már nem triviális feladat, és aki gyakorlatlan, egy napot is elszenvedhet ilyennel.
Szóval a JSF hátránya nem a nagy DOM fa, hanem az, hogy rohadtul érteni kell hozzá, és egyáltalán nem egyszerű. Mivel az egyszerűség kitétel volt, ezért nem ajánlom.
Én speciel szeretem hogy komponens alapú, és szépen különválasztja a megjelenítési logikát a controller logikától, plusz nem kell foglalkoznom a form változók kinyerésével szerver oldalon, a 3rd party komponens library-k pedig eléggé eye-candy dolgokat tudnak. (viszont ha valamelyik komponens bugos, akkor vagy az eredeti forráskódja alapján csinálsz egy saját komponenst a bugfix-szel, vagy lefejleszted magadnak. Illetve például az Icefaces táblázatai és fája nagyon jól néz ki, de ha több száz elemet akarsz megjeleníteni, akkor baszhatod, mert memóriazabáló a szerver oldalon, és lassú, mint a dög)
-
Hali, szerintem simán el lehet érni jó eredményeket szimplán servlet + stringtemplate ( http://www.stringtemplate.org/ ) kombinációval. Én még nem próbáltam, de kollégám szerint nagyon jó. A frankó az, hogy nem erőlteti rá a framework a saját technológiáit, hanem azt használsz amit szeretnél. Servlet a Controller szerepben, Stringtemplate a view szerepben, Model szerepben pedig vagy saját DAO-kat írsz JDBC-vel, vagy akármit gyakorlatilag használhatsz backendnek.
Egyébként pedig a Play frameworköt nagyon dícsérik, csak az a bökkenő, hogy ahhoz Scalát érdemes használni, amit nem egy-két nap megtanulni, szerintem.
Én is láttam már ez a sprintemplate-t. Egyetlen bajom van vele, mégpedig az, hogy teljesen Java idegen számomra. Tudom, őskövület vagyok, aki JSP/JSF-en szocializálódott
-
vagy nem specifikáltad eléggé nekünk, vagy ez egyáltalán nem egy bonyolult feladat. Sőt, ezt nem is nevezném a klasszikus értelemben vett verziókövetésnek.
Ha csak ennyi kell, ezt egy szimpla szervlettel megoldhatod. Amikor a felhasználó kér egy fájlt, get-ben elküldi az általa ismert utolsó módosítási időt vagy a fájl hashét. A szervlet megnézi, hogy a szerveren lévő fájlnak a módosítási ideje későbbi-e, mint a requestben található, vagy nem egyezik-e a hash. Ha a fájl módosult, akkor visszaküldi a response-ban.
Pont ugyanígy működnek a cache mechanizmusok is http-ben. Erről a két megoldásról tudok. Kicsit utána kell nézi, lehet, hogy Jetty is tudja ezt alapból (lévén, hogy ő egy HTTP server) csak a HTTP headerekben van az info, mert egy decens szerver már csak tudja.
Persze ehhez egyenként kell lekérdezgetni a fájlokat.
Azt sem mondtad, hogy mennyi fájlról lenne szó, és hogy a kliens tudja-e alapból a fájl elérési útját. El kell-e tárolni a korábbi verziókat? -
-
Pedig kihúzod a gyufát!
Az a baj, hogy nem tudom megítélni, hogy helyes-e az alábbi diagram, ami azt mutatja, hogy a Java EE-re a kereslet nagyobb mértékben nőtt, mint Springre, vagyis fejlesztőre.
http://www.indeed.com/jobtrends?q=%22Spring+framework%22%2C+%22Java+EE%22&l=&relative=1
(De igazából nem tudom eldönteni, hogy mennyire hiteles ez a diagram)
DE. A Spring egy jó framework, máskülönben nem használnák, és szerintem innovatívabb is, mint a Java EE, gyorsabban mozog az új technológiák felé. Mindkét keretrendszert nagyon sok helyen használják. De az eredeti kérdéshez visszatérve, ha konkrétan tudja valaki, hogy Springgel kell/akar foglalkozni, akkor azt tanulja előbb, és ne a Java EE-t
Ez a diagram azt is mutathajta, hogy sok helyen keresnek EE fejlesztőt, de nem találnak, mert lassan mindenki átmegy Springre. Sokkal jobban mutatna egy olyan grafikon, hogy hány helyen használnak Springet aktívan és hány helyen EE-t
Ha már flame, legyen kövér
-
Helló,
Nem.
A spring Java EE-től független technológia. Ugyanarra találták ki, mint ami ma a Java EE, még az előtt, hogy a Java EE igazán használható lett volna. Helyettesítő technológiák.Ugyanakkor, ha készítesz egy Springes alkalmazást, megvan a lehetőséged, hogy Java EE technológiákat használj benne. Például a JPA egy Java EE specifikáció, de mára annyira kiforrott (és persze mert java standard), Springes alkalmazásokban is használják ORM rétegnek.
Ha elsősorban Springet akarsz használni, akkor spring tutoriallal kezdd. Csak akkor olvass Java EE tutorialt, ha olyan technológiába ütközöl.
-
Igen, volt már erről vita, és arra jutottunk, hogy a steepet rosszul használják. Az emberek legtöbbször úgy értik, hogy aminek meredek a tanulási görbéje, azt nehéz megtanulni (gondolom azért, mert ami meredek, arra nehéz felmászni
). A wikipedia is ezt írja http://en.wikipedia.org/wiki/Learning_curve#In_culture
De azt is írja, hogy a félreértés elkerülése végett érdemes inkább 'long' és 'short' learning curve-t írniÁh. Hát én konkrétan csak a meredek = nehéz megmászni jelentéssel találkoztam eddig. Akkor tárgytalan
-
Sziasztok, ismét írtam egy blogpostot arról, hogyan érdemes használható EJB-ket gyártani, ha gondoljátok olvassátok el, és mondjátok el a véleményeteket, ha hülyeséget írtam
http://palkonyves.blogspot.hu/2013/03/how-to-design-clean-business-tier-with.html
Még olvasom (nagyon érdekel a téma amúgy), egy elírást észrevettem: szerintem steep learning curve-öt akartál írni, nem shallow-t
-
Karma írta: "A lényeg az, hogy milyen szolgáltatást nyújt, nem az, hogy konkrétan hogyan oldja meg."
Igazából ez a legfontosabb dolog. Amit még hozzá tennék, hogy kontextusfüggő vagy scope függő, hogy a statikus típusa a változónak Map vagy TreeMap legyen-e.
Amikor az osztályod (osztályaid) külső interfészét tervezed meg, akkor a hívó kliens kódnak nem kell tudnia hogy milyen konkrét implementációt (TreeMap vagy HashTable) ad vissza az osztályod egy függvénye, csak azt, hogy a visszaadot érték Map tulajdonságú.
De az osztályon belül fontos lehet, hogy konkrét típust deklarálj. Például egy JSON feldolgozó osztályt csinálsz, és szeretnéd, ha a hívó kliens egyszerűen egy OutputStreambe tudja írni a feldolgozandó JSON stringet. Neked azonban kell egy módszer a JSON feldolgozó osztályban, amivel ki tudod nyerni az OutputStreambe írt adatot. Az OutputStream interfészben nincsen deklarálva semmilyen metódus, amivel adatot ki tudnál nyerni (nem is arra való). De a ByteArrayOutputStreamben vissza tudod kérni a beírt adatot byte[] tömbként.
Konkrét példa:
public class MyJsonParser {
private ByteArrayOutputStream jsonByteStream = new ByteArrayOutputStream();
public OutputStream getOutputStream() {
return (OutputStream) jsonByteStream;
}
public JsonObject parse() {
// fontos tudni hogy ez egy ByteArrayOutputStream hogy használhassuk a toByteArray() metódusát
byte[] jsonBytes = jsonByteStream.toByteArray();
JsonObject jObject = new JsonObject();
// parszoljuk a json stringet
return jObject;
}
}
public class Application {
public static void main(String[] argv) {
MyJsonParser parser = new MyJsonParser();
// kit érdekel a konkrét implementációja az OutputStreamnek én csak írni akarok bele?
OutputStream parserOutputStream = parser.getOutputStream();
parserOutputStream.write( argv[0].getBytes() );
JsonObject jObject = parser.parse();
}
}Ezt csak azért írtam le, mert nem örök igazság, hogy csak interfész típust deklarálunk.
Mondjuk az se véletlen, hogy a parserek általában InputStreamekre/Readerekre épülnek
Ettől függetlenül köszi a kiegészítést, a scope és a szándék tényleg fontos.
-
cső
egyébként multiple="multiple" legyen az (x)html kódban, mert az a szabvány nem támogatja az érték nélküli attirbútumokat, szóval nem köteles minden böngészőben működni ...ásszem
köszi.
Sajnos ahány böngésző annyi szabódványértelmeződés
de köszönöm, javítom -
http://docs.oracle.com/javaee/6/firstcup/doc/gcrlo.html
És hát itt a biblia:
http://docs.oracle.com/javaee/6/tutorial/doc/Az, hogy Glassfishben kell fejlesztened gondolom azt jelenti, hogy Java EE alkalmazásokat kell fejlesztened. Itt még felmerül kérdésként, hogy milyen technológiákat használ az általad átvett projekt. Réginek számít a JSP, Servlet, közvetlen JDBC, esetleg Hibernate. Újnak számít (persze már ezek is 3-4+ éves technológiák, de mára váltak igazán kiforrottá) a JSF, EJB, CDI, JPA.
Én azt javaslom, hogy először szedd össze, hogy melyik technológiákat használja a projekt. (Remélhetőleg a kolléga nem egyedül dolgozott rajta, így valaki tud segíteni), szerezz ezekről valami fogalmat, hogy mi mire jó, párosítsd össze a technológiákat a projekt kódjával, hogy lásd élőben is, mikor és hogyan volt használva.
A fönti linkelt bibliában le van írva részletesen, hogy melyik technológiát mikor használjuk.Ez tényleg hosszú folyamat, mert nagyon összetett a Java EE felépítése. Elmélet-gyakorlat oda-vissza, míg az ember teljesen megvilágosodik.
A forráskódot vissza lehet fejteni minden gond nélkül java decompilerrel, ha minden kötél szakad, de az eredeti formázást és kommenteket el fogja veszíteni. Bár nem tudom elképzelni, hogy "a kolléga elment, nekem kell átvenni a helyét, de nincs meg a forráskód", annak valahol meg kell lennie, a kolléga sem bytekódot írt séróból.
Ha már leírtam, pár hozzászólással korábban van egy hosszú kommentem néhány Java EE technológiából, mert valaki kérdezte, ennek most te is veheted kis hasznát
Persze, ha az alkalmazás Spring-es...
-
Ilyen egyszerű esetekben, illetve ha fontos a sebesség, érdemes inkább megkeresni a ";" helyét String.indexOf vagy String.lastIndexOf függvénnyel, aztán a két adatot a String.substring függvénnyel kiszedni az eredetiből.
Fapadosabb megoldás, de gyorsabb.
10 sornál nem lesz érezhető különbség, de több száz sornál már igen. -
Ilyen egyszerű esetekben, illetve ha fontos a sebesség, érdemes inkább megkeresni a ";" helyét String.indexOf vagy String.lastIndexOf függvénnyel, aztán a két adatot a String.substring függvénnyel kiszedni az eredetiből.
Fapadosabb megoldás, de gyorsabb.
10 sornál nem lesz érezhető különbség, de több száz sornál már igen.Köszi. De mindössze 18 sorról volt szó, szóval bőven jó így is.
-
Servlet
Egy HttpServlet-ből származtatott osztály, amit te készítesz az alkalmazásodban, ebből akármennyi lehet.
Egy alkalmazásszervernek specifikáció szerint tartalmaznia kell servlet containert. Az alkalmazásod web.xml fájljában kell megadnod a <servlet> és <servlet-mapping> direktívákkal. Ezekkel mondod meg a servlet containernek, hogy melyik osztályaid a szervletek, és melyik szervlet hívódjon meg adott url request esetén. pl.<servlet>
<servlet-name>proba</servlet-name>
<servlet-class>hu.whatnot.ProbaSzervlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>proba</servlet-name>
<url-pattern>/proba/*</url-pattern>
</servlet-mapping>A fenti linken látod, hogyan működik a servlet. Például a doGet metódusa HTTP GET kérésnél hívódik meg.
JSP
JavaServer Pages. Ez XML-szerűen, deklaratívan megírt fájl. Ez azt jelenti, hogy a JSP olyan kódot tartalmaz leginkább, ami HTML kódot állít elő. Tudsz benne HTML tageket használni, de van egy csomó, akár mások által feljesztett tag library ami megkönnyítni a HTML kód generálását: például végigiterálás listán, minden egyes elemnél kiírni valamilyen html kódot.
Ezen kívül lehet bennük írni szkriptleteket, amik <% %> közé tett java kód. Ez arra jó, hogy például a megjelenítéshez szükséges formára szabd a megjelenítendő adatot.
példa: http://140.109.18.7/examples/jsp/num/numguess.txt
A JSP Servletté fordul első meghívásnál, itt látod, hogyan http://www.informit.com/articles/article.aspx?p=130980&seqNum=5JSF
Ez már bonyolultabb dolog. JavaServer Faces egy MVCszerű keretrendszer, aminek az volt a célja, hogy úgy tudjunk szerver oldali GUI-t programozni, mint vastagkliens alkalmazást. A JSP kiváltására szolgál. A JSF-nek egyetlen szervlete van, ami az alkalmazásod base url-jére mappel, azon belül ő intézi a dolgokat, hogy mikor mit hívjon meg.
http://courses.coreservlets.com/Course-Materials/pdf/jsf/jsf2/JSF2-Programming-Basics.pdfEJB
Ez szintén bonyolult dolog
Enterprise Java Beanekbe üzleti logikát szoktak tenni. Általában az EJB osztályok azok, amik összekötik a megjelenítési réteget az adatbázissal/ perzisztencia réteggel. Ezek egyszerű Java osztályok (POJO-k). Az esetek 90%-ában állapotmentesek, tehát nincsen belső változóhoz kötött állapotuk, csak metódusaik. Belső változók általában más állapotmentes erőforrásokra hivatkoznak, mint pl. másik EJB.
egy EJB metódus például azt csinálhatja, hogy létrehoz egy új felhasználót, és elmenti az adatbázisban. (nyilván, ezt az alkalmazásfejlesztőnek kell megírnia).
Hogy mitől különb egy EJB egy POJO-nál?
Az osztályra tett @EJB annotációval az osztály az alkalmazásszerver által menedzseltté válik:
Te nem példányosítasz EJB-t, csakis az alkalmazásszerver teszi.
Minden egyes EJB-n kívülről érkező EJB metódushívás új adatbázis tranzakciót indít. (persze ez széjjelkonfigurálható)Itt látható, hogyan kapcsolódnak a technológiák egymáshoz:
http://www.cs.utsa.edu/~cs4413/lectures/topic7.html Főleg az első kép a lényeges. Ott a JSP mellé még tedd be a JSF-et gondolatban.Már azt hittem, nem kapok választ
Nem vagyok Java (vagy bármilyen) programozó, így a konkrét kód nem érdekel, csak a működés elmélete.
JSP volt pl. homályos, de a linkelt példa olyan faék egyszerűségű, hogy még én is megértettem.Köszönöm a részletes választ
-
Nem tudom pontosan hogy akarod megoldani a megjelenítést. Régen volt JSP. ebből ugye servlet generálódott, ahol a JSP statikus részei final stringek voltak, tehát szépen benne maradt a memóriában, nem hozta őket létre újból minden requestnél. Én JSF-et használok, de egyszerű weboldalakra kiváló és nagyon kiforrott a String template.
Én arra gondoltam, hogy ha magát a template-et, mint Stringet egy Singleton osztályba beolvasod egyszer pl. fájlból, amikor szükség van rá, és utána onnan éred el, akkor a Singletonod alkalmazáson belül de, requestek között megmarad, így a beolvasott string template is megmarad a memóriában. Sőt, requestenként ugyanazt a singleton-t fogod elérni. Persze fontos, hogy ezt az osztályt tényleg csak stringek tárolására használd, és ne legyen benne semmi állapot a template stringeken kívül. Plusz a fájlból beolvasás metódusát és a getInstance metódusát nem árt egy mutex-szel védeni, elkerülendő, hogy két thread (két szimultán request) egyszerre inicializálja.
Ez amúgy csak most jutott eszembe a kérdéseddel kapcsolatban, lehet hogy valahol hibádzik a gondolatmenetem, de tekintve, hogy egy JVM-en és egy classloader hierachián belül ugyanazt az osztálypéldányt használja az alkalmazásod requestektől függetlenül, gondolom működik.
Aj, ez nagyon jó, ennek nagyon örülök.
Én valszeg JSP, ha jól látom ezeket használja a Grails és SpringMVC, de még csak bontogattom a szárnyait a java web világban.
Köszönöm, ez hasznos volt -
Idézlek másik fórumról:
Én laptopon futatom a linux + java webszervert (Jetty - baromi jó, gyors és keveset eszik ajánlom mindenkinek) + mongot + (jelenleg mysql), de összeségében még nem láttam őket együtt 1GB ram felé menni
De akkor mi a francért kérdezel ilyeneket?Plusz, arra van valami example a neten / tudnál javasolni vagy kereső szót, hogy amit ajánlottál a statikus html oldalak, vagy amit generálok, hogy azt hogyan lehet megvalósítani a singleton-nal?
Fúú, ez nagyon érdekel.Köszi a részletes választ
. .
Mert majd webszervert akarok bérelni, és hogy ha jön napi szinten a requestek, akkor hogyan hat rá a terhelésre, és ennek utána olvasva ellentétes infókat kaptam... (bár néha a net tele van szútyokkal).
És elbizonytalanodtam... -
Hogyan törölsz?
Ha simán törlöd a detail entitást, de nem nem frissíted a parent entitás (a másik táblából) Set-jét és nem mergeled (sorry nem vágom pontosan a hibernate-es terminológiát) őt, akkor a hibernate cache úgy érzékelheti, hogy az objektumon nem történt semmi változás (a kapcsolatot csak az egyik oldalról törölted, a parent felől nem), ezért nincs oka újra lekérdezni olyan result setet mégegyszer.Próbáld meg, hogy a parent entitás Set-jéből törlöd a detailt, majd mergeled a parent entitást.
Remélem ez menni fog.
-
Hali,
Glassfish egy teljeskörű java EE implementáció (bár van web profile-ja is, ami kicsit kevesebbet tud).
Springhez nem kell Java EE alapesetben, csak egy szervlet konténer, tehát a Tomcat teljesen megfelel. Elvileg egyébként egy teljesen alap Jetty is megfelel neki:köszi, a jetty nekem teljesen ismeretlen, most ránézek.
-
Az annotációk elég sok mindenre használatosak.
Nem tudom konkrétan melyik annotációra gondolsz, és azt sem tudom hirtelen, hogy a Java 2 EE mennyire használja őket. Volt egy névváltás javában, nagyon sokan még mindig J2EE-ként hivatkoznak rá, de Java 1.4-től fölfelé Java EE 5 és Java EE 6-nak nevezik őket, amik sokkal inkább használják a különféle annotációkat.
http://en.wikipedia.org/wiki/Java_EE_version_history
Az annotációk az egyfajta "convention over configuration" paradigma. Amit korábbi java verziókban konfigurációs fájlokban kellett megadni, most a forráskódba írható a definíció helyén. Persze a régi konfigurációs fájlban lévő beállítások precedencia előnyt élveznek az annotációkkal szemben. A haszon az egészben az, hogy sokkal kisebb erőfeszítésbe telik a fejlesztő számára, ha csak a forráskódot kell böngésznie, mint ha a forráskódot és mellé a konfigurációs fájlt is figyelemmel kell kísérni.
Például ott vannak az EJB-k. Régen a beans.xml-ben kellett definiálni minden osztályra, hogy az EJB-e vagy sem, definiálni kellett hozzá a remote és local interfészt, a bean nevét, egyebet. Ha van 10 EJB-d, és változik a neve az egyiknek, nem túl kényelmes külön a konfigurációs fájlban is böngészni utána, pláne, lehet, hogy egy kezdő programozónak eszébe sem jut.
A java EE-nek csomó olyan szolgáltatása van, amiket csak konfigurációs fájlokkal vagy annotációkkal lehet csak elérni. Pl EJB-k létrehozása, JPA Entity beanek, ManagedBean-ek, Servletek, Servlet filterek. egy nagy program esetén ez hatalmas konfigurációs fájlokat eredményezhet, amiket aztán külön kell karbantartani, hogy a kóddal konzisztens maradjon. Az annotációkkal azonban a kóddal együtt lehet kezelni.
Kb ennyi
Nagyon szépen köszönöm a kimerítő választ. Mélyülök a témában így az itt leírtakat értelmezem és utána újra jelentkezem.
-
Heló,
nem
![;]](//cdn.rios.hu/dl/s/v1.gif)
A "nested class-od" adattagjainak láthatósága alapértelmezetten package.
remélem tudod, hogy a static class csak belső osztályként jöhet létre (nested class), és nem azt jelenti, hogy ez egy singleton.
statikus nem a láthatóságra vonatkozik, hanem hogy az adott tag (metódus vagy mező) nem objektum példányhoz, hanem osztály példányhoz tartozik.
Kicsit több tudást igénylő példa, de ugyanazon nevű osztályból (package nevet is beleértve) szélsőséges esetben több példány is létezhet egy jvm-en belül (egy futtatás alatt), ha azok különböző classloaderekkel lettek betölve. (most nem objektum példányról beszélek, az egyértelmű, hogy egy osztálynak több példánya is lehet) -- A java classloaderek kicsit hasonlítanak a PHP-s auto-load classloaderekhez.
az osztálytagok (metódus vagy mező) alapértelmezett láthatósága a package. Így ebben az esetben is. Mivel azonban a nested classod privát, ezért kívülről egyébként sem férhetsz hozzá az osztályhoz, így az adattagokhoz sem, csak és kizárólag a tartalmazó osztályból.
Tehát az Elem osztályod tagjaihoz csak a tartalmazó osztályból férhetsz hozzá, tulajdonképpen magához az osztályhoz is.
Lehet egy nested class nem statikus is
Ha a belső osztályod nem static, akkor egyértelműen hozzá van kötve az őt tartalmazó osztály egy példányához. Példányosítani kicsit furcsa szintaxissal kell:
KulsoOsztaly.BelsoOsztaly belsoPeldany =
kulsoOsztalyPeldany.new KulsoOsztaly.BelsoOsztaly();belső osztályból a tartalmazó külső osztálypéldányra hivatkozni pedig:
KulsoOsztaly tartalmazoOsztalyPeldany = KulsoOsztaly.this;http://docs.oracle.com/javase/tutorial/java/javaOO/innerclasses.html nézd meg a példakódot
Hali!
Köszönöm a válaszokat! Athlon64+, Davs
Most jövők elméleti / gyakorlati kérdésekkel, majd. Leporoltam a Java könyveket, és erősen Java hivő lettem
A beágyazott osztályok, még odébb vannak, de ha ott tartuk, feltétlenül szólok!
Classloader-t nem ismerem, feliírtam magamnak, az általában melyik nagyobb témakörrel együtt szerepel? Beágyazott osztályoknál? Nekem még ez új volt. Mindenképp utánaolvasok majd Ezt jó volt megjegyezni, hogy a static osztály, csak belső lehet.
Akkor viszont, jöjjön a kérdés:
"Mivel azonban a nested classod privát, ezért kívülről egyébként sem férhetsz hozzá az osztályhoz, így az adattagokhoz sem, csak és kizárólag a tartalmazó osztályból."
1.
- Miért fér hozzá a tartalmozó osztály? Hiszen ha a belső osztály privát, akkor elméletben nem férek hozzá. De mégis hozzáfér az őt tartalmazó osztály? Miért?
Például van az A osztáy privát, a B osztály public, akkor az A hozzáfér a B osztály tagfüggvényeihez/adattagjaihoz, de a B nem férhet hozzá az A-hoz.2.
- Milyen gyakorlati haszna van, és mikor érdemes belső static osztályt használni a sima osztály helyet?3.
- Ősosztály példánya hajthat-e végre, az alosztály példányán műveleteket, ha az privát láthatóságú.
Példa.: Ez így lehet nem állja meg a helyét, meg én Interfésszel valósítanám meg, de elméleti kérdés... Legyen adott egy publikus Állat ősosztály, itt van például az ugat() metódus. És van a publikus Kutya és a privát Farkas alosztály.
Legyen egy függvény az állatban: hajtóvadászat(Állat állatPéldány) néven, amely meghívja az állat példányhoz tartozó ugat() metódust.
Ha ezt a hajtóvadászat(Állat állatPéldány) függvényt meghívom úgy, hogy a paraméterben egyszer a Kutya osztály egy példánya van, akkor azon az ugat()-ot végre tudja hajtani, de ha Farkas osztály egy példányánál már nem tudja meghívni az ugat() fv-t igaz? Gondolom ilyenkor a JVM RuntimeException-t kéne dobnia.4.a
Ha egy ősosztály privát (és vele együtt, minden adattag, és tagfv.), és rendelkezik alosztállyal, akkor a fordító automatikusan legenerálja az alosztály számára is a privát adattagokat/tagfv-t?
4.b
Vagy az ősosztály protected/privát, és van benne 1 privát adattag. Akkor az alosztály is megkap minden egyes adattagot, még a privát-ot is, csak annyi a különbség, hogy nem fér hozzá az ősosztály ezen privát adattagjához.
Pl: Állatnak van a privát futás(), és van a publikus Farkas alosztály, akkor a farkas példányának is van futás() nevű fv-e, igaz?
De akkor megint itt jön a helyetesíthetőség elve, hogy ha Egy Feldolgozó osztályban (Például egy függvényt, amely paraméterben egy állat osztályt vár)meghívom az Állat osztály egy állat nevű példányát, akkor a futás() fv-hez nem férek hozzá. És ha az állat példány helyett egy farkas példányt hívok meg, akkor annak a futás()-a meghívható...
Nem tudom, hogy mennyire voltam érthető...5.
Akkor ha egy osztály publikus vagy privát, és az adattagjainál nincs külön feltüntetve, hogy milyen láthatóságú, akkor automatikusa az osztály láthatóságát kapják meg, igaz?arn: http://nagygusztav.hu/java-programozas -ez az előbb említett fórumtárs által javasolt könyv, egy sokkal rövidebb és magyarosított változata.(néha van egy olyan érzésem, hogy csak egy fordító progi lett ráeresztve az eredeti könyvre...) A Thinking in Java könyv, tényleg nem rossz, de én félbe hagytam anno. De nagyon részletes, és még Design Pattern példák is vannak benne!
-
Heló,
nem
A "nested class-od" adattagjainak láthatósága alapértelmezetten package.
remélem tudod, hogy a static class csak belső osztályként jöhet létre (nested class), és nem azt jelenti, hogy ez egy singleton.
statikus nem a láthatóságra vonatkozik, hanem hogy az adott tag (metódus vagy mező) nem objektum példányhoz, hanem osztály példányhoz tartozik.
Kicsit több tudást igénylő példa, de ugyanazon nevű osztályból (package nevet is beleértve) szélsőséges esetben több példány is létezhet egy jvm-en belül (egy futtatás alatt), ha azok különböző classloaderekkel lettek betölve. (most nem objektum példányról beszélek, az egyértelmű, hogy egy osztálynak több példánya is lehet) -- A java classloaderek kicsit hasonlítanak a PHP-s auto-load classloaderekhez.
az osztálytagok (metódus vagy mező) alapértelmezett láthatósága a package. Így ebben az esetben is. Mivel azonban a nested classod privát, ezért kívülről egyébként sem férhetsz hozzá az osztályhoz, így az adattagokhoz sem, csak és kizárólag a tartalmazó osztályból.
Tehát az Elem osztályod tagjaihoz csak a tartalmazó osztályból férhetsz hozzá, tulajdonképpen magához az osztályhoz is.
Lehet egy nested class nem statikus is
Ha a belső osztályod nem static, akkor egyértelműen hozzá van kötve az őt tartalmazó osztály egy példányához. Példányosítani kicsit furcsa szintaxissal kell:
KulsoOsztaly.BelsoOsztaly belsoPeldany =
kulsoOsztalyPeldany.new KulsoOsztaly.BelsoOsztaly();belső osztályból a tartalmazó külső osztálypéldányra hivatkozni pedig:
KulsoOsztaly tartalmazoOsztalyPeldany = KulsoOsztaly.this;http://docs.oracle.com/javase/tutorial/java/javaOO/innerclasses.html nézd meg a példakódot
A lényeget kihagytam: static nested class az egy teljesen hagyományos osztály. Akkor használják, ha bizonyos adattagok, feladatok egy osztályon belül is logikailag jól körülhatárolhatóak és csoportosíthatóak.
Vagy, mint a te esetedben is, egy osztály cask egyetlen másik osztály számára hasznos.Davs
Az csak útvonalat jelöl, mint a package név, de elképzelhető, hogy nem működik úgy, ahogy én írtam, nem teszteltemAthlon64+
jó, nem tudom, nem értek hozzá
-
Heló,
nem
A "nested class-od" adattagjainak láthatósága alapértelmezetten package.
remélem tudod, hogy a static class csak belső osztályként jöhet létre (nested class), és nem azt jelenti, hogy ez egy singleton.
statikus nem a láthatóságra vonatkozik, hanem hogy az adott tag (metódus vagy mező) nem objektum példányhoz, hanem osztály példányhoz tartozik.
Kicsit több tudást igénylő példa, de ugyanazon nevű osztályból (package nevet is beleértve) szélsőséges esetben több példány is létezhet egy jvm-en belül (egy futtatás alatt), ha azok különböző classloaderekkel lettek betölve. (most nem objektum példányról beszélek, az egyértelmű, hogy egy osztálynak több példánya is lehet) -- A java classloaderek kicsit hasonlítanak a PHP-s auto-load classloaderekhez.
az osztálytagok (metódus vagy mező) alapértelmezett láthatósága a package. Így ebben az esetben is. Mivel azonban a nested classod privát, ezért kívülről egyébként sem férhetsz hozzá az osztályhoz, így az adattagokhoz sem, csak és kizárólag a tartalmazó osztályból.
Tehát az Elem osztályod tagjaihoz csak a tartalmazó osztályból férhetsz hozzá, tulajdonképpen magához az osztályhoz is.
Lehet egy nested class nem statikus is
Ha a belső osztályod nem static, akkor egyértelműen hozzá van kötve az őt tartalmazó osztály egy példányához. Példányosítani kicsit furcsa szintaxissal kell:
KulsoOsztaly.BelsoOsztaly belsoPeldany =
kulsoOsztalyPeldany.new KulsoOsztaly.BelsoOsztaly();belső osztályból a tartalmazó külső osztálypéldányra hivatkozni pedig:
KulsoOsztaly tartalmazoOsztalyPeldany = KulsoOsztaly.this;http://docs.oracle.com/javase/tutorial/java/javaOO/innerclasses.html nézd meg a példakódot
-
Peter Kiss
őstag
-
Az appenginere csak annyit, hogy sajnos ez az informatika ilyen, hogy néha meg kell tanulni új dolgokat.
Az utf8-ra nem tudok hirtelen mit mondani, szerintem annak container szinten nem kéne problémát okoznia, vagy be lehet állítani. (az alábbi linken van egy példa karakter kódolás megváltoztatására)
Az utolsó bekezdésre viszont állíts be egy szervletet, mint index.html, tehát a defaultra. van külön ilyen beállítás, és onnan indíthatsz belső requestet más szervletekre is valamilyen input paraméter alapján. Lehet, hogy filterrel is meg tudod oldani: http://www.oracle.com/technetwork/java/filters-137243.html -
Nem tudom mi volt a problémád google appengine-en a servlettel, elvileg azt defaultból tudnia kell, kvázi szabványos szervlet konténert deployolsz föl az appoddal, de van néhány kisebb megszorítás hogy ne lehessen kihasználni végtelen mennyiségű erőforrást, illetve biztonsági megfontolásokból.
A Java EE alkalmazásokra szerintem egyébként sem pont az egyszerű konfiguráció jellemző. vannak dolgok, amik működnek out of the box kevés konfigurációval, de a komplexebb megoldásoknál elég sok deklaratív beállítás van, amiről nem árt, ha az ember tud.
-- ellenben a PHP-val, ami elméletileg csak abból áll, hogy feltöltöd a webszerverre és megy. gyakorlatban meg ahány szolgáltató, annyiféle korlátozás lehetséges --Amúgy nekem már sikerüt (vannak leírások a neten) deployolni JSF-et (Mojarra) és CDI-t is (Weld) is appengine-re. Persze nem fél óra volt, de aztán működött rendesen...
Ha nem tetszik a google appengine, próbáld ki a Heroku-t, de nem biztos, hogy azzal kevesebb utána járás lesz.
Hogy miért nincsenek ingyenes Java hostingok? Hirtelen belegondolva azért, mert kevesebben ismerik olyan szinten, hogy képesek legyenek egy normális weboldalt összehozni velük, így nincs rá akkora igény. Mikor hallani, hogy valaki a sarki suszter weboldalát Java EE alapokon akarja összedobni PHP helyett.
Akik viszont Java-t használnak webes környezetben, azok inkább cégek, és ők szerintem kifejezetten kerülik az ingyenes alternatívákat, mert nem bíznak benne, hogy az tényleg menni fog minden helyzetben. -
"Ezek a servletek hogy is működnek? mármint kell hozzá alkalmazásszerver?
Van egy egyszerű servletem és azt szeretném működtetni."A korábbi hozzászólásaiddal már bebizonyítottad hogy teljesen inkompetens vagy a témában, ennek ellenére olyan felháborodottan írsz a futtatási környezetekről, -- amit nem mellesleg sokan elégedetten használnak -- mintha meglenne az előképzettséged ahhoz, hogy jogosan lefikkantsd olyan emberek munkáját, akik értettek is ahhoz, amit csinálnak.
Amúgy ha valami problémád van pl. az appengine-nel, mindenki sokkal többre menne, ha részletes információkat adnál a hibáról vagy pl. egy stacktrace-t. De lehet, hogy a megoldásban már az is sokat segítene, ha elolvasnád az appengine wiki-t, mert tényleg nem olyan egyszerű, de az biztos, hogy használható.
Én is elég kezdő vagyok, de mindig megpróbálom megtalálni a megoldást, gugliban vagy jútyubon mielőtt kérdezősködnék. Volt már, hogy szégyelltem is magam, hogy milyen egyszerű volt megoldás, csak nem ástam eléggé be magam a témába. -
"Ezek a servletek hogy is működnek? mármint kell hozzá alkalmazásszerver?
Van egy egyszerű servletem és azt szeretném működtetni."A korábbi hozzászólásaiddal már bebizonyítottad hogy teljesen inkompetens vagy a témában, ennek ellenére olyan felháborodottan írsz a futtatási környezetekről, -- amit nem mellesleg sokan elégedetten használnak -- mintha meglenne az előképzettséged ahhoz, hogy jogosan lefikkantsd olyan emberek munkáját, akik értettek is ahhoz, amit csinálnak.
Amúgy ha valami problémád van pl. az appengine-nel, mindenki sokkal többre menne, ha részletes információkat adnál a hibáról vagy pl. egy stacktrace-t. De lehet, hogy a megoldásban már az is sokat segítene, ha elolvasnád az appengine wiki-t, mert tényleg nem olyan egyszerű, de az biztos, hogy használható.
nem éppen vagyok inkompetens, csak régen szenvedtem ilyen marhaságokkal (szerencsére nem volt szükség rá, mert a lightos minden egyben programokat szeretem, nem az ilyen bugos bloatwareket de most sajnos most nem én csinálom az egész kócerájt, alkalmazkodni kell a servlettel), a servletes kérdés is igazából úgy szólt volna jól hogy "nincs az alkalmazás szervereken kívül valami lightosabb megoldás servlet futtatásra?" és van, a jetty
De már lényegtelen a guglis téma nem fogom megtanulgatni az n+1. "szabványos, kompatibilis"(és mégsem az sem az) implementációt, inkább összerakok egy kis fogyasztású gépet szervernek azt arra meg azt rakok amit akarok).
Csak azt nem értem hogy miért olyan ritka a free javas alkalmazásszerver hosting, az undorító php-ból meg annyi van mint a szemét, pedig scriptnyelvként tuti hogy a php zabálja jobban a szervereket. -
JavaDB ( másik nevén Apache Derby ). Ezt tartalmazza a Java SE, így mindenhol elérhető adatbázismotor. Asztali alkalmazásokhoz kiváló, bár van pár dolog, amit nem tud, pl. nincsen benne full text search.
Ha egyáltalán nem használtál még semmilyen adatbázist, akkor a tanulás 60%-a inkább az SQL-re fog rámenni, 30% arra, hogyan használd a JDBC-t, maradék 10% meg arra, hogyan lődd be a Derby-t.
Kiindulásnak http://docs.oracle.com/javadb/ -> http://docs.oracle.com/javadb/10.8.2.2/getstart/index.html
-
JavaDB ( másik nevén Apache Derby ). Ezt tartalmazza a Java SE, így mindenhol elérhető adatbázismotor. Asztali alkalmazásokhoz kiváló, bár van pár dolog, amit nem tud, pl. nincsen benne full text search.
Ha egyáltalán nem használtál még semmilyen adatbázist, akkor a tanulás 60%-a inkább az SQL-re fog rámenni, 30% arra, hogyan használd a JDBC-t, maradék 10% meg arra, hogyan lődd be a Derby-t.
Kiindulásnak http://docs.oracle.com/javadb/ -> http://docs.oracle.com/javadb/10.8.2.2/getstart/index.html
Köszönöm
. -
Én még csak glassfish-t használtam Eclipselinkkel. Weblogic-ban nem vagyok jártas, de
ez a [link] azt sugallja, hogy ez még EJB 1.1, ami már régi, az EJB 2.0 jobban kitalált kevesebb opciót kér.Lehet, hogy a könyv még EJB 1.1-ről beszél, ez esetben szerintem jobban jársz, ha inkább egy on-line tutorial után nézel, ami az újabb verziót tárgyalja
-
Akkor a StringBuildernek például az indexOf, replace, insert metódusai lehetnek a barátaid. Ezekkel próbálkozz. Akár a String.replaceAll is mehet végülis. Bár ez regex kifejezést vár, de ha egyébként is felhasználói inputra kell várni, akkor ez nem sokat dob a latba.
például indexOf operátorral rákeresel a két határoló karakterre, ami között a kicserélendő szöveg van, elmented a két karakter pozicióját, majd StringBuilder.insert metódusával beteszed közéjük az újat. Ilyesmikre kell gondolni.
Lehet jobban jársz, ha letöltöd az Apache StringUtils könyvtárat. elég hasznos.
-
Hali!
talán ez http://www.javapractices.com/topic/TopicAction.do?Id=42itt pedig fönt van egy jó kis ábra, hogy melyik osztályt mire tudod használni:
http://docs.oracle.com/javase/tutorial/essential/io/file.htmlÉn a helyedben azt csinálnám, hogy beolvasnám a fájlt sorról sorra. Megváltoztatnám soronként ami kell, és egyből írnám ki egy másik fájlba (BufferedReader, BufferedWriter). A procedúra végén pedig ezt a tmp fájlt átnevezném az eredeti fájlra.
A kicserélés könnyen megy String függvényeivel. Reguláris kifejezéseket ne használj, mert Javaban nagyon lassú.
Ha nem akarod megkeseríteni az életed, akkor arról tegyél le, hogy egy fájlt szimultán olvasol és írsz
nem is hatékony -
Hali!
talán ez http://www.javapractices.com/topic/TopicAction.do?Id=42itt pedig fönt van egy jó kis ábra, hogy melyik osztályt mire tudod használni:
http://docs.oracle.com/javase/tutorial/essential/io/file.htmlÉn a helyedben azt csinálnám, hogy beolvasnám a fájlt sorról sorra. Megváltoztatnám soronként ami kell, és egyből írnám ki egy másik fájlba (BufferedReader, BufferedWriter). A procedúra végén pedig ezt a tmp fájlt átnevezném az eredeti fájlra.
A kicserélés könnyen megy String függvényeivel. Reguláris kifejezéseket ne használj, mert Javaban nagyon lassú.
Ha nem akarod megkeseríteni az életed, akkor arról tegyél le, hogy egy fájlt szimultán olvasol és írsz
nem is hatékony -
Ez úgy hangzott, mintha cinikusan idéztél volna egy 4 évvel ezelőtti cikket
-- de amúgy igazad van részben. még annyival egészíteném ki, hogy ez természetesen nem jelenti azt, hogy bármilyen esetben lecserélhető egy relációs adatbázissal. És még jó darabig sok helyen nem is fogják lecserélni. -
Ezek alapján az információk alapján nehéz eldönteni, hogyneked milyen tervezési mintákra van szükséged, az meg a másik, hogy olyan sok tapasztalatom nekem sincsen, hogy séróból vágjak 10-20 mintát
Ahogy látom, szeretnéd jól átgondoltan elkezdeni a projektedet, ami mindenképpen jó. Ehhez tudok adni pár tanácsot, ezek elcsépeltnek tűnhetnek, de érdemes betartani őket, hogy ne idő közben jöjj rá, hogy valami szar vagy nem elég rugalmas
Specifikáció: Mindenképpen próbáld meg jól specifikálni azt, amit szeretnél az oldalon: Milyen adatokat akarsz megjeleníteni, hogy akarod megjeleníteni, a felhasználók milyen interakciókra képesek az oldalon (use-case-ek), hogyan akarod őket elszeparálni egymástól. Milyen oldalak lesznek egyáltalán. Ez az alapja az egésznek, ha ebben nem vagy biztos, akkor gondolkodj még rajta.
Modell/Adatbázis: A speci függvényében találd ki a modelledet. Vagy adatbázisból indulj, vagy osztályokból. Én adatbázis modellből indulnék, mert tudom, hogy úgy biztosan hatékony és normalizált lesz az adatbázis (már hanem valami elosztott/no-sql megoldást teszel mögé). Ez még csak az adatok és az adatok közötti interakció, ebben nincsen benne a felhasználói input meg böngészés.
Modell 2 /BLL: Az adatbázis alapján megtervezed a modelledet, osztályokat, amik képesek mindenfélét elvégezni az adatbázisban, amire szüksége lehet a szoftverednek: új diagram, diagram lekérdezése, kérdések, tárátáttá... Itt már érezni fogod, hogy mik azok a pontok, amiket lehet, hogy egyszerűbben is meg lehetne valósítani valami design patternnel, és akkor felmész wikipédiára, és véginézed az összeset
Na, ha ezekkel megvagy, és úgy látod, kiválóan meg tudsz valósítani mindent modell szinten, amit szeretnél, akkor már "gyerekjáték" lesz megcsinálni a controllert és a view-kat, amik az adatokat megjelenítik. Ne felejtsd el, hogy a Java erősen objektumorientált nyelv, ezért nagyon is van értelme osztályokban gondolkodni.
Egy szó, mint száz: Tervezés, tervezés, tervezés!
Persze lehet, hogy fognak jönni azok, akik mondják, hogy manapság az agilis módszertanokat használják a gyors szoftverfejlesztés miatt, és nem kell ennyi időt szánni a tervezésre... erre csak azt tudom mondani, hogy: DE!
Köszi, még van idő a megvalósításig, addig gondolkodom rajta, csak amikor már neki esek a JSP/JSF tanulásának akkor már egyből tolni is akarom a projektet.
De ezt a DAL és BLL-t még kódszinten is látni akarom, előtte. Most így belekavarodtam.DAL: például: objektum beszúrás, módosítása, törlése az adatbázisban
BLL például: Diagram objektum, Felhasználó objektumokIgazából ahogy a munka és egyetem során is ismerkedem a dolgokkal én MongoDB-re gondoltam (nosql) neked erről mi a véleményed?
Én addig szívesen tervezek
. -
az MVC az architektúra, nem tervezési minta. tervezési minta nagyon sokféle van, és sokfélét lehet használni MVC-n belül is, hogy egyszerűsítsd, hordozhatóbbá tedd a kódodat.
Én nem tudok hirtelen mást architektúrát MVC-n kívül, szerintem ez a legelterjedtebb.
De hogy valami érdemi információt is mondjak, én még ketté tudnám osztani az MVC model rétegét:Model:
DAL - Data Access Layer
BLL - Business Logic Layer
Controller
ViewA DAL fogja tartalmazni az alap objektumaidat a modelledben, általában ezt valósítják meg a külfönféle ORM-ek. (ügyfél, autó, számla, kutyafüle...) Más értelmezésben, ahogy a neve is mutatja: ez a réteg kommunikál közvetlenül az adatbázissal: create, update, read, delete
A BLL pedig komplexebb feladatok megoldása a DAL-béli objektumokon, amiknek nincsen köze még a view-hoz vagy a program flow-hoz, amit a controller biztosít.
Például: Ha egy banki szoftvert csinálsz, és regisztrálsz egy új felhasználót, akkor BLL-ben cisnálod meg a regisztrál függvényt, ami a DAL rétegben létrehoz egy felhasználót és egy kezdő számlát is.Igen-igen, az MVC arhcitecktúra, ezt így összemostam,
De köszönöm a DAL és a BLL réteg leírását! Esetleg erre van példa linked?Igen, és tervezési mintákra(design patternek) te melyiket javasolod? Példákkal.
2 dolog lenne,
Az egyik, nem más lenne, hogy folyamatosan kérdések lennének kiírva, Csak annyit, hogy 2-3 témára koncentrálodnának a kérdések (bár lehet ehhez felesleges)A másik, hogy diagramokkat jelenítenék meg. Lenne id, címe, stb. És egy dinamikusan adattag is lenne, az pedig az oszlopok (ez egy List lenne például, vagy egy 2 dimmenziós tömb), az egyik ilyen diagram objektumnak az oszloplistája, 4 oszlopot tartalmazna (értéket), a másik meg például 8-at.
De ezek folyamatosan is változnának, vagyis az oszlopokhoz tartozó érték (adatbázisból jönnének az értékek)
És egy ilyen 2 dimmenziós tömböt érdemes-e mással kiváltani? Például egy List, Treemap?
Mapekre gondoltam, mert lenne kulcs, és hozzátartozó érték. Csak ahogy írtam a mappek mérete mindig más-más lenne, mert diagram objektumonként változik (a válaszadási lehetőségek kiértékelése)Esetleg felhasználók kezeléséhez? Én mondjuk itt az abstract factoryra gondoltam, lenne az egyszerű user, moderátor és admin.
Elméletben tanultam a tervezési mintákról, csak szeretném gyakorlatban is alkalmazni.
-
Nem tudom, hogy ez miért bonyolult. akár egy ciklusban is megoldható, én SWT-ben így oldanám meg (pszeudo kód), nem hiszem, hogy SWING-ben ez nagyon különbözne.
List<JPanel> jpanels = new ArrayList<JPanel>();
for( int i = 0; i< 64; i++ ){
JPanels p = new JPanel( .. );
//beallitod p koordinatait, kiterjedeset
...
//hozzaadsz egy eventlistenert click esemenyre
p.addClickListener( new ClickListenerInterfesz(){
void clickEvent( Event e ){
//beallitod a kivant szint
e.target.setBackgroundColor(...);
}
);
jpanels.add(p);
}sőtt, nem is valószínű, hogy kell minden egyes JPanelhez új ClickListener-t példányosítani, mert általában az esemény target-jéből (melyik elemre vonatkozott) ki lehet nyerni magát a GUI elemet.
-
Én nem is értem ezt a kérdést.
Én SWT-vel bíbelődtem mostanában, és kódoltam a felületet, nem tervezővel csináltam, így nyilván könnyebben nyúlok hozzá a különböző elemekhez, mintha a generált kódból szeretném kiszedni az egyes elemek referenciáit.
Egyre tudok gondolni, hogy a kérdésed arra vonatkozik, hogyan tudsz hivatkozni a tervezővel megrajzolt felületen lévő elemekre, mert az valószínűleg egyenként hozta létre mind a 64 elemre a referenciát.
Ha nem akarsz sokat kódolni (egyenként beletenni a generált elemeket egy mátrixba), akkor bizony kódolnod kell... generáld le te az említett elemeket, és kapásból pakold is őket bele egy mátrixba vagy tömbbe, vagy tudom is én, ahogy ábrázolni szeretnéd a sakktábládat.
Egyébként a sakktábla modelleden is elgondolkodhatsz. Elképzelésem szerint szeretnéd váloztatni a kocka színét, ha rálép egy bábú, rajta van egy bábú, vagy ráklikkel valaki. Előbbi esetekben érdemes lehet származtatni vagy becsomagolni egy osztályba a JPaneleket, amik a kockákat jelentik (decorator pattern pl.), és így minden egyes panelhez tudsz majd rendelni állapotot: rajta van egy bábú, melyik bábú van rajta.
Ez a baj a swinggel, hogy vannak kifinomult form tervezők, amivel megcsinálod a csilli-villi felületet, de amikor már interaktívvá kell tenni, akkor bizony hozzá kell nyúlni kódban is, és akkor jössz rá, hogy igazából nem tanultál semmit a swinggel kapcsolatban azzal, hogy összekattintgattál valamit.
-
Ezt jó tudni, hogy a Spring, mintegy alternatívája a Java EE-nek. Nem foglalkoztam vele még, csak tudom, hogy van.
A webhostingról meg annyit, hogy mindenért fizetni kell. nem vagyok jól tájékozott hosting szolgáltatások terén, de szerintem egy javás hosting nem kerülhet többe, mint egy hasonló tudású php-s hosting árának másfélszerese. Tudom, hogy válság van meg mindenki szegény, de azért egy szolgáltatásért ki lehet fizetni évi mondjuk 8 ropit
-
Servlet/JSP/JDBC az alap. Én ezekkel nem is nagyon foglalkoztam, inkább megpróbáltam kapásból JSF, EJB, JPA-t tanulni. Ez a kombó már komolyabb alkalmazások elkészítésére is alkalmas, és jobban karbantartható, de nem egyszerű megtanulni. Lényegesen lassabb megtanulni, mint az előbbit, de ha rendes Javas karriert akarsz befutni, mindenképpen érdemes ezt tanulni, szerintem. (vagy Struts2 ill. Spring3)
JSF mellett még ott van a Struts2 és a Spring framework 3. Mind a három MVC architektúrájú, nagyon sokat tud, de nem foglalkoztam az utóbbi kettővel. Azt tudom, hogy a JSF az bekerült a Java specibe, így hivatalosan támogatott keretrendszer, nagyon jól együttműködik EJB-vel és JPA-val.
Lacces: Szerintem jó ötlet, még a JSP, JDBC kombóval is PHPval szemben, mert rendes objektumorientált szemlélettel tudsz dolgozni, és tisztább kódot tudsz írni, ezt a nyelv megköveteli. Csomó dolog nincsen benne, ami a PHP-t dinamikusabb, alkalmazkodóbb nyelvvé teszik, de pont ezek miatt a megszorítások miatt lesz majd értelmesebb és átgondoltabb a kód. (Persze Javaban is ott a Reflection API, amivel aztán csuda dolgokat lehet művelni)
modder és Taoharcos köszi!
Mert ha az egyik ötletem összejönne, akkor úgy mond lenne látogatottság, ha meg nem, akkor nem.
PHP vs Java, inkább úgy kérdem, hogy teljesítményben a Java weboldal nem lassúbb mint egy PHP-s weboldal?
És melyik adatbázist érdemes hozzá használni?
ASP.NET-ezek is, az egyik webprojektem biztosan ebben készül. (ADO.NET-eztem is így a JDBC szemlélete nincs mesze tőlem
De így nekem az MSSQL jobban bejön mint a MySQL. -
Servlet/JSP/JDBC az alap. Én ezekkel nem is nagyon foglalkoztam, inkább megpróbáltam kapásból JSF, EJB, JPA-t tanulni. Ez a kombó már komolyabb alkalmazások elkészítésére is alkalmas, és jobban karbantartható, de nem egyszerű megtanulni. Lényegesen lassabb megtanulni, mint az előbbit, de ha rendes Javas karriert akarsz befutni, mindenképpen érdemes ezt tanulni, szerintem. (vagy Struts2 ill. Spring3)
JSF mellett még ott van a Struts2 és a Spring framework 3. Mind a három MVC architektúrájú, nagyon sokat tud, de nem foglalkoztam az utóbbi kettővel. Azt tudom, hogy a JSF az bekerült a Java specibe, így hivatalosan támogatott keretrendszer, nagyon jól együttműködik EJB-vel és JPA-val.
Lacces: Szerintem jó ötlet, még a JSP, JDBC kombóval is PHPval szemben, mert rendes objektumorientált szemlélettel tudsz dolgozni, és tisztább kódot tudsz írni, ezt a nyelv megköveteli. Csomó dolog nincsen benne, ami a PHP-t dinamikusabb, alkalmazkodóbb nyelvvé teszik, de pont ezek miatt a megszorítások miatt lesz majd értelmesebb és átgondoltabb a kód. (Persze Javaban is ott a Reflection API, amivel aztán csuda dolgokat lehet művelni)
-
Servlet/JSP/JDBC az alap. Én ezekkel nem is nagyon foglalkoztam, inkább megpróbáltam kapásból JSF, EJB, JPA-t tanulni. Ez a kombó már komolyabb alkalmazások elkészítésére is alkalmas, és jobban karbantartható, de nem egyszerű megtanulni. Lényegesen lassabb megtanulni, mint az előbbit, de ha rendes Javas karriert akarsz befutni, mindenképpen érdemes ezt tanulni, szerintem. (vagy Struts2 ill. Spring3)
JSF mellett még ott van a Struts2 és a Spring framework 3. Mind a három MVC architektúrájú, nagyon sokat tud, de nem foglalkoztam az utóbbi kettővel. Azt tudom, hogy a JSF az bekerült a Java specibe, így hivatalosan támogatott keretrendszer, nagyon jól együttműködik EJB-vel és JPA-val.
Lacces: Szerintem jó ötlet, még a JSP, JDBC kombóval is PHPval szemben, mert rendes objektumorientált szemlélettel tudsz dolgozni, és tisztább kódot tudsz írni, ezt a nyelv megköveteli. Csomó dolog nincsen benne, ami a PHP-t dinamikusabb, alkalmazkodóbb nyelvvé teszik, de pont ezek miatt a megszorítások miatt lesz majd értelmesebb és átgondoltabb a kód. (Persze Javaban is ott a Reflection API, amivel aztán csuda dolgokat lehet művelni)
Alapvetően egyetértek azzal amit írtál. Két aprósággal egészíteném ki.
Az MVC csak egy kis része a Spring keretrendszernek. Alapvetően nem csak webes, hanem komplett enterprise alkalmazások fejlesztésére alkalmas, mintegy alternatívája a J2EE-nek.
Nagyon ajánlott megtanulni, viszont az igazsághoz hozzátartozik, hogy interjúkon inkább J2EE kérdéseket tesznek fel, így állás kereséskor érdemes inkább arra rágyúrni. Konkrétan én sehol nem kaptam még Spring-es kérdést, még ott sem ahol a pozíció kiírásban benne volt, mint követelmény, ellenben szabvány J2EE kérdést annál inkább.A PHP vs JSP kérdéshez az is hozzá tartozik hogy egy JSP-t támogató web hosting szolgáltatás jóval drágább, mint a sima PHP-s. Ha nem saját szerverre fejlesztesz, ez is fontos lehet.
-
Igen, ha Java, akkor inkább Java EE-re kell gondolni, ami mindenféle apit és szolgáltatást nyújt middleware rendszerek létrehozására, illetve webprogramozásra.
Szóval Javaval kapcsolatban elsősorban nem felhasználói programokra kell gondolni, hanem háttér rendszerekre.
Bár egyébként nem tudom, hogy miért nem használják gyakrabban felhasználói programokhoz. Én mostanában Eclipse RCP-ben fejlesztgettem SWT-vel, és nagyon használható, natív hatású felületeket lehet lérehozni vele, de tény, hogy az MS WPF-től elmarad sokban. Amúgy pl. a Vuze torrent kliens teljes egészében Javaban íródott, és SWT-t használ.
-
Hali, nagyjából jó, amiről beszéltek, de kicsit össze vagytok zavarodva.
Azt mondjátok, hogy "ha változtatsz a kódon, a JIT csak azt fordítja újra". De ehhez előbb nyilván bytekódot kéne generálni, szóval ez a példa nem jó.
A jvm interpreterként működik: veszi a bytekódot, és sorról sorra megfeleltetni egy-egy gépi utasításnak vagy jvm-beli utasításnak. Ilyen a PHP is, a python is, az összes interpretált nyelv.
Amitől a JVM-et Hotspot-JVM-nek hívják az a JIT, ami az alábbi tulajdonságot aknázza ki:
Általában elmondható, hogy egy program a futása során az idő 90%-át a programrészek (függvények) 10-20%-ában tölti el.és ebből jön a JIT működése:
A JVM futtatja a kódot, statisztikákat készít róla futás közben (profiling). Megtalálja ezt a 10%-ot, ahol a program a futása során a legtöbb időt tölti, majd ezeket a kódokat direktbe lefordítja a célgép gépi kódjára, majd beszúr egy ugrást az eredeti bytekódba (természetesen a memóriában, a .class fájlokba nem ír semmit), hogy most onnantól a gépi kódos rész fut.Az optimalizálás pl. abban nyilvánul meg, hogy a JVM látja, mik azok a feltételek, amik sok-sok lefutás után sosem teljesülnek vagy mindig teljesülnek, és úgy fordítja az adott kódrészletet gépi kódra, hogy ezeket a feltételeket alapból igaznak vagy hamisnak veszi
Például egy if-else ág mindig csak egyik fele igaz, akkor úgy fordítja le a kódot, hogy ki is hagyja a feltételvizsgálatot. Természetesen folyamatosan figyeli ezeket az előfeltételeket, és ha van 1 eset, amikor mégis lefutna a kioptimalizált rész, akkor az eredeti bytekódot futtatja interpretált módban.Szó sincs arról, hogy mindent gépi kódra fordít.
Remélem tisztáztam
Szerk:
még annyi, hogy ezek mind a program 1-1 futása során történnek. nincsen olyan, hogy a futását befejező program gépi kód részeit valahová elmenti, és ha újra futtatod, akkor azokat betölti. ezek mint just-in-time egy-egy futás alkalmával történő változtatások. ( ezt azért mondom, mert régen én így képzeltem)Köszi!
. (Csak gyere gyakrabban ide, hogy hasznos dolgokat is olvassunk)
Te ezt hol olvastad?
Én nem egy honlapot nézegettem, és ilyen mélységig nem mentek bele a magyarázatba, így ki következtetem az eddig olvasatokból és tanulmányaimból.
(Ez az optimalizálás nekem új volt
![;]](http://cdn.rios.hu/dl/s/v1.gif)
De így nekem az MSSQL jobban bejön mint a MySQL.
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Autós topik
- Samsung Galaxy S26 Ultra - fontossági sorrend
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- sziku69: Szólánc.
- Milyen billentyűzetet vegyek?
- Elektromos (hálózati és akkus) kéziszerszámok, tapasztalatok/vásárlás
- Luck Dragon: Asszociációs játék. :)
- One otthoni szolgáltatások (TV, internet, telefon)
- Samsung Galaxy Felhasználók OFF topicja
- Építő/felújító topik
- További aktív témák...
- Mac Pro 6,1 2013 Late
- GAMER PC! i7-14700 / RTX 5080 / 32GB DDR5 / 1TB NVMe / 1000w Gold / BeszámítOK !
- ASUS ROG Strix SCAR 16 / Ultra 9 275HX / RTX5090 / 32GB / 2TB NVMe! BeszámítOK
- 27% - Corsair RMx Series RM1000x 1000W 80 PLUS Gold (CP-9020271-EU) Tápegység!
- White AM4 félkonfig! ASUS ROG B550-A + Ryzen 9 5950X BOX + 32GB DDR4 3600Mhz CL17
Állásajánlatok
Cég: aiMotive Kft.
Város: Budapest
Cég: Laptopműhely Bt.
Város: Budapest