Megyen!

Az 1-es: amikor létrehozol UI elemeket (pontosabban ha jól emlékszem legkésőbb akkor, amikor pack()-el lefoglalod a rendszertől őket), a háttérben létrejön egy új szál, ami a UI eseményeket dolgozza fel, az AWT Event thread. Innentől kezdve - akarva, akaratlanul - többszálú a programod, ha más nem addig, amíg a main() függvényed nem végez - az eseménykezelőket az event thread-ben futtatja az AWT (egy eseménykezelőben levő Thread.sleep hívás pl. szépen meg tudja fagyasztani az UI-t).

És ebből következik az, hogy nem "illik" más thread-ből módosítani az UI elemek állapotát, mert ezzel bejön a képbe a szinkronizáció összes problémája. A SwingUtilities osztályban van két metódus (invokeLater és invokeAndWait), amikkel át tudsz adni egy Runnable példányt, hogy amikor éppen nincs dolga az AWT Event Thread-nek, akkor futtassa le őket - az előbbi azonnal vissza is tér, az invokeAndWait pedig vár, amíg ténylegesen le is futott (vagy dob egy kivételt, ha gond volt).

Így pl. egy fájl mentés (tipikus "lassú I/O" feladat) úgy néz ki, hogy a gombra kattintásra lefut az AWT Thread-ben az eseménykezelő, ami mondjuk megjelenít egy progress bar-t aztán indít egy új Thread-et és vissza is tér. Az új Thread pl. kiírt blokkonként invokeLater-rel bedobja az event queue-ba, hogy "akkor a progress bar-t egy kicsit növelni kéne" (eredmény szempontjából mindegy, hogy mikor fut le és növeli a progree bar-t, a feldolgozás sorrendje miatt monoton nőni fog), és a fájl lezárása után invokeAndWait-el eltünteti a progress bar-t - ezzel a szál meg is szűnik.

A Look & Feel dolog: a Swing nem feltétlenül az OS natív UI komponenseit használja (az AWT-tal és a "közös nevező" megoldással ezt csúnyán megszívták), nagyon sok komponens önmagát rajzolja ki - egy külön nyilvántartott téma alapján, ezek az ún. Look and Feel-ek. Többnyire szokott lenni a rendszerbe illő téma (UIManager.getSystemLookandFeel), van a default (azt hiszem Metal a neve), de sajátot is telepíthetsz ill. futás közben lekérdezheted a telepített LaF-ok listáját (http://docs.oracle.com/javase/7/docs/api/javax/swing/UIManager.html#get…()).
Nem akarok hülyeséget mondani, mert nem emlékszem, hogy pontosan melyik look and feel volt, de van olyan, ami minden publikus metódusban azzal nyit, hogy ellenőrzi, az AWT Event Thread-ben hívták-e (SwingUtilities.isEventDispatchThread() megmondja), és ha nem, akkor azonnal dob egy exceptiont.

A 2: tényleg csak annyi, hogy a konstruktor-ban ne tedd láthatóvá az ablakod, mert így később nem tudod majd kompozícióval más osztályokban használni - mert amint létrehozod a példányt, az meg is jelenik (ha nagyon sarkítani akarnék, akkor ez mellékhatásnak minősül). És nagyjából ipari standard a kívülről később nem hivatkozott ablakok létrehozására+megjelenítésére a new FooWindow().setVisible(true); forma, előbb-utóbb úgyis meg kell szoknod :)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

"Igen, természetesen. Sőt..."

Átnéztem én is. :)

1. Amikor osztályról, metódusról, paraméterről írod le, hogy mit csinál, az lehetne javadoc is.
2. A Fields, Constructors, Methods kommentek szerintem feleslegesek, de ez egyéni ízlés kérdése is, végülis nem bántanak senkit.
3. Nem használsz package-eket, ami egyelőre nem gond, de előbb-utóbb nem árthat, pl. én külön package-be raknám a guit és a modellt. Illetve a default package-be nem szerencsés kódot rakni, pl. névütközéseknél problémás lehet.
4. Az előző ponthoz kapcsolódik, az osztályaid, metódusaid mind package private (modifier nélküli) láthatóságúak, érdemes mindig a célodnak megfelelő láthatóságokat használni, de ez csak onnantól érdekes, ha több package-ed van.
5. A CrossWord osztályban a Row és Column eltárolásának jelenleg nem látom sok hasznát, egyrészt mert nem használod, másrészt mert javaban a tömbök tárolják magukról a méretüket a length attribútumban. Persze van, amikor nem tudod garantálni, hogy a tömb le is van foglalva, vagy épp egy mátrix egyik dimenziója nulla elemű, ekkor van értelme letárolni, különben elveszne az információ.
6. A Square osztály jelenleg több felelősséggel rendelkezik. Egyszerre lehet benne karaktereket, számokat, fekete négyzeteket, határvonalakat tárolni. A problémára alapvetően a leszármazás a megoldás, vagyis a Square egy abstract osztály vagy interface, és ennek vannak konkrét implementációi, pl. CharacterSquare, NumberSquare, BlackSquare, sőt, EmptySquare. A határvonalakhoz én a decorator patternt használnám. Ez a változtatás annyi módosítást hozna magával, hogy futásidőben kellene cserélgetni a modellben tárolt objektmokat, de ez mindössze 2-3 sor módosítást jelentene a CrossWord osztályban. Ha érdekel, ezt részletesebben is ki tudom fejteni.
7. A Square osztályban a határvonalakat egy bitmaszkkal tárolod. Ez alapvetően nem rossz megoldás, viszont az annak állítgatására kitalált módszered nem épp fejlesztő barát. A witch byte-ról ugyanis ki kell deríteni, hogy milyen sorrendben kódolod benne az oldalakat, mi történik, ha egynél több bit 1 benne, illetve mi a metódus szemantikája (esetedben xor). Ehhez mind az implementációt kell nézegetni vagy dokumentációt kell olvasni, röviden nem egyértelmű az api. Valamivel szebb megoldás lenne, ha egyrészt a setSideLine helyett mondjuk toggleSideLine lenne a metódus neve (ezzel máris tudom, hogy xor van mögötte), másrészt valahogy nevesíted az oldalakat. Erre C-ben az a megoldás, hogy definiálsz 4 konstans byteot a 4 oldalhoz, amiket akár vegyíthetsz is bitenkénti vaggyal. Javaban szerintem viszont szebb, ha enumot vársz, amiben szintén nevesítve van a 4 oldal. Az enum javaban egyben osztály is, vagyis minden oldalhoz letárolhatod, hogy milyen byte érték tartozik hozzá, vagyis a metódusban továbbra is megmaradhat az xor, csak az enumból kell kivenni a which byteot. Nem tudom ez így mennyire érthető, ezt is kifejtem jobban ha érdekel.