- Hamarosan megkezdődik a nubia 2,8K-s táblagépének szállítása
- Barátokká váltak az eddig rivális AI-óriások
- ASUS blog: Ideális olcsó utazós gép lett az új Vivobook S14
- Az Aura Displays hordozható monitorhármasa jól felturbózhatja a produktivitást
- Dual Mode-os IPS monitorral adott magáról életjelet a Gigabyte
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Philips LCD és LED TV-k
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- ASUS notebook topic
- Milyen videókártyát?
- Vezetékes FEJhallgatók
- HP notebook topic
- Kormányok / autós szimulátorok topikja
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- Radeon RX 9060 XT: Ezt aztán jól meghúzták
Új hozzászólás Aktív témák
-
-
#4802
modder
aktív tag
Oppenheimer
#4800
modder
aktív tag
válasz
Oppenheimer
#4800
üzenetére
mert a netbeans egy sz*r
-
modder
aktív tag
-
#4714
modder
aktív tag
WonderCSabo
#4711
modder
aktív tag
válasz
WonderCSabo
#4711
üzenetére
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.
-
#4707
modder
aktív tag
Oppenheimer
#4706
modder
aktív tag
válasz
Oppenheimer
#4706
üzenetére
Akkor, ha újat generálsz, illik.
-
modder
aktív tag
válasz
smallmer
#4701
üzenetére
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
[ Módosította: Qru ]
-
modder
aktív tag
válasz
Gyeptegla
#4687
üzenetére
félreértetted. A konstruktorban csak értéket adsz:
this.cim = cim;
this.eloado = eloado;
this.hossz = hossz;A ciklusos részeket ugyanúgy a feladat függvényében csináld meg, ahogy eddig.
A parse(line) metódus meg annyit csinál, hogy kiveszi a sorból ezt a 3 értéket, és visszaad egy Szamot
-
#4686
modder
aktív tag
WonderCSabo
#4685
modder
aktív tag
válasz
WonderCSabo
#4685
üzenetére
Mindegy szerintem, mert ígyis-úgyis lineáris keresést kell alkalmazni, akár be is olvashatja. Azt szerettem volna demonstrálni, hogy nem feltétlenül kell beolvasni, ami akár hasznos is lehet, ha később az életben ugyanezt a feladatot kapja egy akkora fájllal, amit már nem illik beolvasni a memóriába.
-
modder
aktív tag
válasz
Gyeptegla
#4681
üzenetére
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
-
modder
aktív tag
válasz
M_AND_Ms
#4521
üzenetére
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.
-
modder
aktív tag
JDK - Java Development Kit - Java programok fordításához szükséges környezet
Szerintem ebben a JRE is benne van
http://www.oracle.com/technetwork/java/javase/downloads/index.htmlJRE - Java Runtime Environment - Java programok futtatásához szükséges környezet
http://www.oracle.com/technetwork/java/javase/downloads/index.htmlJava EE SDK - JDK és/vagy Glassfish
Itt látod, hogy a négy csomagban mi van benne: lehet JDK-val vagy anélküllel
Ugye glassfish nélkül nem lehet, mert maga a Glassfish adja a Java EE (Java SE fölötti) runtime-ot.
http://www.oracle.com/technetwork/java/javaee/downloads/index.htmlJava Glassfish Server - Glassfish + JRE
Egész biztos vagyok benne, hogy ebben nem lesz JDK, csak JRE
https://glassfish.java.net/download.htmlNeked melyik kell?
Ha Java SE programokat akarsz fejleszteni, akkor elég egy JDK. Ha Java EE platformot akarsz fejleszteni, akkor Java SDK (JDK-val vagy anélkül, ha ki akarod tudni cserélni a JDK-t, mert olyan igényeid vannak) -
#4448
modder
aktív tag
bendikeee11
#4447
modder
aktív tag
válasz
bendikeee11
#4447
üzenetére
http://groovy.codehaus.org/Compile-time+Metaprogramming+-+AST+Transformations
bár ez nem az a tipikus sakkprogram dolog, viszont menő.
-
modder
aktív tag
válasz
RexpecT
#4377
üzenetére
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.
-
#4322
modder
aktív tag
pokerecske1
#4321
modder
aktív tag
válasz
pokerecske1
#4321
üzenetére
felfordit(field) {
// ha nem nulla, vissza is ter, a
// szomszedokhoz korbeer a rekurziv hivas
// masik iranybol
x = field x pozicioja a tombben;
y = field y pozicioja a tombben;
if (field.getActionCommand().equals("0")) {
t.setText("");
t.setBackground(Color.lightGray);
t.setEnabled(false);
// szomszedok felforditasa
if (y>0)
felfordit(buttonField[x][y-1]);
if (y<height-1)
felfordit(buttonField[x][y+1]);
if (x>0)
felfordit(buttonField[x+1][y]);
if (x<width-1)
felfordit(buttonField[x-1][y]);
}
} -
modder
aktív tag
-
#4266
modder
aktív tag
trisztan94
#4265
modder
aktív tag
válasz
trisztan94
#4265
üzenetére
új projekt from source. existing csak akkor működik, ha már van .project fájl a könyvtárban
-
modder
aktív tag
válasz
pakriksz
#4263
üzenetére
http://en.wikipedia.org/wiki/Public-key_infrastructure
Mi az a cacerts file:
http://docs.acl.com/ax/300/index.jsp?topic=/com.acl.ax.admin.help/system_administration/t_importing_certificates_into_the_java_cacerts_file.htmlHa a java SSL kilensed a default cacerts truststore-t használja, és olyan szerverrel kommunikálsz, ami self-signed certificate-et vagy olyan használ, aminek az aláírója nincsen benne a cacerts fileban, akkor nem tudja hitelesíteni a szervert.
-
modder
aktív tag
válasz
MrSealRD
#4239
üzenetére
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.
-
#4223
modder
aktív tag
trisztan94
#4221
modder
aktív tag
válasz
trisztan94
#4221
üzenetére
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.
-
#4118
modder
aktív tag
WonderCSabo
#4117
modder
aktív tag
válasz
WonderCSabo
#4117
üzenetére
én azt figyeltem meg régebben, ha total commanderben sok apró fájlt másolok, nagyon visszaesik a teljesítmény pár megabyte-ra.
-
modder
aktív tag
az csak egy referencia, semmit nem számít, hol deklarálod. Akkor lenne értelme, ha az egész streamet újra fel lehetne használni.
n00n:
meg kellene nézni, rendesen bezáródnak-e a filehandlerek.
a close()-okat pedig mindig finally blokkba.pl a bytebuffer tömböd tényleg ki lehetne szedni a cikluson kívülre, az lehet, sokat segítene.
-
modder
aktív tag
válasz
pakriksz
#4010
üzenetére
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.
-
#3996
modder
aktív tag
PandaMonium
#3995
modder
aktív tag
válasz
PandaMonium
#3995
üzenetére
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.
-
modder
aktív tag
válasz
zserrbo
#3951
üzenetére
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. -
modder
aktív tag
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.
-
modder
aktív tag
válasz
Taoharcos
#3786
üzenetére
Illetve a private static List userList = new ArrayList();-t tedd inkább egy @ApplicationScoped bean-be nem static-ként, mert semmi garancia nincs rá, hogy egy konkurens felhasználó, akit másik http worker szál szolgál ki szerver oldalon, ugyanazt fogja látni a userList-ből.
-
-
modder
aktív tag
válasz
pakriksz
#3710
üzenetére
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ó
-
modder
aktív tag
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.
-
modder
aktív tag
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
-
modder
aktív tag
válasz
pakriksz
#3690
üzenetére
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.
-
modder
aktív tag
válasz
skoda12
#3684
üzenetére
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)
-
modder
aktív tag
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.
-
modder
aktív tag
válasz
pakriksz
#3613
üzenetére
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? -
modder
aktív tag
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
-
modder
aktív tag
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.
-
modder
aktív tag
Hali,
http://en.wikipedia.org/wiki/Java_API_for_XML_Processing Ez egy jó összefoglalónak tűnik, hogy melyik API mire való. az XMLEventReader azt hiszem StAX specifikus dolog.
A DOM ugye fogja az egész dokumentumot és beparsolja egy DOM fába.
A SAX az egy push parser: ahogy parsolja a dokumentumokat, új tag-eket, és attribútumokat talál, callback metódusokat hívogat, amiket az alkalmazásod implementál, és el tudod dönteni, hogy mit akarsz csinálni az éppen aktuális információval.
A StAX parser hasonló, csak ott az alkalmazás kívülről irányítja a parsolást: lépteti a parsert előre.Nyilván egy szálban tökre mindegy, hogy push vagy pull, szerintem akkor lehet érdekes ez, amikor van egy parsoló szál és egy feldolgozó szál.
A legegyszerűbb a DOM, mert miután a parser készített belőle egy objektum modellt, a tag-ek objektumok hierarchiájaként fog megjelenni, és szépen a saját metódusain keresztül kereshetsz/iterálhatsz benne, meg is változtathatod. Továbbá, ami nagyon hasznos lehet számodra, hogy XPath lekérdezésekkel le tudod kérni csak azokat a node-okat, amikre szükséged van: http://www.ibm.com/developerworks/library/x-domjava/#3
Az, hogy melyiket válaszd eléggé függ attól, hogy mit akarsz elérni:
Ha nem fontos a sebesség: Ha egy asztali alkalmazást csinálsz, semmit nem fogsz profitálni a StAX parserrel a DOM-hoz képest, nem lesz akkora a különbség. Hatalmas RSS-nél mondjuk (hasraütés) pár száz ms-t veszítesz. (DOM)Ha fontos a sebesség: Egy google readerszerű alkalmazást akarsz, ami éjjel nappal olvassa az RSS-t, és mondjuk párhuzamosan amennyit tud. Akkor nem mindegy, hogy a végső reprezentáció és az eredeti XML között fel akarsz-e építeni és tárolni ideiglenesen a memóriában egy DOM fát.
Esetleg fontos a gyors válasz: te real-time akarod beparszolni az RSS-t, és minél gyorsabban pl. betolni adatbázisba a tartalmát vagy más reprezentációban tárolni. (SAX)Streaming: Ez kapcsolódik az előzőhöz: az RSS-t egyből más reprezentációban akarod elmenteni gyorsan, vagy továbbküldeni a hálózaton. (StAX)
Kell-e minden adat: elképzelhető, hogy nem kell az RSS-ből minden adat, csak a link neve például, akkor a többi adat teljesen fölösleges, fölösleges is tárolni őket, a parsolás folyamán csak azokat az adatokat tárolod le, amik szükségesek. (StAX)
Én azt mondom, amíg nem hatalmas mennyiségű RSS feedről, rettentő reszponzív alkalmazásról, streamingről, vagy nagyon kevés memóriáról van szó, addig használj DOM-ot.
-
modder
aktív tag
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 -
modder
aktív tag
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
-
modder
aktív tag
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.
-
modder
aktív tag
válasz
pvt.peter
#3456
üzenetére
Nem vagyok egy nagy XML vadállat, csak mostanában kellett. Attól függ, hogy akarod használni.
ha entitást akarsz generálni az xml-ből oda-vissza, akkor JAXB (Metro, de inkább Eclipse Moxy implementációt használd, mert kevésbé bugos).
Ezt nagyon egyszerű használni.Ha több kontroll kell, akkor pl StAX API.
Én most a kettőt együtt használtam, mert alá kellett írni az eredeti xml üzenetet, ami sokféle típusú lehet. szóval fogtam, jaxb-vel legenerelátam az üzenet xml-t, szintén jaxb-vel legeneráltam a signature objektumból az xml-t, majd StAX-szal a kettőből összeheggesztettem egy nagyon egyszerű xml-t, ami a kettőt tartalmazza.
-
modder
aktív tag
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
-
modder
aktív tag
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
-
modder
aktív tag
Kíváncsiságból megnéztem, és igazad van
http://www.docjar.com/html/api/java/lang/String.java.html 2312. sorától látszik, hogy indexOf()-val splittel, ha(1)one-char String and this character is not one of the
RegEx's meta characters ".$|()[{^?*+\\", or
(2)two-char String and the first char is the backslash and
the second is not the ascii digit or ascii letter. -
modder
aktív tag
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. -
modder
aktív tag
válasz
whatnot
#3260
üzenetére
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. -
modder
aktív tag
válasz
Dave-11
#3239
üzenetére
Ha már a könyvben szó esett arról, hogy "az osztály implementálja az x interfészt", akkor gyanítom, hogy egy valós példa is szerepel az interfész alkalmazására.
Többek között azért jó egy interfész, mert elrejti az osztály konkrét implementációját (fordítási időben).
Egy egyszerű példa a Swing ActionListener interfész amit arra használhatsz, hogy gui eseményekre (pl. gomb megnyomása) valamit reagáljon a programod.
A GUI komponens .addActionListener( ActionListener listener ) metódusának egy olyan objektumra van szüksége, aminek van actionPerformed( ActionEvent e ) metódusa. Tehát létrehoztak neki egy interfészt, amiben deklarálták ezt a metódust, ez lett az ActionListener interfész. Ezzel kényszerítik ki, hogy csak olyan objektumot adjál át ennek a metódusnak, aminek megvan a megfelelő actionPerformed( ActionEvent e ) metódusa.Vissza a fordítási időhöz: Látható, hogy a Swing készítőket nem érdekli, hogy miután lefordították a Swing library-t milyen ActionListener objektumokat fog létrehozni a fejlesztő, lehet azoknak az objektumoknak hatszáz másik metódusa is, és mindegy, hogy mit csinál. Ami a fontos, hogy a fejlesztő által létrehozott listener objektumoknak meglesz az elvárható tulajdonsága: lesz neki actionPerformed( ActionEvent e ) metódusa.
-
modder
aktív tag
Hali,
Mivel még nem vagyok világhírű a blog postjaimmal, ezért teszek egy önző kísérletet a saját népszerűsítésemre
Ha valakit érdekel a JSF, csináltam egy postot arról, hogyan szenvedtem végig egy problémát rossz megközelítéssel, és mi lett volna a helyes.
http://palkonyves.blogspot.hu/2012/12/ive-been-using-postconstruct-wrong-way.html
A feedbackek welcomeok!
-
modder
aktív tag
válasz
Taoharcos
#3228
üzenetére
Akkor gondolom a hiba az egy fordítási hiba annál a kódrésznél egy szép hibaüzenettel. Nem árt, ha legközelebb azt is beírod, nem csak hiba. A vízvezeték szerelőnek sem mondod, hogy rossz a zuhanyzó, mert kicserléi az egész zuhanyfülkét, közben pedig csak a csap csöpög benne..
Na de a lényeg, hogy az ott egyáltalán nem jó. azt a for ciklust tedd a konstruktorba olyan helyre, hogy a benne használt változók már inicializálva legyenek.
mert az ott nem egy függvényhívás, hanem tömb definíció, és tömböt többek között úgy tudunk definiálni, hogy: tipus[] tomb = new tipus[]{ elem1, elem2, elem3 }
Plusz nem árt, ha az alapokkal tisztában vagy, mert lehet kérdezni, de senki nem fogja helyetted megtanulni
http://docs.oracle.com/javase/tutorial/java/nutsandbolts/index.html -
modder
aktív tag
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.
-
modder
aktív tag
-
modder
aktív tag
Most az jutott a tudomásomra, hogy minden egyes lekérésnél elindítódik külön-külön a JVM (ami egymagában 30-40 mega), ezen picit meglepődtem.
Ezt hol olvastad meglepődnék ha így lenne. Totál elveszítené a webszerver az értelmét, és gyakorlatilag CGI-ként futtatnád így az alkalmazásodat.Tessék, itt van egy összehasonlítás arról, hogy melyik webszerver mennyi memóriát használ idle állapotban http://www.jvmhost.com/articles/memory-usage-comparison-of-java-application-servers-and-applications -- 1 jetty instance átlag 50 megabyte.
Erre jön még az alkalmazásod memóriaigénye, ami nagyban függ az alkalmazásod felépítésétől, az output nagyságától. Pl. ha csak az outputot nézzük (a belső struktúrát nem), akkor átlagosan 16 bites karakter hosszal számolva 20 megabyte memóriába 1 250 000 karakter fér bele. ami átlagos karakter per oldal alapján ~ 43 wikipedia oldalnak felel meg.
Erre jöjjön rá még az alkalmazásod belső struktúrája. Azért látni, hogy ez egy eléggé elnagyolt példa, egy kis weboldal nem fog 20 megabyteot elhasználni oldallekéréseknél, max pár megabyte. Nem beszélve arról, hogy statikus adatokat (pl. html template-eket amibe csak beszúrod a generált tartalmat) megosztasz a lekérdezések között, mert bent marad a memóriában. Pl. ha egy singletonban tárolod ezeket, és nem próbálod meg beolvasni a fájlból minden egyes oldallekéérésnél.
Szóval egy relative kis weboldal max pár megabyte memóriát fog lefoglalni requestenként.Plusz korlátozhatod a memóriát JVM beállításokkal (pl. max heap size) meg hasonlók, így ha kezd kifogyi a memóriából a webszerver, a GC majd elintézi a régi objektumokat. Szerintem elég neki kb 500 megabyte memóriát adni.
Szerintem ami a legfontosabb, ha kevés memóriát szeretnél használni, hogy ahol dinamikus string összefűzés van, ott használj StringBuildert vagy StringBuffert (nem emlékszem melyik a nem threadsafe de azt). Pl. A stringet több objektum, függvény állítja elő, vagy cikluson belül generálod. Különben a String + operátor új stringet hoz létre mindig. Kiemeltem, hogy dinamikusan, mert ha csak kényelmi szempontból egy ilyen változót deklarálsz, hogy
String fejlec = "Üdvözöllek \n" + "a\n" + "weboldalamon!"; akkor a fordító automatikusan egybefűzi ezeket a stringeket, úgyhogy no para.Szó ami szó, napi 200 lekérdezésre simán elég a 2GB, de ha spórolni akarsz adj rá 500 megabyte-ot, az is bőven elég lesz.
-
modder
aktív tag
válasz
bucsupeti
#3170
üzenetére
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.
-
modder
aktív tag
válasz
Superhun
#3157
üzenetére
Én nem keverném ezt bele, mert az equals()-nak és a hashCode()-nak az egyedet kell tudnia azonosítania, és nem egyetlen tulajdonságát. Végtelenféle háromszöget lehet ugyanazzal a területtel. Szóval ez ellent mond a Java equals()-ra és hashCode()-ra vonatkozó contractjának.
Nem is adna jó eredményt, mert a terület nagy valószínűséggel Float lesz, amit nem tudsz még javában sem alapból úgy összehasonlítani, hogy mindig jó eredményt kapj, pláne nem az == operátorral:
http://docs.oracle.com/javase/1.4.2/docs/api/java/lang/Float.html#equals(java.lang.Object)Nem tudom mire kell itt a HashSet, de én úgy oldanám meg a dolgot memóriahatékonyan, hogy:
1) csinálok egy ArrayList<Haromszog> haromszogek listát
2) csinálok egy másik ArrayList<Float> teruletek listát
3) ahogy generálom a háromszögeket a ciklusban, egy belső ciklusban minden legenerált háromszögre végigmegyek a 'területek' összes elemén és megnézem, hogy benne van-e az új háromszög területe, így:
if(Math.abs( aktualisTerulet - ujHaromszogTerulet) < 0.001f)
benne van
else
nincs benne, hozzáadom a háromszögekhez a háromszöget, és hozzáadom a az ujHaromszogTeruletet a teruletekhezHa pontosabb float egyenlőség vizsgálat kell, ezt találtam neten http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm
esetleg gyorsabban futó megoldást is találhatsz, ha valamilyen orderes listet használsz pl http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Collections.html#binarySearch(java.util.List, java.lang.Object, java.util.Comparator) -vel keresel a területek között
-
modder
aktív tag
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: -
modder
aktív tag
válasz
lakisoft
#3025
üzenetére
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
-
modder
aktív tag
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á
-
#2966
modder
aktív tag
Peter Kiss
#2965
modder
aktív tag
válasz
Peter Kiss
#2965
üzenetére
Javaban van static konstruktor
-
modder
aktív tag
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
-
modder
aktív tag
válasz
pakriksz
#2958
üzenetére
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 -
modder
aktív tag
válasz
pakriksz
#2955
üzenetére
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. -
-
modder
aktív tag
válasz
pakriksz
#2949
üzenetére
"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ó.
-
modder
aktív tag
válasz
pakriksz
#2945
üzenetére
A Java EE specifikáció elég régóta application server specifikáció. ha egy-egy dolog kell, nem kell hozzá letöltened egy egész application szervert, elég csak megtalálnod azt a projektet, ami tartalmazza a megfelelő package-ket. és ebből több implementáció is van.
Ha kell neked egy darab szervlet container -- isten tudja miért --, akkor pl. letöltöd a Jetty-t, és elindítod egy sima kliens alkalmazásban.
-
modder
aktív tag
válasz
RexpecT
#2790
üzenetére
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
-
modder
aktív tag
válasz
Sotyks94
#2693
üzenetére
ha Javára gyanakszol, először mindenképpen frissítsd, szerintem.
Másodszor pedig létezik több JVM monitorozó program.Ilyen a Java Visual VM. Kell hozzá JDK-t telepítened, és itt találod meg:
Java\jdk1.7.0\bin\jvisualvm.exeHa van programozói beállítottságod, akkor ezzel jászogatva talán ráakadsz a problémára (pl. milyen program zabálhatja föl az erőforrásaidat)
Ha Flashnél is baszkódik (youtube), akkor lehet, hogy a böngésződ a hibás. Nálam a chrome egy időben youtube-nál flash miatt rendszeresen kifagyott, nem is olyan régen.
-
modder
aktív tag
válasz
MrSealRD
#2669
üzenetére
É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
-
modder
aktív tag
http://docs.oracle.com/javase/1.4.2/docs/api/java/lang/String.html#substring(int, int)
http://docs.oracle.com/javase/1.4.2/docs/api/java/lang/String.html#indexOf(int, int)
azaz megkeresed az " első előfordulását, elmented az indexet, ahol van, majd a következő keresését ettől az indextől kezded -
modder
aktív tag
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.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Poco X3 Pro - hardverfrissítés
- Milyen okostelefont vegyek?
- GTA VI
- PlayStation 4
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Genshin Impact (PC, PS4, Android, iOS)
- Óvodások homokozója
- bitpork: MOD Júni 13 Augusztus 2- szombat jelen állás szerint.
- EAFC 25
- sziku69: Fűzzük össze a szavakat :)
- További aktív témák...
- Újszeru GIGABYTE G5 - 15.6" FullHD 144Hz - i7-13620H - 48GB - 1TB - RTX 4050 - Win11 - 1,5 év gari
- Eladó garanciás,új állapotu projektorom kihasználatlanság miatt!
- Acer Nitro V ANV15 - 15.6"FHD IPS 144Hz - i5-13420H - 16GB - 512GB - Win11 - RTX 3050 - 2,5 év gari
- GIGABYTE GeForce RTX 4060 EAGLE OC 8G (GV-N4060EAGLE OC-8GD
- TP-Link Archer AX73 AX5400 Router
- Hp USB-C/Thunderbolt 3 dokkolók: USB-C Universal, G2, G4, G5, Hp Elite/Zbook- Thunderbolt 4 G4
- Samsung Galaxy S23 Plus 256 GB Kártyafüggetlen 1Év Garanciával
- 15db töltő egybe (65W + 90W) kerek végűek (ELKELT)
- DELL T40 EMC Szerver
- ÁRGARANCIA! Épített KomPhone Ryzen 5 9600X 32/64GB RTX 5070 12GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: CAMERA-PRO Hungary Kft
Város: Budapest