Gradlen run-taskia ei ole olemassa, joka teki ohjelman suorittamisesta aluksi hieman hankalaa.
FileOutputStream luo automaattisesti tiedoston, jos sitä ei ole, joten fileToLoad.createNewFile() on turha.
PriorityQueue on sisäänrakennettuna tietorakenteena käytössä Huffman-puiden toteutuksessa enkä näe että sitä oltaisiin yritetty vaihtaa omaan toteutukseen.
BinaryTree-luokan rivin 32 return on turha. (Jäänne rakennemuutoksesta?)
System.arraycopy'ä ja ByteUtils.arrayCopyä on sekaisin; on varmaan parempi muuttaa kaikki jälkimmäisiksi (tai sitä vastaaviksi).
modifyCombinedByte ei pitäisi vaatia castauksia - yhdelle riville kirjoitettuna se olisi esimerkiksi return (byte) (one | ((other & 0xFF) >>> otherCutPoint));, tosin en tiedä onko se niinkään selkeämpi.
(int) Math.floor((numOfBits - 1) / 8): Math.floor ei tarpeellinen, koska muuttaminen kokonaisluvuksi tekee sen automaattisesti tässä tapauksessa. Teknisesti muuntoakaan ei tarvitsisi tehdä, koska numOfBits on jo kokonaisluku, jolloin jakolaskukin tuottaa aina kokonaisluvun, mutta se voi selventää.
Huomioitani:
run-taskia ei ole olemassa, joka teki ohjelman suorittamisesta aluksi hieman hankalaa.FileOutputStreamluo automaattisesti tiedoston, jos sitä ei ole, jotenfileToLoad.createNewFile()on turha.BinaryTree-luokan rivin 32returnon turha. (Jäänne rakennemuutoksesta?)System.arraycopy'ä jaByteUtils.arrayCopyä on sekaisin; on varmaan parempi muuttaa kaikki jälkimmäisiksi (tai sitä vastaaviksi).modifyCombinedByteei pitäisi vaatia castauksia - yhdelle riville kirjoitettuna se olisi esimerkiksireturn (byte) (one | ((other & 0xFF) >>> otherCutPoint));, tosin en tiedä onko se niinkään selkeämpi.(int) Math.floor((numOfBits - 1) / 8):Math.floorei tarpeellinen, koska muuttaminen kokonaisluvuksi tekee sen automaattisesti tässä tapauksessa. Teknisesti muuntoakaan ei tarvitsisi tehdä, koskanumOfBitson jo kokonaisluku, jolloin jakolaskukin tuottaa aina kokonaisluvun, mutta se voi selventää.(Latasin lähdekoodin 26.4.2019 kello 21:10)