- Nem kell még temetni: 2 éves órajelcsúcsot döntöttek meg Raptor Lake-kel
- HiFi műszaki szemmel - sztereó hangrendszerek
- Házimozi belépő szinten
- Apple MacBook
- Milyen egeret válasszak?
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Gaming notebook topik
- Nem kéri tovább a nekik fejlesztett csúcs-GeForce-ot Kína?
- Fejhallgató erősítő és DAC topik
- Kezdő fotósok digitális fényképei
Új hozzászólás Aktív témák
-
Épp a gyakorlás az, amikor érdemes mindent kipróbálni.
Részemről:
- Gradle vagy Maven
- Spring
- legalább egy Derby szerver módban
- Hibernate/JPA
- Spring Data JPA
- QueryDSL
- Spring MVC REST controllerekkel, Security
- szigorúan csak embedded Jetty
- JQuery vagy Sencha ExtJS -- utóbbinál a vektorgrafika sem kihívás a nézőtér összerakásánálAbban mondjuk egyetértünk, hogy érdemes a tanulás miatt iteratívan újra átdolgozni a megoldást, de a desktopos részt én kerülném, mint a leprást.
-
És mind felesleges, mert tiszta javaban ugyanazt el lehet érni kevesebb erőforrás felhasználásával.
Persze több meló és odafigyelés, de valamit valamiért.Hát ezt most remélem nem jól értem
Egyébként meg betegek vagytok, full kezdő javaból erre kap a nyakába egy ilyen technology stack-et
Bár végül is ő kérezde, ki milyen technológiát választana -
Ha multi, akkor távbabrálásban jönnek a román, majd indiai kollégák. Ez van. A 10 órás marhaságra meg csak annyit lehet mondani, hogy tehetségtelen PM/architekt emberekkel is tele van a piac, emiatt van ez, meg hogy leprásként tekintenek sok helyen a 30+ családosakra, mintha az lenne a normális, hogy az ember bent éli az életét.
-
Komoly cég megbíz olyanokat, akik bárhol keresnek.
Egyébként nem csodálkozok ezen, mert nem túl jó irányban alakult a piac az utóbbi években a furcsa felhozatal révén. Érdekes elvárások vannak mindkét fél részéről, közben csak hígul a szakma. Emiatt az értékesebb emberek gyakran elszállnak (többnyire emberileg), sokan kivándorolnak... Ez van.
Sok szerencsét a keresőknek! Szükségük lesz rá.
-
Az alkalmazott technológiák, módszertanok, felelősségek megemlítése értékes adalék lett volna, ha már a cég neve titok. Kétlem, hogy pusztán a "kimagasló bérezés" elegendő arra, hogy egy fejlesztő váltásra adja a fejét. Legalábbis a jobbak, akik amúgy is jól meg vannak fizetve.
Na meg kérdés mi számít kimagasló bérezésnek
Sokszor itt félreértések vannak azt hiszem a jó java fejlesztők meg a munkáltatók között Egyébként megdöbbentően sokan recruitolnak így fejvadászok, még a cég nevét se mondják meg, UI vagy backend, technológiák stb. stb. mégis mit várnak, időmilliomos az ember, hogy még ha ne adj isten tényleg épp aktuális is lehet a váltás ennyire hogy "java fejlesztőt keresünk" már ugrik is az ember és megy interjúzni? -
És a többi feladatot is elolvastad előtte?
Mert akkor elég egyértelmű:
Írj egy (a sereg) csomagon kívüli futtatható osztályt!
Futtatható: van benne main ... de ez is elég egyértelmű a feladatból. -
-v-
addikt
Pont most kezdtem olvasni a clean code magyar verzióját és a felület szónál azonnal eszembe jutott a forum. Amíg nem írt konkrét példát addig fogalmam nem lett volna mire gondol a költő
Általában neten szoktam angolul olvasni, de ez most kivétel.
Van még pár gyöngyszem amit tudnál mondani?magyar verzióját
Fasza lehet -
Sziasztok
2 hét múlva kezdek egy 30 fős cégnél mint java gyakornok. Spring MVC-ben fejlesztenek és annak ellenére vettek fel, hogy még csak java SE-t tanulgatom. Az lenne a kérdésem, hogy ilyen helyen általában, hogy zajlik a betanulási fázis. Leülök próbálkozni és néha kérdezhetek vagy heti 1-2 órát magyaráznak? Nem tértünk ki erre, de kíváncsi lennék a tapasztalataitokra.
Hat eleg szeles a skala szerintem ... van ahol a knowledge transfer mint olyan nem is letezik, van ahol meg tok nagy hangsulyt fektetnek ra. Kollegaktol is fugg, meg attol is, hogy az adott helyen mi a policy erre ... remenykedj hogy jo helyre kerulsz, mert be lehet szopni, plane ha valami ezereves fos legacy codebase van, mindenfele sajat szutykokkal, amik kozeleben se jarnak a szabvanyos megoldasoknak, minden mindennel okosan ossze van drotozva, doksi nulla, design nulla, knowledge transfer nincs, kollegak basznak rad, oldd meg ahogy tudod, aztan mehetsz turkalni nyakig a kakiban ...
Szerintem azert nem ez az altalanos, de van ilyen is. Remelhetoleg baratsagos konyezetbe, meg szakmaikag jo projektre mesz. -
Ráadásul nem csak a megítélésed lesz jobb, de nekik is, meg neked is könnyebb lesz, hogy nem a keretrendszer alapjait ( a finomságokra úgyse elég két hét) kell elmagyarázniuk, hanem magát a szoftvert, és a mögötte levő üzleti logika alapjait.
Hm? Ezt nem a kolleganak akartad inkabb cimezni?
Nekem nem kell jelenleg ilyennel foglalkoznom, egesz egyszeruen szeretnem megismerni oket, melyik mit tud, from scratch melyik projekthez melyiket valasztanam. -
Tudom ajánlani az ExtJS kitchen sink oldalát és a Dijit demót, ha a részletekre vagy kíváncsi.
A core, az adatkezelés, a kommunikációs eszközök sokkal kidolgozottabbak az ExtJS esetében. A komponensek tekintetében a Dijit-nél az összkép elég lehangoló -- olyan mintha félbehagyta volna a tervező, és nem figyeltek volna az eseménykezelésnél a megfelelő sorrendekre.
Az ExtJS-nek nagyon erős a komponens modellje, és eléggé rágyúrtak az OOP-szerű programozási modellre. A Dojo az eseménykezelésre gyúrt rá, de nagyon nem mentek tovább. Az ExtJS komponensek tudása lényegesen nagyobb, és nem elhanyagolható az sem, hogy a Dojo dokumentációja messze elmarad az ExtJS-étől.
Az ExtJS gyengéje a custom design. Ha sajátot akarsz készíteni az összetett komponensekre, akkor az nagy meló. Amennyire látom a Dijit esetében ez kevésbé időigényes, bár az ExtJS alapkomponenseiből elég gyorsan lehet építeni saját összetett elemeket is.
-
Webes kliensnél? Erre nem fogsz jó választ kapni. Mindenki elmondja a véleményét
A generálás szvsz egyáltalán nem követendő. Manapság van pár divatos frontend platform: AngularJS, JQuery, Sencha Touch/ExtJS, Dojo, meg még sok más hasonló framework. Nekem ezekkel kapcsolatban az a meglátásom, hogy az első kettő elég ingatag, állandó pletykák keringenek a támogatásukkal kapcsolatban. A Dojo egy kicsit komolyabb háttérrel rendelkezik, de a Sencha-hoz képest kevésbé teljes termék.
A Touch/ExtJS nem egyszerű eset, ha tanulni kell, mert a tipikus frontendes számára érthetetlen, hogy szoftveres logikára épül (Java/PHP fejlesztők számára készült inkább), ezért sokan kerülik, bár nálunk ez van majd minden projektben. Sokakat az riaszt, hogy nem GPL felhasználáskor fejlesztői licenc kell hozzá, bár amennyi emberórát elpocsékoltak itt páran JQuery komponensek keresésével/illesztésével, abból kijönne pár licenc. -
Luxus, mert most láthatod, hogy valamire szükséged lenne, amit nem tudsz megkerülni. Persze játszhatod azt, hogy ameddig tudod, másra tolod, vagy ilyesmi, de mostanában egyre népszerűbbek azok, akik több dologhoz is értenek (vagy akarnak érteni).
Szerintem a javafx IS döglődik a többi plugines technológiával együtt. Gyakorlatilag mindenki JS-t használ.
Igen hat ez igy van ebben a szakmaban, valtozik folyon, nyitva kell tartania az embernek a szemet, aztan gyorsan reagalni ha valami van ... Akar technologiaval, akar massal kapcsolatban. Eddig nem volt luxus, ha mostantol az lenne valami miatt, akkor nyilvan felturbozom magam javascript ugyben, ennyi.
A rugalmassag meg a tanulas az itt orok, de amig megtehetem hogy ragaszkodok a sajat szempontjaimhoz addig azert valamennyire megtszem, mert nyilvan olyat akarok csinalni, ami szeretek ... De aki azt hiszi, hogy ebben a szakmaban nem kell folyton tanulni, meg valtozni stb. az halott Na meg minel tobbet latott az ember, annal nagyobb a ralatasa. Nem abbol lesz jo architect, aki 15 evig utotte ugyanazt a fos legacy kodot valahol... -
Ez nem feltétlen ui. Mármint.. ha te értesz a javascripthez az nem feltétlen jelenti azt, hogy te gui ninja vagy. Egy normális cégnél, egy javascriptes projekten, mondjuk 1,2 ember foglalkozik a gui-val (=css, html), az összes többi, mondjuk 3 frontend fejlesztő csak az üzleti logikával, megint másik 2,3,5 a backenddel. Ugye a backend lehet bármi. Általában java, webservicekkel, vagy akár nodejs, .net stb...
Az, hogy nem találkoztál a javascripptel eddig igencsak meglepő. A legtöbb enterprise rendszerben, aminek valami köze van a webhez, ott 100%, hogy megjelenik valamilyen szinten a js. Van ahol kevésbé, csak designolás miatt. Van ahol sokkal inkább. Pl apache cordova (alias PhoneGap), vagy ha pl van valamilyen I/O app, arra a legalkalmasabb momentán a node.
Szóval az én véleményem az, hogy egy mai programozónak valamilyen szinten tisztában kell lennie a js-el, mert előbb-utóbb találkozni fog vele. Én nem várnám el mindenkitől, hogy értsen hozzá, de azt elvárnám, hogy rálátás nélkül ne mondja rá, hogy szar, csak azért mert nem ismeri O.o
És igen, szerintem is abban teljesen igazad van, hogy nem az a jó szakember, aki ehhez, vagy ahhoz nagyon ért, majd mindent abban próbál megoldani, hanem inkább az, aki képes felismerni, hogy egy feladatot miben érdemes megoldani, majd az új technológiát képes minél gyorsabban a magáévá tenni.
Nem mondtam, hogy nem talalkoztam vele, sajnos talalkoztam tobbet mint akarnek
De mindig tudatosan es szandekosan kikerulom, ahogy lenyegeben az osszes java fejleszto, akit valaha ismertem. Rossz, nem rossz, ez van, faszom se akar expert lenni javascriptbol ... Van ralatasom szerintem epp eleg, hadd mondjam mar valamire hogy szar, ha az a velemenyem Nem mondtam, hogy ez az objektiv igazsag vagy nekem van igazam ez ugyben, aki szereti csinalja.Mas: javafx ugyben mi a velemenyetek?
-
Közvetlen alternatíva nincs. Csak a legtöbb compile to js. Még az egyik ami a legígéretesebb a js leváltására az a Dart.
javascript az egy fos
Ebből a hozzászólásodból csak az jön le, hogy nem értesz hozzá, se a dolgokhoz. Ne vedd magadra, de tényleg. Most szar a C#, a Delphi, a Haskell, csak azért mert nem értek hozzá? Mert ennyi erővel ezekre én is mondhatnám, hogy szar...
10 évvel ezelőtt még lehet, hogy szar volt, de napjainkban a js aranykorát éli. Ha valaki tudja a bad habits-et, és azokat kerüli, neadj isten még ismeri a hasznos könyvtárakat, toolokat, akkor igenis nagyon baró cucc.
Lehet igazad van, de attol ez meg nekem mindig egy fos marad
Persze megszokni mindent meg lehet, meg beletanulni ... De ahogy Winkler szokta mondani, altalaban ezek a "meg kell szokni" dolgok siman csak azt jelentik, hogy szar
Az meg, hogy luxus lenne kikerulni ... Nem tudom, eddig sikerult. Meg sokaknak sikerul, siman nem mennek el UI-t fejleszteni es ennyi. Persze valamikor luxus valamit kikerulni vagy ignoralni, es igen, hulye nem vagyok, hogy ha csinalni kell valamit aminek a legjobb modja jelenleg ez vagy az, akkor azt csak azert kikeruljem mert nem szeretem. Ertelmes mernok ilyet nyilvan nem csinal ...Jo de verpistike kettot akkor mar javascript ui fejlesztonek hivjak ...
De a listat lementem koszi -
Nézd, én nem mondtam soha senkinek, hogy könnyű. Meg kell ezt is tanulni, és kell hozzá tapasztalat. Ha a "könnyebb" utat választanád, akkor vehetsz hozzá designer-t is, de azt is tanulni kell. Lehet jól csinálni, és lehet nagyon rosszul is. Több szintje van a frameworknek: class management, core, alap komponensek, összetett komponensek; utóbbit nem mindig érdemes használni épp hasonló okok miatt, mint ami a vaadin problémája is.
Debugolni, és pofozgatni szerintem lényegesen jobb, mint a többit, csak sajnos nem tudsz odaülni egy 2 órás gyorstalpaló után LHC-vezérlő GUI-t gyártani/debugolni. Megint csak sajnálatos - amitől sokan fáznak - hogy a JS-fejlesztésnek sok buktatója van a laza típusosság miatt. Ez van, ezekből tudsz gazdálkodni.
Mihelyst egy összetettebb UI-ra van szükséged, meg vagy lőve, bármilyen frameworköt használsz, mert vagy elrejt tőled olyan dolgokat, ami idővel kelleni fog, vagy rádönti. Nincs bölcsek köve - itt sem.szerk.: az MVC részét nem feltétlenül érdemes erőltetni, mert kiszervezi a komponensekből a működést, ami szerintem megint egy olyan hiba, ami a hagyományos frontend fejlesztés megszokásaiból ered.
"Megint csak sajnálatos - amitől sokan fáznak - hogy a JS-fejlesztésnek sok buktatója van a laza típusosság miatt."
Szepen fogalmazol .... En inkabb ugy mondanam, hogy ez az egesz javascript egy fos szutyok sz*r g*ci szemet, es a lenyeg hogy ne kelljen hozzanyulnom ...
Szerintem egyre jobbal elvalik a UI fejlesztes, fel kell ezekre venni kulon javascriptes embert, mert ertelmes fejleszto nem szivesn nyul hozza ... -
Webes kliensnél? Erre nem fogsz jó választ kapni. Mindenki elmondja a véleményét
A generálás szvsz egyáltalán nem követendő. Manapság van pár divatos frontend platform: AngularJS, JQuery, Sencha Touch/ExtJS, Dojo, meg még sok más hasonló framework. Nekem ezekkel kapcsolatban az a meglátásom, hogy az első kettő elég ingatag, állandó pletykák keringenek a támogatásukkal kapcsolatban. A Dojo egy kicsit komolyabb háttérrel rendelkezik, de a Sencha-hoz képest kevésbé teljes termék.
A Touch/ExtJS nem egyszerű eset, ha tanulni kell, mert a tipikus frontendes számára érthetetlen, hogy szoftveres logikára épül (Java/PHP fejlesztők számára készült inkább), ezért sokan kerülik, bár nálunk ez van majd minden projektben. Sokakat az riaszt, hogy nem GPL felhasználáskor fejlesztői licenc kell hozzá, bár amennyi emberórát elpocsékoltak itt páran JQuery komponensek keresésével/illesztésével, abból kijönne pár licenc. -
Tudom, hogy nem igazán ide tartozik, de szeretném megkérdezni, hogy ti milyen gepen/notebookon fejlesztetek?
A mostani gépem Core 2 Duo 1,4GHz ULV, 4GB DDR3, 4500HD nem igazán birja az Eclipse ADT-t, nagyon sokszor 95-100%-on fut, s így használhatatlan, de nem tudom mire cseréljek, egy i5 4200M már elég, vagy kell a i7 4702MQ?Köszönöm a válaszokat
-
Igazabol eleg nehez megmondani, hogy mit kene tanitani ahhoz, hogy jo programozo legyen aki kijon. Szerintem peldaul annak idejen hianyzott, hogy nem meseltek egy szot sem a verziokezelo meg hibakatalogus rendszerekrol; vagy hogy mi az a kovetelmenykezeles, meg coding standard.
Masreszt meg en 98-ban jottem ki az egyetemrol, java-t csak egy speckoll-on, egy lelkes phd-stol hallgattunk egy fel evet (a C++ meg mint bevez. az oop-be a C-s felev fele volt). Az valtozik, hogy mi a nyelv, de az nem, hogy mi az hogy melysegi kereses vagy verem (nalunk azert ezt egesz jol tanitottak; aztan kesobb voltam demonstrator a gyakorlatan, de az akkori eloado mar kicsit mast rakott a tananyagba). Illetve nalunk nemigen volt csapatmunkas feladat, es pl. nem kellett dokumentaciot kesziteni (ma mar tudom, hogy javult legalabb a szakdolgozatnal az eloiras, pl. kotelezo lett a tesztstrategia es par eredmeny leirasa).Oppenheimer: mernokinfo szerintem az en idomben me'g nem is volt... de szo szerinti mernok nem is akartam volna lenni (nem az elektronok erdekelnek, hanem a magas szintu programnyelvekben alkotas), pont a masik iranybol kozelitettem, a matek absztrakt szintjerol. Amugy akkor me'g jate ttk.
-
-v-
addikt
Én is egyetemista vagyok, nem így látom a helyzetet, inkább a hallgatók nagy részének a hozzáállásával van a baj.
-
-v-
addikt
A főnököm meg a Java ellenzők sorában áll már régóta
C fejlesztő az istenadta Overengineering...mindig ezzel zsibbaszt 
-
"Miért használsz prefixet a fieldeknél? Az se túl jó gyakorlat manapság"
Mi a baj vele? Androidon elég gyakori.
Sorry androidot nem láttam, ahhoz nem (sem
) értek 
(#5288) floatr: hát részletkérdés az igaz, de szerintem rontja eléggé az olvashatóságot. És ha pár ilyen részletkérdés mind "rosszul" van és összeadódnak, akkor máris bajban lehet az ember ... vagy legalábbis nekem ez a tapasztalatom, de lehet csak én szopom be mindig az ótvar legacy code baseket
-
-v-
addikt
Nem jó sajnos, mert statikus függvénnyel is érem el a statikus változót, így nem tudom felüldefiniálni a függvényeket.
Mutatom mi a konkrét scenario:
public class DatabaseManager extends OrmLiteSqliteOpenHelper {
private static final AtomicInteger sUsageCounter = new AtomicInteger(0);
private static DatabaseManager sInstance = null;
public static synchronized DatabaseManager getHelper(Context context) {
if (sInstance == null) {
sInstance = new DatabaseManager(context);
}
sUsageCounter.incrementAndGet();
return sInstance;
}
@Override
public void close() {
if (sUsageCounter.decrementAndGet() == 0) {
super.close();
sInstance = null;
}
}
}Na most ebből lett két külön osztály, és ahhoz jelenleg ezt a kódot mind le kell kopiznom.
Miért erőlteted ezt a staticot, én se értem ... amúgy ezek a helper classok mennyire bad practice... előjöttek a rossz emlékek
Miért használsz prefixet a fieldeknél? Az se túl jó gyakorlat manapság (#5278) WonderCSabo: hát, a kód duplikáció az sose jó
Amúgy: java-ban nincs függvény
Metódus van. De szerintem az adattag is c++ terminológia.edit: ja most látom, hogy androidról beszélünk
-
-
A default methodokkal interfészekhez lehet alapértelmezett implementációkat írni, tehát ha van valami közös funkció amit egy interfészt megvalósító osztályoknak mindnek tudnia kell, és pont ugyanúgy, akkor nem kell se abstract ősosztály, se kódot ismételni.
A végeredmény hasonló, mint az extension methodok C#-ban.
De ott van a streams API is, elég erős túlzás hogy nincs a Java 8-ban semmi új... Meg a lamdba szintaxissal sincs baj szerintem – mindig azt vallottam és tartom is, hogy minél kevesebb kódot ír az ember, annál jobb.
-
Hype. Mondjuk az is költői túlzás, hogy "ez a lambda egy mekkora szar", de ha ez a sztár, akkor az oracle monnyonle.
A lambda meg a funkcionalis dolgok tok jok, en konkretan most arra ertem amit a java 8-ba beleraktak ... na annak ebben a formaban semmi ertelme szerintem. De most tenyleg, sporolok par sort, hogy nem kell anonymus classt csinalnom, es ennyi (amit amugy is baromi ritkan, 1-2 speci esetben hasznalni, mert nem valami jo gyakorlat) ... a fordito meg ugyis ugyanazt csinalja belole.
Ezen kivul meg lettek default methodok, es ennyi, ez a java 8? De tenyleg, nem hozott semmi ujat ...
-
Az van, hogy kidobnak egy új verziót, ami kvázi használhatatlan, ha egy hello world-nél összetettebb projektet akarsz kezelni. Aztán fél évre rá már tarthatatlan a sok bugreport miatt a helyzet, és kiadnak egy javítást SR1 néven, majd később a megmaradt nem kritikus hibák javításaira is adnak ki egy második javítást SR2 néven. Közben elkezdik összerakni a következő release-t. Szóval ha stabil Eclipse-re vágysz, akkor ahhoz az SR2 kiadások állnak a legközelebb, bár kicsit elgondolkodtat ez a frissen felbukkant java 8 támogatás.
Az a bosszantó, hogy az első kiadást soha nem tudtuk munkára fogni, mert annyira hemzsegett a hibáktól. Nem is értem, hogy ezt is miért nem hívják publikus bétának.
Ez így van pontosan ahogy írod...
-
-
Ha van egy változód, ami akár objektum, akár egyszerű típus, akkor ez a megoldás mindig működik. Sőt még akkor is, ha a változó null. Ha viszont nincsen saját toString metódus, akkor pointer értéket fog kiírni.
Ezzel annyit érsz el, hogy a println() String paraméteres verziója hívódik meg. És az azért jobb neked... mert?
"Ha van egy változód, ami akár objektum, akár egyszerű típus, akkor ez a megoldás mindig működik."A "" + nélkül is.
Ha azt mondod
System.out.println(myObject);
System.out.println("" + myObject);
és a myObject null, mindkét esetben "null"-t fog kiírni. Ha nincs felüldefiniálva a toString-je, akkor is ugyanazt írja ki mindkét esetben (MyObject@120cc56 pl ... ). Ha nem referenciatípus, hanem primitív típus, akkor sincsen különbség, println() mindenre túl van terhelve. Még mindig nem értem mire jó ez... nem kell se toString se semmi, println(amitakarszkiiratni) aztán szevasz ...
Ott van különbség ha pl. int-ek, ha nincs előtte "" akkor a + miatt összeadja mielőtt kiírja, ha meg egy ""-t odaraksz elég onnantól stringként kezeli és konkatenálgatja.. de itt most ilyesmi nem volt kérdés. -
-v-
addikt
+1
Illetve párhuzamos programozásból tudnátok ajánlani valamit ? -
Sziasztok
Valaki elmagyarázná nekem, hogy miért a D a jó válasz. Szerintem az A.
interface SampleClosable {
public void close () throws java.io.IOException;
}A.
public class Test implements SampleCloseable {
Public void close () throws java.io.IOException {
/ / do something
}
}
B.
public class Test implements SampleCloseable {
Public void close () throws Exception {
/ / do something
}
}
C.
public class Test implementations SampleCloseable {
Public void close () throws Exception {
/ / do something
}
}
D.
public class Test extends SampleCloseable {
Public void close () throws java.IO.IOException {
/ / do something
}
}Előre is köszi a segíséget!
üdv.:
vgergoPersze, A a jó
Vagyis egyik se, mert "Public void close" mindenhol uppercase a public
-
Tudnátok segíteni nekem? Ezt akarom használni fájlmásolásra: http://filecopylibrary.sourceforge.net/
Van egy mentesFrame.java JFrame fájlom amin van egy mentesPanel.java JPanelem.
A mentesPanelen van egy gomb ami megnyomásakor grafikus felületen kellene másolnia a FileCopierPanel-nek, SwingWorker-be raktam, de mégse frissíti rendesen az ablakot:
private void mentesGombActionPerformed(java.awt.event.ActionEvent evt) {
mentesFunkciok mFunk = new mentesFunkciok();
try {
mFunk.doInBackground();
} catch (Exception ex) {
Logger.getLogger(mentesAblakPanel.class.getName()).log(Level.SEVERE, null, ex);
}
}A mentesFunkciok fájl:
public class mentesFunkciok extends SwingWorker<Integer, Integer> {
Source[] sources = new Source[]{
new Source("D:\\Elektronikus dolgok\\teszt\\hostgep")
};
String[] destinations = new String[]{
"D:\\Elektronikus dolgok\\teszt\\celgep\\"
};
CopyJob copyJob = new CopyJob(sources, destinations);
@Override
protected Integer doInBackground() throws Exception {
JFrame frame = new JFrame();
frame.setSize(400, 200);
frame.setLocationRelativeTo(null);
FileCopierPanel panel = new FileCopierPanel();
FileCopier fc = new FileCopier();
panel.setFileCopier(fc);
frame.add(panel);
frame.setVisible(true);
fc.copy(copyJob);
return null;
}
}Min kellene változtatnom, hogy ne csak "fehérség" legyen az ablakban másolás végén?
-
Megnézegetem, hogy itt miket lehet fellelni, köszi. Codingbat-ot nézegettem eddig. Valami olyasmit keresek, ami azért nem az egy-két osztályos minifeladat, hanem egy fokkal bonyorultabb, jó gazdag magyarázattal, hogy mi miért lett úgy megvalósítva, ahogy. Mondjuk ez nem is igazán java specifikus, inkább OOP, de ha java nyelven van hozzá a példa, az mégjobb
Mert akkor elég egyértelmű:
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Nem kell még temetni: 2 éves órajelcsúcsot döntöttek meg Raptor Lake-kel
- Asustor NAS
- Yettel topik
- Mesterséges intelligencia topik
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- Villanyszerelés
- HiFi műszaki szemmel - sztereó hangrendszerek
- Forza sorozat (Horizon/Motorsport)
- Házimozi belépő szinten
- Óra topik
- További aktív témák...
- Kingston KC3000 PCIe 4.0 NVMe M.2 2TB-os, bontatlan SSD, 2 év garanciával eladó!
- Samsung 990 Pro 1TB-os PCIe 4.0 M.2 NVMe 2280 SSD, bontatlanul, 2 év garanciával eladó!
- ADATA Legend 900 Pro 2TB-os PCIe Gen4 M.2 NVMe 2280 SSD, bontatlanul, 5 év garanciával eladó!
- AMD R7 350X és RX550 VGA kártyák
- Megvigyázott, 3,5 éves, 128 Gb, iPhone 13, 81% akku
- Samsung 870 QVO 8TB Sata 2.5 SSD
- BESZÁMÍTÁS! Sapphire Pure RX 9070 XT 16GB videokártya garanciával hibátlan működéssel
- Töltő Bazár! kb. 1000-1500Ft/10W, Rengeteg féle, SZÁMLÁVAL, GARANCIÁVAL
- Xbox One / Xbox Series játékok
- Lenovo ThinkPad L13 Gen 3 i5-1245U 16GB 256GB FHD+ IPS 1 év teljeskörű garancia
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest