<?xml version="1.0" encoding="ISO-8859-15"?>
<rss version="2.0"><channel>
<title>the daily Java WTF</title>
<link>http://sange.fi/~atehwa/cgi-bin/piki.cgi/</link>
<description>Recent changes in the daily Java WTF</description>
<item><title>the daily Java WTF</title>
<link>http://sange.fi/~atehwa/cgi-bin/piki.cgi/the%20daily%20Java%20WTF</link>
<guid>http://sange.fi/~atehwa/cgi-bin/piki.cgi/#1488375271</guid>
<description>&lt;p&gt;!!! &lt;ins&gt;ke 1.3.2017&lt;/ins&gt; 

&lt;p&gt;&lt;ins&gt;Javassahan ei ole mitään tapaa eikä käytäntöä sille, miten 
valmis, käännetty softa (joka yleensä levitetään .jar- tai 
.war-tiedostona) löytää käyttämänsä kirjastot. Siksi ne kirjastot 
yleensä levitetään .jar-tiedoston mukana. Tähän on yleistynyt käytäntö, 
että build-työkalut osaavat paketoida kirjasto-.jar:t softa-.jar:n 
sisään, niinsanotuksi "überjar":ksi.&lt;/ins&gt; 

&lt;p&gt;&lt;ins&gt;Yhdistetäänpä tämä siihen, että on tyypillistä käyttää joka 
softaan kaiken maailman frameworkeja ja kirjastoja, jotka puolestaan 
vetävät lisää kirjastoja sisään. Seuraus on, että suhteellisen 
yksinkertainen API-toteutus, joka käyttää Spring Bootia, Google Guavaa, 
Lombokia ja JAXBia, vie käännettynä .jarrina levyltä 38 megatavua. 
Mutta ei se ole varsinainen ongelma, vaan se, että sitten javalla 
ajettuna tämä .jar vie muistia 3 '''gigatavua''' josta muistissa 300 
megatavua. Niin että jos luulette, ettei modernia pöytäkonetta saa 
polvilleen muutamalla mikroservicellä, niin kyllä saa. Kunhan valitsee 
teknologiaksi Javan.&lt;/ins&gt; 

&lt;p&gt;&lt;ins&gt;!!!&lt;/ins&gt; ma 27.2.2017 

&lt;p&gt;[...]

</description>
<pubDate>Wed, 01 Mar 2017 13:34:31 +0000</pubDate>
</item>

</channel></rss>
