Re: javac vs. Eclipse - čísla řádků v .class u víceřádkových výrazů
Ja len doplnim. Eclipse kompilator dokaze kompilovat aj projekty (defacto
adresare so zdrojakmi) s cyklickymi zavislostami, co sa s antom, mavenom
alebo javac robi velmi tazko (vlastne to nepodporuju). V tomto smere
podporuje viacprechodovu kompilaciu. Eclipse kompilator sa da pouzivat aj
ako standalone kompilator. Je to asi pat pluginov, ktore treba mat a je
nejaka classa cez ktoru sa to spusta. Da sa to najst na nete.
Co sa tyka inkrementalnych buildov, tak tie su podporovane aj mavenom, ale
neviem co to znamena pre kompilaciu. V ideckach okrem inkrementalnych
buildov, co je pre mna samozrejmost, by mal byt este specialny parser java
zdrojakov as you write. To napr. eclipse ma. Je to vyhoda, lebo programator
vidi co pise este pred ulozenim (save), co moze byt niekedy pekna otrava.
Ak sa spravne pamatam, tak sun javac vyvijal javac iba ako zakladnu
implementaciu kompilatora, teda urcite nie na integraciu do IDE.
Tomas
2011/4/26 Robert Novotny robert.novo...@upjs.sk
Informacii o tom kompilatore nie je vela. Prakticky sa vie len to, ze
Eclipse Compilator (ECJ) sa hrdi inkrementalnou kompilaciou, co znamena, ze
v ramci projektu sa udrziava mnozina zmien v suboroch, ktora nastala od
poslednej kompilacie. Pri rekompilacii sa zisti len zoznam zmenenych /
novych suborov od predoslej kompilacie a z nich sa vyrobia .class subory. Ak
je nejaky .java subor vymazany, prislusny .class sa pri inkrementalnej
kompilacii vymaze tiez.
ECJ tiez udrziava komplexny strom zavislosti medzi .java zdrojakmi, cim
adresuje napr. pripady, ked sa niektore zmenene subory daju skompilovat a
niektore kvoli chybam nie a minimalizuje pocet suborov, ktore treba skutocne
prekompilovat.
Tato featura bola dost vyznamna v casoch, ked este NetBeans nemal
compile-on-save a nesiel cez Ant, ale dnes aj Ant kompiluje len zmenene
subory (hoci netusim, ako je to v NetBeans a megaprojektoch).
ECJ ma zrejme lepsiu integraciu s reportovanim chyb, mozno sa navesat cez
listenery a dostavat kompilacne chyby a varovania, ktore mozno programovo
spracovat. Dnes uz samozrejme existuje javax.tools, ale to je len zalezitost
JDK1.6+ a predtym to zdaleka nebol standard
A ako povedal kolega, Eclipse kompilator ma ine spravanie v pripade chyb:
public class Thing {
public void getSecret() {
return x;
}
public static void main(String[] args) {
new Thing().getSecret()
}
}
ECJ to radostne skompiluje a za behu metoda getSecret() hodi
java.lang.Error: Unresolved compilation problem.
Javac to odmietne skompilovat.
Inak ECJ sa uz od nepamati pouziva v Tomcate na kompilaciu servletov, ktore
vzniknu z JSP stranok.
RN
On 25. 4. 2011 22:17, Libor Jelinek wrote:
Já patřím mezi asi tu masu co nikdy nekompilovala ničím jiným, než Oracle
javac (taky mi to nejde z pusy, ale snažím se :-)). Nikdy jsem se nesetkal s
Blackdown, Ice, gjc apod. kompilátory.
A NetBeans používá taky vlastní kompilátor?
Když dám v Eclipsech Build, tak mi to přeloží jakým kompilátorem? Když
(jako ve zmíněném příkladu z Stackoverflow) Eclipse zkompiluje, ale
Sun/Oracle nikoli, tak jak se to pak chová při běhu oproti Sun/Oracle JRE?
2011/4/25 Ladislav Thon ladi...@gmail.com
Já kupříkladu narazil na rozdíly v kompilaci při volání metody se
signaturou používající Enum?, Eclipsí kompilátor to zvládl na jedničku,
javac měl problémy, viz diskuze na stackoverflow.com:
http://stackoverflow.com/questions/2220763/java-specific-enums-and-generic-enum-parameters
Překladače mohou odvozovat parametrizované typy nad rámec minimálních
požadavků. Suní překladač (hádám, že Oraclí začnu říkat nejdřív za pět
let) se moc nesnaží, překladač z Eclipsu toho zvládne odvodit víc. Neznamená
to, že některý z překladačů je vadný, jenom že o tom lidi moc neví.
LT
Ovšem pokud používáte Maven, musíte se stejně podřídit standardnímu javac
(tedy pokud neexistuje nějaký Maven plugin, který by uměl použít pro
kompilaci Eclipse -- a i kdyby existoval, ani bych ho snad nechtěl použít).
Martin Schayna
On 04/25/2011 02:25 PM, Libor Jelinek wrote:
To jsou tedy vlastnosti s ohledem na IDE. Já stejně většinou používám
javac z Oraclího JDK přes Ant, tak jsem jen chtěl vědět, zda náhodou není
Eclipse compliter třeba několikanásobně rychlější/lepší apod. :-)
Díky.
Libor
Dne 25. dubna 2011 11:17 Filip Jirsák fi...@jirsak.org napsal(a):
Kompilátor eclipse například umožňuje přeložit i třídu s chybou (chyba
v syntaxi v nějaké metodě apod.), jenom místo kódu dané chybné metody
vloží vyhození nějaké runtime výjimky. K tomu asi sunovský kompilátor
nedonutíte. Eclipse (IDE) pak ten přeložený kód používá pro code
completion a spol., kde je užitečné, aby jedna chybná metoda
nezabránila získávat informace o zbytku třídy a ostatních třídách. Na
druhou stranu je potřeba si na to dávat pozor a finální verzi přeložit
s plnou kontrolou chyb, aby se ten kód, kde se místo nějaké metody
bude vyhazovat výjimka na řádku 353 chybí
Re: javac vs. Eclipse - čísla řádků v .class u víceřádkových výrazů
Ten Váš úryvek však ECJ v mých Eclipsech (Helios Service Release 1, Build
id: 20100917-0705) nezkompiluje. Vypíše (správně) chybu:
*Exception in thread main java.lang.Error: Unresolved compilation problem:
x cannot be resolved to a variable
at Thing.getSecret(Thing.java:3)
at Thing.main(Thing.java:7)*
Libor
Dne 26. dubna 2011 0:26 Robert Novotny robert.novo...@upjs.sk napsal(a):
Informacii o tom kompilatore nie je vela. Prakticky sa vie len to, ze
Eclipse Compilator (ECJ) sa hrdi inkrementalnou kompilaciou, co znamena, ze
v ramci projektu sa udrziava mnozina zmien v suboroch, ktora nastala od
poslednej kompilacie. Pri rekompilacii sa zisti len zoznam zmenenych /
novych suborov od predoslej kompilacie a z nich sa vyrobia .class subory. Ak
je nejaky .java subor vymazany, prislusny .class sa pri inkrementalnej
kompilacii vymaze tiez.
ECJ tiez udrziava komplexny strom zavislosti medzi .java zdrojakmi, cim
adresuje napr. pripady, ked sa niektore zmenene subory daju skompilovat a
niektore kvoli chybam nie a minimalizuje pocet suborov, ktore treba skutocne
prekompilovat.
Tato featura bola dost vyznamna v casoch, ked este NetBeans nemal
compile-on-save a nesiel cez Ant, ale dnes aj Ant kompiluje len zmenene
subory (hoci netusim, ako je to v NetBeans a megaprojektoch).
ECJ ma zrejme lepsiu integraciu s reportovanim chyb, mozno sa navesat cez
listenery a dostavat kompilacne chyby a varovania, ktore mozno programovo
spracovat. Dnes uz samozrejme existuje javax.tools, ale to je len zalezitost
JDK1.6+ a predtym to zdaleka nebol standard
A ako povedal kolega, Eclipse kompilator ma ine spravanie v pripade chyb:
public class Thing {
public void getSecret() {
return x;
}
public static void main(String[] args) {
new Thing().getSecret()
}
}
ECJ to radostne skompiluje a za behu metoda getSecret() hodi
java.lang.Error: Unresolved compilation problem.
Javac to odmietne skompilovat.
Inak ECJ sa uz od nepamati pouziva v Tomcate na kompilaciu servletov, ktore
vzniknu z JSP stranok.
RN
On 25. 4. 2011 22:17, Libor Jelinek wrote:
Já patřím mezi asi tu masu co nikdy nekompilovala ničím jiným, než Oracle
javac (taky mi to nejde z pusy, ale snažím se :-)). Nikdy jsem se nesetkal s
Blackdown, Ice, gjc apod. kompilátory.
A NetBeans používá taky vlastní kompilátor?
Když dám v Eclipsech Build, tak mi to přeloží jakým kompilátorem? Když
(jako ve zmíněném příkladu z Stackoverflow) Eclipse zkompiluje, ale
Sun/Oracle nikoli, tak jak se to pak chová při běhu oproti Sun/Oracle JRE?
2011/4/25 Ladislav Thon ladi...@gmail.com
Já kupříkladu narazil na rozdíly v kompilaci při volání metody se
signaturou používající Enum?, Eclipsí kompilátor to zvládl na jedničku,
javac měl problémy, viz diskuze na stackoverflow.com:
http://stackoverflow.com/questions/2220763/java-specific-enums-and-generic-enum-parameters
Překladače mohou odvozovat parametrizované typy nad rámec minimálních
požadavků. Suní překladač (hádám, že Oraclí začnu říkat nejdřív za pět
let) se moc nesnaží, překladač z Eclipsu toho zvládne odvodit víc. Neznamená
to, že některý z překladačů je vadný, jenom že o tom lidi moc neví.
LT
Ovšem pokud používáte Maven, musíte se stejně podřídit standardnímu javac
(tedy pokud neexistuje nějaký Maven plugin, který by uměl použít pro
kompilaci Eclipse -- a i kdyby existoval, ani bych ho snad nechtěl použít).
Martin Schayna
On 04/25/2011 02:25 PM, Libor Jelinek wrote:
To jsou tedy vlastnosti s ohledem na IDE. Já stejně většinou používám
javac z Oraclího JDK přes Ant, tak jsem jen chtěl vědět, zda náhodou není
Eclipse compliter třeba několikanásobně rychlější/lepší apod. :-)
Díky.
Libor
Dne 25. dubna 2011 11:17 Filip Jirsák fi...@jirsak.org napsal(a):
Kompilátor eclipse například umožňuje přeložit i třídu s chybou (chyba
v syntaxi v nějaké metodě apod.), jenom místo kódu dané chybné metody
vloží vyhození nějaké runtime výjimky. K tomu asi sunovský kompilátor
nedonutíte. Eclipse (IDE) pak ten přeložený kód používá pro code
completion a spol., kde je užitečné, aby jedna chybná metoda
nezabránila získávat informace o zbytku třídy a ostatních třídách. Na
druhou stranu je potřeba si na to dávat pozor a finální verzi přeložit
s plnou kontrolou chyb, aby se ten kód, kde se místo nějaké metody
bude vyhazovat výjimka „na řádku 353 chybí středník“ nedostal na
produkci.
S pozdravem
Filip Jirsák
Dne 25. dubna 2011 7:43 Libor Jelinek ljeli...@virtage.com napsal(a):
A jaký má Eclipse důvod mít vlastní kompilátor? A jaké má Eclipse
kompilátor
výhody? Oproti standardnímu javac od Oraclu?
Libor
Dne 19. dubna 2011 15:16 Tomáš Záluský zalu...@centrum.cz
napsal(a):
Eclipse kompilator se da pouzit i standalone, je nejaky duvod proc
ho tak
nemuzes pouzit v build procesu?
Zřejmě není, nejspíš na něj přejdeme. Budeme ale muset vyřešit, že je
to
pro Javu 1.5.
Omlouvám se za odmlku,
Re: javac vs. Eclipse - čísla řádků v .class u víceřádkových výrazů
Nenechajte sa zmiast.
Eclipse samozrejme zobrazi kompilacnu chybu v Problems, podciarkne Vam
zly vyraz... ale to, co vidite, je chyba, ktora vznikla za behu :-) To
co vidite, je stack trace vyhodenej vynimky java.lang.Error, ktora
nastala po spusteni triedy.
Alebo inak: pozrite sa do adresara s .class subormi, ECJ napriek
kompilacnej chybe vyprodukoval Thing.class a ked sa don pozriete nejakym
editorom / dekompilatorom / disasemblerom, tak uvidite, ze v nom je
metoda getSecret(), ktora ma prakticky jeden riadok: throw new Error()
On 26. 4. 2011 12:22, Libor Jelinek wrote:
Ten Váš úryvek však ECJ v mých Eclipsech (Helios Service Release 1,
Build id: 20100917-0705) nezkompiluje. Vypíše (správně) chybu:
/Exception in thread main java.lang.Error: Unresolved compilation
problem:
x cannot be resolved to a variable
at Thing.getSecret(Thing.java:3)
at Thing.main(Thing.java:7)/
Libor
Dne 26. dubna 2011 0:26 Robert Novotny robert.novo...@upjs.sk
mailto:robert.novo...@upjs.sk napsal(a):
Informacii o tom kompilatore nie je vela. Prakticky sa vie len to,
ze Eclipse Compilator (ECJ) sa hrdi inkrementalnou kompilaciou, co
znamena, ze v ramci projektu sa udrziava mnozina zmien v suboroch,
ktora nastala od poslednej kompilacie. Pri rekompilacii sa zisti
len zoznam zmenenych / novych suborov od predoslej kompilacie a z
nich sa vyrobia .class subory. Ak je nejaky .java subor vymazany,
prislusny .class sa pri inkrementalnej kompilacii vymaze tiez.
ECJ tiez udrziava komplexny strom zavislosti medzi .java
zdrojakmi, cim adresuje napr. pripady, ked sa niektore zmenene
subory daju skompilovat a niektore kvoli chybam nie a minimalizuje
pocet suborov, ktore treba skutocne prekompilovat.
Tato featura bola dost vyznamna v casoch, ked este NetBeans nemal
compile-on-save a nesiel cez Ant, ale dnes aj Ant kompiluje len
zmenene subory (hoci netusim, ako je to v NetBeans a megaprojektoch).
ECJ ma zrejme lepsiu integraciu s reportovanim chyb, mozno sa
navesat cez listenery a dostavat kompilacne chyby a varovania,
ktore mozno programovo spracovat. Dnes uz samozrejme existuje
javax.tools, ale to je len zalezitost JDK1.6+ a predtym to zdaleka
nebol standard
A ako povedal kolega, Eclipse kompilator ma ine spravanie v
pripade chyb:
public class Thing {
public void getSecret() {
return x;
}
public static void main(String[] args) {
new Thing().getSecret()
}
}
ECJ to radostne skompiluje a za behu metoda getSecret() hodi
java.lang.Error: Unresolved compilation problem.
Javac to odmietne skompilovat.
Inak ECJ sa uz od nepamati pouziva v Tomcate na kompilaciu
servletov, ktore vzniknu z JSP stranok.
RN
On 25. 4. 2011 22:17, Libor Jelinek wrote:
Já patřím mezi asi tu masu co nikdy nekompilovala ničím jiným,
než Oracle javac (taky mi to nejde z pusy, ale snažím se :-)).
Nikdy jsem se nesetkal s Blackdown, Ice, gjc apod. kompilátory.
A NetBeans používá taky vlastní kompilátor?
Když dám v Eclipsech Build, tak mi to přeloží jakým
kompilátorem? Když (jako ve zmíněném příkladu z Stackoverflow)
Eclipse zkompiluje, ale Sun/Oracle nikoli, tak jak se to pak
chová při běhu oproti Sun/Oracle JRE?
2011/4/25 Ladislav Thon ladi...@gmail.com
mailto:ladi...@gmail.com
Já kupříkladu narazil na rozdíly v kompilaci při volání
metody se signaturou používající Enum?, Eclipsí
kompilátor to zvládl na jedničku, javac měl problémy, viz
diskuze na stackoverflow.com http://stackoverflow.com:
http://stackoverflow.com/questions/2220763/java-specific-enums-and-generic-enum-parameters
Překladače mohou odvozovat parametrizované typy nad rámec
minimálních požadavků. Suní překladač (hádám, že Oraclí
začnu říkat nejdřív za pět let) se moc nesnaží, překladač z
Eclipsu toho zvládne odvodit víc. Neznamená to, že některý z
překladačů je vadný, jenom že o tom lidi moc neví.
LT
Ovšem pokud používáte Maven, musíte se stejně podřídit
standardnímu javac (tedy pokud neexistuje nějaký Maven
plugin, který by uměl použít pro kompilaci Eclipse -- a i
kdyby existoval, ani bych ho snad nechtěl použít).
Martin Schayna
On 04/25/2011 02:25 PM, Libor Jelinek wrote:
To jsou tedy vlastnosti s ohledem na IDE. Já stejně
většinou používám javac z Oraclího JDK přes Ant, tak
jsem jen chtěl vědět, zda náhodou není Eclipse compliter
třeba několikanásobně rychlější/lepší apod. :-)
Díky.
Libor
Dne 25. dubna 2011 11:17 Filip Jirsák fi...@jirsak.org
mailto:fi...@jirsak.org napsal(a):
Kompilátor eclipse například umožňuje přeložit i
Re: javac vs. Eclipse - čísla řádků v .class u víceřádkových výrazů
On 04/26/2011 07:23 AM, Zdeněk Troníček wrote: Jakou máte verzi JDK? Mně to přeložit jde. Z. Tehdy se jednalo o verzi 1.6.0_14, viz otisk mvn -version v diskuzi: http://stackoverflow.com/questions/2220763/java-specific-enums-and-generic-enum-parameters Ale teď jsem si to vyzkoušel v 1.6.0_24 a kupodivu to už funguje. Takže si upravuji názor na Sun Oracle, je vidět že se JDK verze od verze drobně vylepšuje :-) Martin Schayna
Re: javac vs. Eclipse - čísla řádků v .class u víceřádkových výrazů
Ahoj.
2011/4/26 Robert Novotny robert.novo...@upjs.sk
A ako povedal kolega, Eclipse kompilator ma ine spravanie v pripade chyb:
public class Thing {
public void getSecret() {
return x;
}
public static void main(String[] args) {
new Thing().getSecret()
}
}
ECJ to radostne skompiluje a za behu metoda getSecret() hodi
java.lang.Error: Unresolved compilation problem.
Aky to ma realny prinos mimo jsp? Momentalne nedobrovolne prechadzam na
eclipse a tato vlastnost eclipse kompilatoru
mi nesmierne vadi *1 ( ked sa teda oprostim sprostych slov ). Z netbeans som
zvyknuty pri neuspesnom builde hodit zrak do konzoly a hned opravit problem,
v eclipse ziadnu konzolu nevidim, zato mam akusi zalozku problems a v nej
svieti 400 error-ov :-)
Na spolupracu eclipse-maven to takisto neprida, eclipse si tam cosi kdesi
chrousta a ja potom na hudsone mozem
cumiet ako pako, preco to nefunguje :-)
*1 - predpokladam, ze sa to da niekde vypnut, zatial som to neskumal
Javac to odmietne skompilovat.
Inak ECJ sa uz od nepamati pouziva v Tomcate na kompilaciu servletov, ktore
vzniknu z JSP stranok.
RN
On 25. 4. 2011 22:17, Libor Jelinek wrote:
A NetBeans používá taky vlastní kompilátor?
AFAIK pouziva z JDK.
Když dám v Eclipsech Build, tak mi to přeloží jakým kompilátorem? Když
(jako ve zmíněném příkladu z Stackoverflow) Eclipse zkompiluje, ale
Sun/Oracle nikoli, tak jak se to pak chová při běhu oproti Sun/Oracle JRE?
2011/4/25 Ladislav Thon ladi...@gmail.com
Já kupříkladu narazil na rozdíly v kompilaci při volání metody se
signaturou používající Enum?, Eclipsí kompilátor to zvládl na jedničku,
javac měl problémy, viz diskuze na stackoverflow.com:
http://stackoverflow.com/questions/2220763/java-specific-enums-and-generic-enum-parameters
Překladače mohou odvozovat parametrizované typy nad rámec minimálních
požadavků. Suní překladač (hádám, že Oraclí začnu říkat nejdřív za pět
let) se moc nesnaží, překladač z Eclipsu toho zvládne odvodit víc. Neznamená
to, že některý z překladačů je vadný, jenom že o tom lidi moc neví.
LT
Ovšem pokud používáte Maven, musíte se stejně podřídit standardnímu javac
(tedy pokud neexistuje nějaký Maven plugin, který by uměl použít pro
kompilaci Eclipse -- a i kdyby existoval, ani bych ho snad nechtěl použít).
Martin Schayna
On 04/25/2011 02:25 PM, Libor Jelinek wrote:
To jsou tedy vlastnosti s ohledem na IDE. Já stejně většinou používám
javac z Oraclího JDK přes Ant, tak jsem jen chtěl vědět, zda náhodou není
Eclipse compliter třeba několikanásobně rychlější/lepší apod. :-)
Díky.
Libor
Dne 25. dubna 2011 11:17 Filip Jirsák fi...@jirsak.org napsal(a):
Kompilátor eclipse například umožňuje přeložit i třídu s chybou (chyba
v syntaxi v nějaké metodě apod.), jenom místo kódu dané chybné metody
vloží vyhození nějaké runtime výjimky. K tomu asi sunovský kompilátor
nedonutíte. Eclipse (IDE) pak ten přeložený kód používá pro code
completion a spol., kde je užitečné, aby jedna chybná metoda
nezabránila získávat informace o zbytku třídy a ostatních třídách. Na
druhou stranu je potřeba si na to dávat pozor a finální verzi přeložit
s plnou kontrolou chyb, aby se ten kód, kde se místo nějaké metody
bude vyhazovat výjimka „na řádku 353 chybí středník“ nedostal na
produkci.
S pozdravem
Filip Jirsák
Dne 25. dubna 2011 7:43 Libor Jelinek ljeli...@virtage.com napsal(a):
A jaký má Eclipse důvod mít vlastní kompilátor? A jaké má Eclipse
kompilátor
výhody? Oproti standardnímu javac od Oraclu?
Libor
Dne 19. dubna 2011 15:16 Tomáš Záluský zalu...@centrum.cz
napsal(a):
Eclipse kompilator se da pouzit i standalone, je nejaky duvod proc
ho tak
nemuzes pouzit v build procesu?
Zřejmě není, nejspíš na něj přejdeme. Budeme ale muset vyřešit, že je
to
pro Javu 1.5.
Omlouvám se za odmlku, nějak mi toto vlákno vypadlo z pozornosti.
Díky Romane :-)
Tomáš
...with Ultimate flying is so easy...
http://www.frisbee.czhttp://www.peaceegg.net
__
Od: Roman Pichlík roman.pich...@gmail.com
Komu: Java konference@java.cz
Datum: 25.03.2011 11:10
Předmět: Re: javac vs. Eclipse - čísla řádků v .class u
víceřádkových
výrazů
Eclipse kompilator se da pouzit i standalone, je nejaky duvod proc
ho tak
nemuzes pouzit v build procesu?
Dne 24.3.2011 12:11 Tomáš Záluský zalu...@centrum.cz napsal(a):
Dobrý den,
narazil jsem na zajímavý problém s generováním čísel řádků do
class
souboru.
Následující minimalizovaný program vyhodí výjimku, ale stacktracy
se
liší
číslem řádky podle toho, čím byl program zkompilován.
public class SourceLines {
public static class Foo {
public Foo withHoo(String hoo) {
return this;
}
}
public static String n() {
Re: javac vs. Eclipse - čísla řádků v .class u víceřádkových výrazů
Zrejme to ma prinos pri rychlosti buildov a podla mna pred vekmi to bola
zrejme jedine riesenie problemu, ako pouzivat kompilator krizom cez
rozne virtualmachiny a rozumne s nim interagovat. A este mi napadlo, ze
realne je mozne pouzivat i metody triedy, ktora ma syntakticke chyby
(zrejme vhodne vo vyvoji).
Inak ja som si toto spravanie kompilatora paradoxne uvedomil az pri
pisani predoslych mailov a nikdy mi to neprekazalo. Chybny zdrojak
Eclipse sice skompiluje, ale okamzite su cervene podciarknute nespravne
konstrukty a vo view Problems vidim prehladne vsetky chyby. Ak spustate
projekt s chybami, dostanete hlasku, ci ho naozaj chcete spustit a ide sa.
View Problems je vsak standardne nastaveny dost divne, pretoze ukazuje
chyby v celom workspace (to je tych Vasich 400 errorov) a i pre mna je
to chaos. Ja si standardne nastavujem zobrazovat len problemy v aktualne
zvolenom elemente v potomkoch, t. j. ked klikam po packagoch, tak sa mi
zobrazuju kumulativne chyby za cely balicek a ked editujem zdrojak,
vidim len chyby v nom. Da sa to nastavit vo vlastnostiach viewu,
Configure Contents, vytvorit novy Configuration, pomenovat ho, nastavit
Scope na ,,Selected item and its children.
Volitelne si este mozete vypnut grupovanie a potom vidite presne to, co
v NetBeansackej konzole, ale v ovela prehladnejsej forme, pretoze si to
mozete triedit, grupovat, filtrovat podla povodu a podobne.
Mimo Eclipse asi ECJ nema valny zmysel, resp. nevidim ho. (V
buildovacich nastrojoch obvykle ide i tak postupnost clean, build).
RN
On 26. 4. 2011 17:01, Dusan Msk wrote:
Ahoj.
2011/4/26 Robert Novotny robert.novo...@upjs.sk
mailto:robert.novo...@upjs.sk
A ako povedal kolega, Eclipse kompilator ma ine spravanie v
pripade chyb:
public class Thing {
public void getSecret() {
return x;
}
public static void main(String[] args) {
new Thing().getSecret()
}
}
ECJ to radostne skompiluje a za behu metoda getSecret() hodi
java.lang.Error: Unresolved compilation problem.
Aky to ma realny prinos mimo jsp? Momentalne nedobrovolne prechadzam
na eclipse a tato vlastnost eclipse kompilatoru
mi nesmierne vadi *1 ( ked sa teda oprostim sprostych slov ). Z
netbeans som zvyknuty pri neuspesnom builde hodit zrak do konzoly a
hned opravit problem, v eclipse ziadnu konzolu nevidim, zato mam akusi
zalozku problems a v nej svieti 400 error-ov :-)
Na spolupracu eclipse-maven to takisto neprida, eclipse si tam cosi
kdesi chrousta a ja potom na hudsone mozem
cumiet ako pako, preco to nefunguje :-)
*1 - predpokladam, ze sa to da niekde vypnut, zatial som to neskumal
Javac to odmietne skompilovat.
Inak ECJ sa uz od nepamati pouziva v Tomcate na kompilaciu
servletov, ktore vzniknu z JSP stranok.
RN
On 25. 4. 2011 22:17, Libor Jelinek wrote:
A NetBeans používá taky vlastní kompilátor?
AFAIK pouziva z JDK.
Když dám v Eclipsech Build, tak mi to přeloží jakým
kompilátorem? Když (jako ve zmíněném příkladu z Stackoverflow)
Eclipse zkompiluje, ale Sun/Oracle nikoli, tak jak se to pak
chová při běhu oproti Sun/Oracle JRE?
2011/4/25 Ladislav Thon ladi...@gmail.com
mailto:ladi...@gmail.com
Já kupříkladu narazil na rozdíly v kompilaci při volání
metody se signaturou používající Enum?, Eclipsí
kompilátor to zvládl na jedničku, javac měl problémy, viz
diskuze na stackoverflow.com http://stackoverflow.com:
http://stackoverflow.com/questions/2220763/java-specific-enums-and-generic-enum-parameters
Překladače mohou odvozovat parametrizované typy nad rámec
minimálních požadavků. Suní překladač (hádám, že Oraclí
začnu říkat nejdřív za pět let) se moc nesnaží, překladač z
Eclipsu toho zvládne odvodit víc. Neznamená to, že některý z
překladačů je vadný, jenom že o tom lidi moc neví.
LT
Ovšem pokud používáte Maven, musíte se stejně podřídit
standardnímu javac (tedy pokud neexistuje nějaký Maven
plugin, který by uměl použít pro kompilaci Eclipse -- a i
kdyby existoval, ani bych ho snad nechtěl použít).
Martin Schayna
On 04/25/2011 02:25 PM, Libor Jelinek wrote:
To jsou tedy vlastnosti s ohledem na IDE. Já stejně
většinou používám javac z Oraclího JDK přes Ant, tak
jsem jen chtěl vědět, zda náhodou není Eclipse compliter
třeba několikanásobně rychlější/lepší apod. :-)
Díky.
Libor
Dne 25. dubna 2011 11:17 Filip Jirsák fi...@jirsak.org
mailto:fi...@jirsak.org napsal(a):
Kompilátor eclipse například umožňuje přeložit i
třídu s chybou (chyba
v syntaxi v nějaké metodě apod.), jenom místo kódu
dané chybné metody
vloží vyhození nějaké
Re: javac vs. Eclipse - čísla řádků v .class u víceřádkových výrazů
To co ecj povazuje za chybu sa da nastavit. Vid nasledovny obrazok
http://www.informit.com/content/images/chap6_0321288157/elementLinks/06fig10.jpg
.
Normalne ked clovek kodi, tak by kazdy projekt mal byt bez cerveneho znaku
error, takze je lahko viditelne ci nejaky kompilacny problem existuje alebo
nie. Niekedy sa vsak stava, ze projekt je natrvalo oznaceny ako chybny, lebo
chyba je niekde v xmlka alebo j2ee alebo v jsp a neda sa jej rozumne zbavit.
Potom sa mierne straca prehlad volnym okom.
Vseobecne sa tu vsak bavite o dvoch roznych veciach. Ecj je totiz normalny
kompilator, ale eclipse spracovava jeho vystup (vola ho priamo) a zobrazuje
ho strukturovane, vizualne. Druha vec je ze eclipse je schopny kompilovat a
spustat java classy s chybami. Tuto ficuriu som vyuzil velmi velmi
zriedkavo, ked som mal zrovna nieco rozrobene a nieco ine som potreboval
ukazat.
BTW som si spomenul ze ECJ by mal byt schopny vyuzivat viac jadier pri
kompilacii. Dokaze to aj javac?
2011/4/26 Robert Novotny robert.novo...@upjs.sk
Zrejme to ma prinos pri rychlosti buildov a podla mna pred vekmi to bola
zrejme jedine riesenie problemu, ako pouzivat kompilator krizom cez rozne
virtualmachiny a rozumne s nim interagovat. A este mi napadlo, ze realne je
mozne pouzivat i metody triedy, ktora ma syntakticke chyby (zrejme vhodne vo
vyvoji).
Inak ja som si toto spravanie kompilatora paradoxne uvedomil az pri pisani
predoslych mailov a nikdy mi to neprekazalo. Chybny zdrojak Eclipse sice
skompiluje, ale okamzite su cervene podciarknute nespravne konstrukty a vo
view Problems vidim prehladne vsetky chyby. Ak spustate projekt s chybami,
dostanete hlasku, ci ho naozaj chcete spustit a ide sa.
View Problems je vsak standardne nastaveny dost divne, pretoze ukazuje
chyby v celom workspace (to je tych Vasich 400 errorov) a i pre mna je to
chaos. Ja si standardne nastavujem zobrazovat len problemy v aktualne
zvolenom elemente v potomkoch, t. j. ked klikam po packagoch, tak sa mi
zobrazuju kumulativne chyby za cely balicek a ked editujem zdrojak, vidim
len chyby v nom. Da sa to nastavit vo vlastnostiach viewu, Configure
Contents, vytvorit novy Configuration, pomenovat ho, nastavit Scope na
,,Selected item and its children.
Volitelne si este mozete vypnut grupovanie a potom vidite presne to, co v
NetBeansackej konzole, ale v ovela prehladnejsej forme, pretoze si to mozete
triedit, grupovat, filtrovat podla povodu a podobne.
Mimo Eclipse asi ECJ nema valny zmysel, resp. nevidim ho. (V buildovacich
nastrojoch obvykle ide i tak postupnost clean, build).
RN
On 26. 4. 2011 17:01, Dusan Msk wrote:
Ahoj.
2011/4/26 Robert Novotny robert.novo...@upjs.sk
A ako povedal kolega, Eclipse kompilator ma ine spravanie v pripade chyb:
public class Thing {
public void getSecret() {
return x;
}
public static void main(String[] args) {
new Thing().getSecret()
}
}
ECJ to radostne skompiluje a za behu metoda getSecret() hodi
java.lang.Error: Unresolved compilation problem.
Aky to ma realny prinos mimo jsp? Momentalne nedobrovolne prechadzam na
eclipse a tato vlastnost eclipse kompilatoru
mi nesmierne vadi *1 ( ked sa teda oprostim sprostych slov ). Z netbeans
som zvyknuty pri neuspesnom builde hodit zrak do konzoly a hned opravit
problem, v eclipse ziadnu konzolu nevidim, zato mam akusi zalozku problems
a v nej svieti 400 error-ov :-)
Na spolupracu eclipse-maven to takisto neprida, eclipse si tam cosi kdesi
chrousta a ja potom na hudsone mozem
cumiet ako pako, preco to nefunguje :-)
*1 - predpokladam, ze sa to da niekde vypnut, zatial som to neskumal
Javac to odmietne skompilovat.
Inak ECJ sa uz od nepamati pouziva v Tomcate na kompilaciu servletov,
ktore vzniknu z JSP stranok.
RN
On 25. 4. 2011 22:17, Libor Jelinek wrote:
A NetBeans používá taky vlastní kompilátor?
AFAIK pouziva z JDK.
Když dám v Eclipsech Build, tak mi to přeloží jakým kompilátorem? Když
(jako ve zmíněném příkladu z Stackoverflow) Eclipse zkompiluje, ale
Sun/Oracle nikoli, tak jak se to pak chová při běhu oproti Sun/Oracle JRE?
2011/4/25 Ladislav Thon ladi...@gmail.com
Já kupříkladu narazil na rozdíly v kompilaci při volání metody se
signaturou používající Enum?, Eclipsí kompilátor to zvládl na jedničku,
javac měl problémy, viz diskuze na stackoverflow.com:
http://stackoverflow.com/questions/2220763/java-specific-enums-and-generic-enum-parameters
Překladače mohou odvozovat parametrizované typy nad rámec minimálních
požadavků. Suní překladač (hádám, že Oraclí začnu říkat nejdřív za pět
let) se moc nesnaží, překladač z Eclipsu toho zvládne odvodit víc. Neznamená
to, že některý z překladačů je vadný, jenom že o tom lidi moc neví.
LT
Ovšem pokud používáte Maven, musíte se stejně podřídit standardnímu
javac (tedy pokud neexistuje nějaký Maven plugin, který by uměl použít pro
kompilaci Eclipse -- a i kdyby existoval, ani bych ho snad nechtěl použít).
