Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Java Decompiler/Byte Code und default (friendly) visibility
23 views
Skip to first unread message
Marcel Müller
Mar 21, 2013, 3:32:48 AM3/21/13
to
Hallo,
mir ist aufgefallen, dass zwei verschiedene Java Decompiler (JAD & JD)
bei einer Klasse, die aus einem serialisierten Datenstrom entstammt
(ObjectInputStream.getObject()), ausschlie�lich private und protected
Members ausweisen. - Hmm, eine solche Klasse w�re g�nzlich nutzlos. Und
es ist auch interessant, wie man die �berhaupt serialisiert bekommt.
Schlie�lich m�sste man dazu von ihr erben, und damit h�tte man eine
andere Klasse serialisiert.
Weitere Analysen des Codes ergaben, dass die gesch�tzten Methoden von
/anderen/ Klassen im selben Namespace aufgerufen wurden. Also sind sie
offensichtlich /nicht protected/ sondern default visible. Machen da die
Decompiler Mist, oder kann man protected im Byte Code tats�chlich nicht
mehr von default unterscheiden? Gegen letztere Hypothese spricht, dass
ich mit einer eigenen Klasse im gleichen Namespace sehr wohl auf die
Methoden zugreifen durfte. Wenn der Java Compiler nur anhand des Source
Codes w�sste, ob ich das darf, h�tte er hier auf die Bretter gehen
m�ssen, oder?
Wei� jemand etwas erhellendes?
Marcel
mir ist aufgefallen, dass zwei verschiedene Java Decompiler (JAD & JD)
bei einer Klasse, die aus einem serialisierten Datenstrom entstammt
(ObjectInputStream.getObject()), ausschlie�lich private und protected
Members ausweisen. - Hmm, eine solche Klasse w�re g�nzlich nutzlos. Und
es ist auch interessant, wie man die �berhaupt serialisiert bekommt.
Schlie�lich m�sste man dazu von ihr erben, und damit h�tte man eine
andere Klasse serialisiert.
Weitere Analysen des Codes ergaben, dass die gesch�tzten Methoden von
/anderen/ Klassen im selben Namespace aufgerufen wurden. Also sind sie
offensichtlich /nicht protected/ sondern default visible. Machen da die
Decompiler Mist, oder kann man protected im Byte Code tats�chlich nicht
mehr von default unterscheiden? Gegen letztere Hypothese spricht, dass
ich mit einer eigenen Klasse im gleichen Namespace sehr wohl auf die
Methoden zugreifen durfte. Wenn der Java Compiler nur anhand des Source
Codes w�sste, ob ich das darf, h�tte er hier auf die Bretter gehen
m�ssen, oder?
Wei� jemand etwas erhellendes?
Marcel
Jochen Theodorou
Mar 21, 2013, 4:32:51 AM3/21/13
to
Am 21.03.2013 08:32, schrieb Marcel M�ller:
> Hallo,
>
> mir ist aufgefallen, dass zwei verschiedene Java Decompiler (JAD & JD)
> bei einer Klasse, die aus einem serialisierten Datenstrom entstammt
> (ObjectInputStream.getObject()), ausschlie�lich private und protected
> Members ausweisen.
also auch keine entsprechenden Methoden...
> Hallo,
>
> mir ist aufgefallen, dass zwei verschiedene Java Decompiler (JAD & JD)
> bei einer Klasse, die aus einem serialisierten Datenstrom entstammt
> (ObjectInputStream.getObject()), ausschlie�lich private und protected
> Members ausweisen.
> - Hmm, eine solche Klasse w�re g�nzlich nutzlos.
gleichem package. "default" schr�nkt protected dahingehend ein, dass
auch Subklassen keinen Zugriff haben und dass der ClassLoader gleich
sein muss.
[...]
> Machen da die
> Decompiler Mist, oder kann man protected im Byte Code tats�chlich nicht
> mehr von default unterscheiden?
Decompiler haben, wenn �berhaupt Probleme mit dem Inhalt der Methoden,
> Decompiler Mist, oder kann man protected im Byte Code tats�chlich nicht
> mehr von default unterscheiden?
mit der Signatur normalerweise nicht. Du kannst auch Reflection benutzen
um die modifier zu �berpr�fen.
Gruss theo
--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org
Marcel Müller
Mar 21, 2013, 6:02:51 AM3/21/13
to
Hallo,
On 21.03.2013 09:32, Jochen Theodorou wrote:
> Nein. Protected erlaubt Zugriff von Subklassen, aber auch von Klassen im
> gleichem package.
oh, das ist bei Java anders (als bei C++ und .NET). Das wusste ich
nicht. Witziger Weise kursiert meine falsche Ansicht wohl auch noch
anderswo im Netz. (z.B.
http://www.developertutorials.com/tutorials/java/java-accessor-visibility-050525-1442/)
Das bedeutet, dass protected eigentlich gar nichts verhindert, denn ich
kann ja offensichtlich immer eine Klasse in einen fremden Namespace
"implantieren". Ganz sicher kein Best Practice, aber die Realit�t h�lt
sich ja �fter nicht an Konventionen.
>> Machen da die
>> Decompiler Mist, oder kann man protected im Byte Code tats�chlich nicht
>> mehr von default unterscheiden?
>
> Decompiler haben, wenn �berhaupt Probleme mit dem Inhalt der Methoden,
> mit der Signatur normalerweise nicht. Du kannst auch Reflection benutzen
> um die modifier zu �berpr�fen.
Das war auch mein Bild.
Wobei da mittlerweile auch beim Code erstaunlich viel geht. Da auch
kommerzieller Code selten so gut dokumentiert ist, wie es sein sollte
(von �ffentlichen APIs mal abgesehen), ist der Unterschied, ob man den
Quellcode nun hat oder nicht, zuweilen kaum noch sp�rbar.
Marcel
On 21.03.2013 09:32, Jochen Theodorou wrote:
> Nein. Protected erlaubt Zugriff von Subklassen, aber auch von Klassen im
> gleichem package.
nicht. Witziger Weise kursiert meine falsche Ansicht wohl auch noch
anderswo im Netz. (z.B.
http://www.developertutorials.com/tutorials/java/java-accessor-visibility-050525-1442/)
Das bedeutet, dass protected eigentlich gar nichts verhindert, denn ich
kann ja offensichtlich immer eine Klasse in einen fremden Namespace
"implantieren". Ganz sicher kein Best Practice, aber die Realit�t h�lt
sich ja �fter nicht an Konventionen.
>> Machen da die
>> Decompiler Mist, oder kann man protected im Byte Code tats�chlich nicht
>> mehr von default unterscheiden?
>
> Decompiler haben, wenn �berhaupt Probleme mit dem Inhalt der Methoden,
> mit der Signatur normalerweise nicht. Du kannst auch Reflection benutzen
> um die modifier zu �berpr�fen.
Wobei da mittlerweile auch beim Code erstaunlich viel geht. Da auch
kommerzieller Code selten so gut dokumentiert ist, wie es sein sollte
(von �ffentlichen APIs mal abgesehen), ist der Unterschied, ob man den
Quellcode nun hat oder nicht, zuweilen kaum noch sp�rbar.
Marcel
Jochen Theodorou
Mar 21, 2013, 9:41:02 AM3/21/13
to
Am 21.03.2013 11:02, schrieb Marcel M锟絣ler:
[...]
> sich ja 锟絝ter nicht an Konventionen.
protected ist halt eine Einschr锟絥kung gegen锟絙er public, gew锟絟rt aber
mehr Rechte als default. was wiederrum mehr als private erlaubt. Es
verhindert also schon was, aber halt nicht ganz so viel wie anderes.
[...]
Bytecode geht durchaus einiges, was in Java selbst nicht geht.
> Da auch
> kommerzieller Code selten so gut dokumentiert ist, wie es sein sollte
> (von 锟絝fentlichen APIs mal abgesehen), ist der Unterschied, ob man den
> Quellcode nun hat oder nicht, zuweilen kaum noch sp锟絩bar.
nunjaaaa.... wenn die Methoden hinreichend einfach sind, dann ok. Aber
oft ist das nicht der Fall
[...]
> Das bedeutet, dass protected eigentlich gar nichts verhindert, denn ich
> kann ja offensichtlich immer eine Klasse in einen fremden Namespace
> "implantieren". Ganz sicher kein Best Practice, aber die Realit锟絫 h锟絣t
> kann ja offensichtlich immer eine Klasse in einen fremden Namespace
> sich ja 锟絝ter nicht an Konventionen.
protected ist halt eine Einschr锟絥kung gegen锟絙er public, gew锟絟rt aber
mehr Rechte als default. was wiederrum mehr als private erlaubt. Es
verhindert also schon was, aber halt nicht ganz so viel wie anderes.
[...]
> Wobei da mittlerweile auch beim Code erstaunlich viel geht.
Ja, kommt darauf an ob das aus einem Javacompiler kommt oder nicht. In
Bytecode geht durchaus einiges, was in Java selbst nicht geht.
> Da auch
> kommerzieller Code selten so gut dokumentiert ist, wie es sein sollte
> Quellcode nun hat oder nicht, zuweilen kaum noch sp锟絩bar.
nunjaaaa.... wenn die Methoden hinreichend einfach sind, dann ok. Aber
oft ist das nicht der Fall
Marcel Müller
Mar 21, 2013, 10:02:05 AM3/21/13
to
Hallo!
On 21.03.2013 14:41, Jochen Theodorou wrote:
>> Wobei da mittlerweile auch beim Code erstaunlich viel geht.
>
> Ja, kommt darauf an ob das aus einem Javacompiler kommt oder nicht. In
> Bytecode geht durchaus einiges, was in Java selbst nicht geht.
Meinst Du nicht /so/ geht, oder Dinge, die sich in Java-Syntax, auch
umst�ndlich, gar nicht darstellen lassen. (Ich kenne mich mit dem
Bytecode ehrlich gesagt nicht aus.)
>> Da auch
>> kommerzieller Code selten so gut dokumentiert ist, wie es sein sollte
>> (von �ffentlichen APIs mal abgesehen), ist der Unterschied, ob man den
>> Quellcode nun hat oder nicht, zuweilen kaum noch sp�rbar.
recht lange mit Java 1.4 unterwegs. Insofern waren da historisch schon
ein paar Grenzen gesetzt.
Marcel
On 21.03.2013 14:41, Jochen Theodorou wrote:
>> Wobei da mittlerweile auch beim Code erstaunlich viel geht.
>
> Ja, kommt darauf an ob das aus einem Javacompiler kommt oder nicht. In
> Bytecode geht durchaus einiges, was in Java selbst nicht geht.
umst�ndlich, gar nicht darstellen lassen. (Ich kenne mich mit dem
Bytecode ehrlich gesagt nicht aus.)
>> Da auch
>> kommerzieller Code selten so gut dokumentiert ist, wie es sein sollte
>> Quellcode nun hat oder nicht, zuweilen kaum noch sp�rbar.
>
> nunjaaaa.... wenn die Methoden hinreichend einfach sind, dann ok. Aber
> oft ist das nicht der Fall
Bei SAP hat es bisher ganz gut geklappt. Allerdings waren die auch noch
> nunjaaaa.... wenn die Methoden hinreichend einfach sind, dann ok. Aber
> oft ist das nicht der Fall
recht lange mit Java 1.4 unterwegs. Insofern waren da historisch schon
ein paar Grenzen gesetzt.
Marcel
Jochen Theodorou
Mar 21, 2013, 10:44:48 AM3/21/13
to
Am 21.03.2013 15:02, schrieb Marcel M�ller:
> Hallo!
>
> On 21.03.2013 14:41, Jochen Theodorou wrote:
>>> Wobei da mittlerweile auch beim Code erstaunlich viel geht.
>>
>> Ja, kommt darauf an ob das aus einem Javacompiler kommt oder nicht. In
>> Bytecode geht durchaus einiges, was in Java selbst nicht geht.
>
> Meinst Du nicht /so/ geht, oder Dinge, die sich in Java-Syntax, auch
> umst�ndlich, gar nicht darstellen lassen. (Ich kenne mich mit dem
> Bytecode ehrlich gesagt nicht aus.)
Ich meine garnicht geht. Zum Beispiel eine Methode machen, die eine
> Hallo!
>
> On 21.03.2013 14:41, Jochen Theodorou wrote:
>>> Wobei da mittlerweile auch beim Code erstaunlich viel geht.
>>
>> Ja, kommt darauf an ob das aus einem Javacompiler kommt oder nicht. In
>> Bytecode geht durchaus einiges, was in Java selbst nicht geht.
>
> Meinst Du nicht /so/ geht, oder Dinge, die sich in Java-Syntax, auch
> umst�ndlich, gar nicht darstellen lassen. (Ich kenne mich mit dem
> Bytecode ehrlich gesagt nicht aus.)
checked Exception wirft, dies in der Signatur aber nicht ausweist. Oder
anders herum, eine checked Exception abfangen, obwohl im try block
nichts behauptet das zu werfen. Und nicht zu vergessen, dass bytecode
GOTO hat, Java aber nicht.
>>> Da auch
>>> kommerzieller Code selten so gut dokumentiert ist, wie es sein sollte
>>> (von �ffentlichen APIs mal abgesehen), ist der Unterschied, ob man den
>>> Quellcode nun hat oder nicht, zuweilen kaum noch sp�rbar.
>>
>> nunjaaaa.... wenn die Methoden hinreichend einfach sind, dann ok. Aber
>> oft ist das nicht der Fall
>
> Bei SAP hat es bisher ganz gut geklappt. Allerdings waren die auch noch
> recht lange mit Java 1.4 unterwegs. Insofern waren da historisch schon
> ein paar Grenzen gesetzt.
nur in den Signaturen auf das Zeug.
Marcel Müller
Mar 21, 2013, 12:54:45 PM3/21/13
to
Hallo,
On 21.03.2013 15:44, Jochen Theodorou wrote:
>> Meinst Du nicht /so/ geht, oder Dinge, die sich in Java-Syntax, auch
>> umst�ndlich, gar nicht darstellen lassen. (Ich kenne mich mit dem
>> Bytecode ehrlich gesagt nicht aus.)
>
> Ich meine garnicht geht. Zum Beispiel eine Methode machen, die eine
> checked Exception wirft, dies in der Signatur aber nicht ausweist.
ja, stimmt. Exceptions werden nur vom Compiler gecheckt. Der VM ist das
total egal.
> Oder
> anders herum, eine checked Exception abfangen, obwohl im try block
> nichts behauptet das zu werfen. Und nicht zu vergessen, dass bytecode
> GOTO hat, Java aber nicht.
Ja, auch richtig - eigentlich jede Sprache kennt intern goto. Man k�nnte
im Ergebnis also keinen g�ltigen Java-Code Erzeugen, wenn es nicht
gelingt daraus Schleifenkonstrukte zu bauen. Verschr�nkte Schleifen
d�rften so ein Beispiel sein.
Marcel
On 21.03.2013 15:44, Jochen Theodorou wrote:
>> Meinst Du nicht /so/ geht, oder Dinge, die sich in Java-Syntax, auch
>> umst�ndlich, gar nicht darstellen lassen. (Ich kenne mich mit dem
>> Bytecode ehrlich gesagt nicht aus.)
>
> Ich meine garnicht geht. Zum Beispiel eine Methode machen, die eine
> checked Exception wirft, dies in der Signatur aber nicht ausweist.
total egal.
> Oder
> anders herum, eine checked Exception abfangen, obwohl im try block
> nichts behauptet das zu werfen. Und nicht zu vergessen, dass bytecode
> GOTO hat, Java aber nicht.
im Ergebnis also keinen g�ltigen Java-Code Erzeugen, wenn es nicht
gelingt daraus Schleifenkonstrukte zu bauen. Verschr�nkte Schleifen
d�rften so ein Beispiel sein.
Marcel
Volker Borchert
Mar 21, 2013, 5:39:15 PM3/21/13
to
Jochen Theodorou wrote:
> >
> > On 21.03.2013 14:41, Jochen Theodorou wrote:
> >> Ja, kommt darauf an ob das aus einem Javacompiler kommt oder nicht. In
> >> Bytecode geht durchaus einiges, was in Java selbst nicht geht.
> >
> >
> > On 21.03.2013 14:41, Jochen Theodorou wrote:
> >> Ja, kommt darauf an ob das aus einem Javacompiler kommt oder nicht. In
> >> Bytecode geht durchaus einiges, was in Java selbst nicht geht.
> >
> Ich meine garnicht geht. Zum Beispiel eine Methode machen, die eine
> checked Exception wirft, dies in der Signatur aber nicht ausweist.
Das geht auch so, ist ein ziemlich gruseliger Trick mit Generics, der
> checked Exception wirft, dies in der Signatur aber nicht ausweist.
darauf beruht, da� die Typpr�fung des generischeb R�ckgabewerts einer
Methode beim Aufrufer im Anschlu� an den Aufruf erfolgt und deshalb
nicht erreicht wird, wenn die Methode "terminates abruptly" also die
verkleidete Exception wirft.
--
"I'm a doctor, not a mechanic." Dr Leonard McCoy <mc...@ncc1701.starfleet.fed>
"I'm a mechanic, not a doctor." Volker Borchert <v_bor...@despammed.com>
Jochen Theodorou
Mar 22, 2013, 2:41:58 AM3/22/13
to
Am 21.03.2013 22:39, schrieb Volker Borchert:
> Jochen Theodorou wrote:
>>>
>>> On 21.03.2013 14:41, Jochen Theodorou wrote:
>>>> Ja, kommt darauf an ob das aus einem Javacompiler kommt oder nicht. In
>>>> Bytecode geht durchaus einiges, was in Java selbst nicht geht.
>>>
>> Ich meine garnicht geht. Zum Beispiel eine Methode machen, die eine
>> checked Exception wirft, dies in der Signatur aber nicht ausweist.
>
> Das geht auch so, ist ein ziemlich gruseliger Trick mit Generics, der
> darauf beruht, da� die Typpr�fung des generischeb R�ckgabewerts einer
> Methode beim Aufrufer im Anschlu� an den Aufruf erfolgt und deshalb
> nicht erreicht wird, wenn die Methode "terminates abruptly" also die
> verkleidete Exception wirft.
probier es mal aus, geht imho nicht in 1.7/1.8
> Jochen Theodorou wrote:
>>>
>>> On 21.03.2013 14:41, Jochen Theodorou wrote:
>>>> Ja, kommt darauf an ob das aus einem Javacompiler kommt oder nicht. In
>>>> Bytecode geht durchaus einiges, was in Java selbst nicht geht.
>>>
>> Ich meine garnicht geht. Zum Beispiel eine Methode machen, die eine
>> checked Exception wirft, dies in der Signatur aber nicht ausweist.
>
> Das geht auch so, ist ein ziemlich gruseliger Trick mit Generics, der
> darauf beruht, da� die Typpr�fung des generischeb R�ckgabewerts einer
> Methode beim Aufrufer im Anschlu� an den Aufruf erfolgt und deshalb
> nicht erreicht wird, wenn die Methode "terminates abruptly" also die
> verkleidete Exception wirft.
Patrick Roemer
Mar 22, 2013, 8:55:24 AM3/22/13
to
Responding to Jochen Theodorou:
Geht in 1.7/1.8 (und Wanja geht ja auch recht ausfuehrlich darauf ein,
warum das nicht so ueberraschend ist).
Nicht, dass der Ansatz empfehlenswert waere...
Viele Gruesse,
Patrick
> Am 21.03.2013 22:39, schrieb Volker Borchert:
>> Jochen Theodorou wrote:
>>> Ich meine garnicht geht. Zum Beispiel eine Methode machen, die eine
>>> checked Exception wirft, dies in der Signatur aber nicht ausweist.
>>
>> Das geht auch so, ist ein ziemlich gruseliger Trick mit Generics, der
>> darauf beruht, da� die Typpr�fung des generischeb R�ckgabewerts einer
>> Methode beim Aufrufer im Anschlu� an den Aufruf erfolgt und deshalb
>> nicht erreicht wird, wenn die Methode "terminates abruptly" also die
>> verkleidete Exception wirft.
>
> probier es mal aus, geht imho nicht in 1.7/1.8
http://brixomatic.wordpress.com/2010/04/29/hack-of-the-day-unchecking-checked-exceptions/
>> Jochen Theodorou wrote:
>>> Ich meine garnicht geht. Zum Beispiel eine Methode machen, die eine
>>> checked Exception wirft, dies in der Signatur aber nicht ausweist.
>>
>> Das geht auch so, ist ein ziemlich gruseliger Trick mit Generics, der
>> darauf beruht, da� die Typpr�fung des generischeb R�ckgabewerts einer
>> Methode beim Aufrufer im Anschlu� an den Aufruf erfolgt und deshalb
>> nicht erreicht wird, wenn die Methode "terminates abruptly" also die
>> verkleidete Exception wirft.
>
> probier es mal aus, geht imho nicht in 1.7/1.8
Geht in 1.7/1.8 (und Wanja geht ja auch recht ausfuehrlich darauf ein,
warum das nicht so ueberraschend ist).
Nicht, dass der Ansatz empfehlenswert waere...
Viele Gruesse,
Patrick
Patrick Roemer
Mar 22, 2013, 9:42:37 AM3/22/13
to
Responding to Jochen Theodorou:
> Nein. Protected erlaubt Zugriff von Subklassen, aber auch von Klassen im
> gleichem package. "default" schr�nkt protected dahingehend ein, dass
> auch Subklassen keinen Zugriff haben und dass der ClassLoader gleich
> sein muss.
Das ist etwas irrefuehrend - die Einschraenkung auf denselben
Classloader ist nicht spezifisch fuer default access. Die run-time
package ist durch den Namen der Package und den Classloader gegeben.
Protected access erlaubt Zugriff aus Subklassen (unabhaengig von der
run-time package) oder aus Klassen in derselben run-time package,
default access nur aus Klassen in derselben run-time package.
Viele Gruesse,
Patrick
> Nein. Protected erlaubt Zugriff von Subklassen, aber auch von Klassen im
> gleichem package. "default" schr�nkt protected dahingehend ein, dass
> auch Subklassen keinen Zugriff haben und dass der ClassLoader gleich
> sein muss.
Classloader ist nicht spezifisch fuer default access. Die run-time
package ist durch den Namen der Package und den Classloader gegeben.
Protected access erlaubt Zugriff aus Subklassen (unabhaengig von der
run-time package) oder aus Klassen in derselben run-time package,
default access nur aus Klassen in derselben run-time package.
Viele Gruesse,
Patrick
Volker Borchert
Mar 22, 2013, 11:02:55 PM3/22/13
to
Patrick Roemer wrote:
> http://brixomatic.wordpress.com/2010/04/29/hack-of-the-day-unchecking-checked-exceptions/
>
> Geht in 1.7/1.8 (und Wanja geht ja auch recht ausfuehrlich darauf ein,
> warum das nicht so ueberraschend ist).
>
> Nicht, dass der Ansatz empfehlenswert waere...
Manchmal sind die Alternativen auch nicht besser. Etwa, wenn man
> http://brixomatic.wordpress.com/2010/04/29/hack-of-the-day-unchecking-checked-exceptions/
>
> Geht in 1.7/1.8 (und Wanja geht ja auch recht ausfuehrlich darauf ein,
> warum das nicht so ueberraschend ist).
>
> Nicht, dass der Ansatz empfehlenswert waere...
Arrays.sort(T[]) oder Collections.sort(List<T>) verwenden will
und eine in compare(T, T) verwendete Methode eine checked exception
deklariert...
Patrick Roemer
Mar 23, 2013, 11:17:39 AM3/23/13
to
Responding to Volker Borchert:
Ordnung - fuer zwei Objekte *muss* immer gelten a <= b oder b <= a,
"bottom" als dritte Moeglichkeit ist ausgeschlossen. Dass da keine
checked Exception zugelassen wird, ist keine Unterlassung, sondern
sozusagen Bestandteil des Contracts (der in der Dokumentation ja auch
gewisse unchecked Exceptions explizit ausschliesst). Wenn man in seiner
#compare() potentiell auf eine checked Exception stoesst (die ja
gemeinhin a) zu einem gewissen Grad erwartbar und b) "recoverable" sein
sollte), und diese nicht innerhalb des #compare() zu einem der beiden
legalen Faelle aufloesen kann, riecht das schon nach einem "Missbrauch"
der Comparator-API.
Wenn man diesen im speziellen Fall rechtfertigen kann und die checked
Exception von der den #sort()-Aufruf umgebenden Methode deklariert wird,
waere dieser Ansatz vielleicht etwas eleganter als die Alternativen -
das waere dann aber gegen den erhoehten WTF-Faktor bei demjenigen, der
den Code Monate spaeter warten muss, abzuwaegen. Auf jeden Fall waere
das ein very exceptional case. ;)
Viele Gruesse,
Patrick
> Patrick Roemer wrote:
>
>> http://brixomatic.wordpress.com/2010/04/29/hack-of-the-day-unchecking-checked-exceptions/
>>
>> Geht in 1.7/1.8 (und Wanja geht ja auch recht ausfuehrlich darauf ein,
>> warum das nicht so ueberraschend ist).
>>
>> Nicht, dass der Ansatz empfehlenswert waere...
>
> Manchmal sind die Alternativen auch nicht besser. Etwa, wenn man
> Arrays.sort(T[]) oder Collections.sort(List<T>) verwenden will
> und eine in compare(T, T) verwendete Methode eine checked exception
> deklariert...
Hmnja... Ein Comparator/Comparable impliziert schliesslich eine totale
>
>> http://brixomatic.wordpress.com/2010/04/29/hack-of-the-day-unchecking-checked-exceptions/
>>
>> Geht in 1.7/1.8 (und Wanja geht ja auch recht ausfuehrlich darauf ein,
>> warum das nicht so ueberraschend ist).
>>
>> Nicht, dass der Ansatz empfehlenswert waere...
>
> Manchmal sind die Alternativen auch nicht besser. Etwa, wenn man
> Arrays.sort(T[]) oder Collections.sort(List<T>) verwenden will
> und eine in compare(T, T) verwendete Methode eine checked exception
> deklariert...
Ordnung - fuer zwei Objekte *muss* immer gelten a <= b oder b <= a,
"bottom" als dritte Moeglichkeit ist ausgeschlossen. Dass da keine
checked Exception zugelassen wird, ist keine Unterlassung, sondern
sozusagen Bestandteil des Contracts (der in der Dokumentation ja auch
gewisse unchecked Exceptions explizit ausschliesst). Wenn man in seiner
#compare() potentiell auf eine checked Exception stoesst (die ja
gemeinhin a) zu einem gewissen Grad erwartbar und b) "recoverable" sein
sollte), und diese nicht innerhalb des #compare() zu einem der beiden
legalen Faelle aufloesen kann, riecht das schon nach einem "Missbrauch"
der Comparator-API.
Wenn man diesen im speziellen Fall rechtfertigen kann und die checked
Exception von der den #sort()-Aufruf umgebenden Methode deklariert wird,
waere dieser Ansatz vielleicht etwas eleganter als die Alternativen -
das waere dann aber gegen den erhoehten WTF-Faktor bei demjenigen, der
den Code Monate spaeter warten muss, abzuwaegen. Auf jeden Fall waere
das ein very exceptional case. ;)
Viele Gruesse,
Patrick
Jochen Theodorou
Mar 24, 2013, 9:25:34 AM3/24/13
to
Am 22.03.2013 13:55, schrieb Patrick Roemer:
[...]
> http://brixomatic.wordpress.com/2010/04/29/hack-of-the-day-unchecking-checked-exceptions/
komisch, ich dachte ich h�tte das ausprobiert und der Compiler h�tte
gemeckert... sehr seltsam.
> Nicht, dass der Ansatz empfehlenswert waere...
Nunja... JDK1.7 hat jetzt Methodandle und ein sch�nes
invokeWithArguments (plus andere), aber das hat ein throws Throwable.
Sehr unsch�n aus Javasicht.
[...]
> http://brixomatic.wordpress.com/2010/04/29/hack-of-the-day-unchecking-checked-exceptions/
komisch, ich dachte ich h�tte das ausprobiert und der Compiler h�tte
gemeckert... sehr seltsam.
> Nicht, dass der Ansatz empfehlenswert waere...
invokeWithArguments (plus andere), aber das hat ein throws Throwable.
Sehr unsch�n aus Javasicht.
Jochen Theodorou
Mar 24, 2013, 9:30:00 AM3/24/13
to
eingeschr�nkt ist. Ist f�r mich nie ganz logisch gewesen, weil die
Subklasse ja in einem anderen runtime package sein darf. Und in der
Praxis f�llt der Unterschied selten auf... ua�er man programmiert gegen
APIs wo sich jemand das sehr ausgetobt hat.
Volker Borchert
Mar 24, 2013, 1:57:48 PM3/24/13
to
Patrick Roemer wrote:
> Responding to Volker Borchert:
> > Patrick Roemer wrote:
> >
> >> http://brixomatic.wordpress.com/2010/04/29/hack-of-the-day-unchecking-checked-exceptions/
> >>
> >> Geht in 1.7/1.8 (und Wanja geht ja auch recht ausfuehrlich darauf ein,
> >> warum das nicht so ueberraschend ist).
> >>
> >> Nicht, dass der Ansatz empfehlenswert waere...
> >
> > Manchmal sind die Alternativen auch nicht besser. Etwa, wenn man
> > Arrays.sort(T[]) oder Collections.sort(List<T>) verwenden will
> > und eine in compare(T, T) verwendete Methode eine checked exception
> > deklariert...
>
> [ ... Comparator Philosophie ... ]
> Responding to Volker Borchert:
> > Patrick Roemer wrote:
> >
> >> http://brixomatic.wordpress.com/2010/04/29/hack-of-the-day-unchecking-checked-exceptions/
> >>
> >> Geht in 1.7/1.8 (und Wanja geht ja auch recht ausfuehrlich darauf ein,
> >> warum das nicht so ueberraschend ist).
> >>
> >> Nicht, dass der Ansatz empfehlenswert waere...
> >
> > Manchmal sind die Alternativen auch nicht besser. Etwa, wenn man
> > Arrays.sort(T[]) oder Collections.sort(List<T>) verwenden will
> > und eine in compare(T, T) verwendete Methode eine checked exception
> > deklariert...
>
>
> Wenn man diesen im speziellen Fall rechtfertigen kann und die checked
> Exception von der den #sort()-Aufruf umgebenden Methode deklariert wird,
Wird sie.
> Wenn man diesen im speziellen Fall rechtfertigen kann und die checked
> Exception von der den #sort()-Aufruf umgebenden Methode deklariert wird,
> waere dieser Ansatz vielleicht etwas eleganter als die Alternativen -
> das waere dann aber gegen den erhoehten WTF-Faktor bei demjenigen, der
> den Code Monate spaeter warten muss,
einer ausf�hrlichen Erl�uterung der Funktionsweise einschlie�lich
bytecode Listing auch S1/2, S53, S61; ich werde allerdings deinen
Hinweis vielleicht in der Form aufgreifen, da� ich noch S57 hinzuf�ge.
Volker Borchert
Mar 24, 2013, 2:00:04 PM3/24/13
to
Jochen Theodorou wrote:
> Am 22.03.2013 13:55, schrieb Patrick Roemer:
> [...]
> > http://brixomatic.wordpress.com/2010/04/29/hack-of-the-day-unchecking-checked-exceptions/
>
> Am 22.03.2013 13:55, schrieb Patrick Roemer:
> [...]
> > http://brixomatic.wordpress.com/2010/04/29/hack-of-the-day-unchecking-checked-exceptions/
>
> Nunja... JDK1.7 hat jetzt Methodandle und ein sch�nes
> invokeWithArguments (plus andere), aber das hat ein throws Throwable.
Autsch!
> invokeWithArguments (plus andere), aber das hat ein throws Throwable.
Patrick Roemer
Mar 25, 2013, 2:17:25 PM3/25/13
to
Responding to Volker Borchert:
> Patrick Roemer wrote:
>> Responding to Volker Borchert:
>>> Patrick Roemer wrote:
>>>
>>>> http://brixomatic.wordpress.com/2010/04/29/hack-of-the-day-unchecking-checked-exceptions/
[...]
> Patrick Roemer wrote:
>> Responding to Volker Borchert:
>>> Patrick Roemer wrote:
>>>
>>>> http://brixomatic.wordpress.com/2010/04/29/hack-of-the-day-unchecking-checked-exceptions/
>>> Manchmal sind die Alternativen auch nicht besser. Etwa, wenn man
>>> Arrays.sort(T[]) oder Collections.sort(List<T>) verwenden will
>>> und eine in compare(T, T) verwendete Methode eine checked exception
>>> deklariert...
>>
>> [ ... Comparator Philosophie ... ]
>>
>> Wenn man diesen im speziellen Fall rechtfertigen kann und die checked
>> Exception von der den #sort()-Aufruf umgebenden Methode deklariert wird,
>
> Wird sie.
Und man kann auch? :)
>>> Arrays.sort(T[]) oder Collections.sort(List<T>) verwenden will
>>> und eine in compare(T, T) verwendete Methode eine checked exception
>>> deklariert...
>>
>> [ ... Comparator Philosophie ... ]
>>
>> Wenn man diesen im speziellen Fall rechtfertigen kann und die checked
>> Exception von der den #sort()-Aufruf umgebenden Methode deklariert wird,
>
> Wird sie.
> Die javadoc der hierzu erforderlichen statischen Methode enth�lt neben
> einer ausf�hrlichen Erl�uterung der Funktionsweise einschlie�lich
> bytecode Listing auch S1/2, S53, S61; ich werde allerdings deinen
> Hinweis vielleicht in der Form aufgreifen, da� ich noch S57 hinzuf�ge.
was sich diese Kuerzel beziehen...?
Wenn die Sortierung auf dem critical path ist und so schnell wie
moeglich sein muss, wuerde ich mich vielleicht zaehneknirschend auf
diesen Ansatz einlassen. Wenn es hingegen so aussieht, als koenne man
mit einem gewissen Overhead leben[1], wuerde ich die abweichende
Semantik lieber explizit in eine entsprechende Utility-API giessen.
interface FallibleComparator<T, E extends Throwable> {
int compare(T a, T b) throws E;
}
public class FallibleSort {
public static <T, E extends Throwable> void sort(
List<T> data, final FallibleComparator<T, E> cmp) throws E {
// ...
}
}
Den internen Comparator fuer dieses #sort() koennte man dann getrost
auch "klassisch" (also z.B. mit Wrapping/Unwrapping einer RTE) ohne
diesen Zaubertrick implementieren - fuer den Verwender ist es eh eine
Black Box, und fuer die Performance ist die Wahl nicht sonderlich relevant.
Viele Gruesse,
Patrick
[1] Laut Caliper bei kleinen Listen 2-4%, bei grossen Listen < 2% bis
komplett vernachlaessigbar. Wie immer bei Microbenchmarks mit Vorsicht
zu geniessen.
Volker Borchert
Mar 25, 2013, 4:54:21 PM3/25/13
to
Patrick Roemer wrote:
> Responding to Volker Borchert:
> Responding to Volker Borchert:
> > Die javadoc der hierzu erforderlichen statischen Methode enth�lt neben
> > einer ausf�hrlichen Erl�uterung der Funktionsweise einschlie�lich
> > bytecode Listing auch S1/2, S53, S61; ich werde allerdings deinen
> > Hinweis vielleicht in der Form aufgreifen, da� ich noch S57 hinzuf�ge.
>
> Wird das dann auch in den 27B-6 eingetragen? ;) IOW: Keine Ahnung, auf
> was sich diese Kuerzel beziehen...?
Aus der deutschen wikipedia:
> > einer ausf�hrlichen Erl�uterung der Funktionsweise einschlie�lich
> > bytecode Listing auch S1/2, S53, S61; ich werde allerdings deinen
> > Hinweis vielleicht in der Form aufgreifen, da� ich noch S57 hinzuf�ge.
>
> Wird das dann auch in den 27B-6 eingetragen? ;) IOW: Keine Ahnung, auf
> was sich diese Kuerzel beziehen...?
R- und S-S�tze ("Risiko- und Sicherheitss�tze", von englisch risk and safety)
sind kodifizierte Warnhinweise zur Charakterisierung der Gefahrenmerkmale von
Gefahrstoffen, also Elementen und Verbindungen sowie daraus hergestellten
gef�hrlichen Zubereitungen. Sie sind zusammen mit den Gefahrenbezeichnungen und
den jeweils dazu geh�renden Gefahrensymbolen die wichtigsten Hilfsmittel f�r
die innerhalb der EU vorgeschriebene Gefahrstoffkennzeichnung.
und
* S 1/2 Unter Verschluss und f�r Kinder unzug�nglich aufbewahren.
* S 53 Exposition vermeiden - vor Gebrauch besondere Anweisungen einholen. -
Nur f�r den berufsm��igen Verwender -.
* S 57 Zur Vermeidung einer Kontamination der Umwelt geeigneten Beh�lter
verwenden.
* S 61 Freisetzung in die Umwelt vermeiden. Besondere Anweisungen
einholen/Sicherheitsdatenblatt zu Rate ziehen.
Patrick Roemer
Mar 25, 2013, 6:25:53 PM3/25/13
to
Responding to Volker Borchert:
als Dokumentation sondern for real.
Viele Gruesse,
Patrick
> Patrick Roemer wrote:
>> Responding to Volker Borchert:
>> > Die javadoc der hierzu erforderlichen statischen Methode enth�lt neben
>> > einer ausf�hrlichen Erl�uterung der Funktionsweise einschlie�lich
>> > bytecode Listing auch S1/2, S53, S61; ich werde allerdings deinen
>> > Hinweis vielleicht in der Form aufgreifen, da� ich noch S57 hinzuf�ge.
>>
>> Wird das dann auch in den 27B-6 eingetragen? ;) IOW: Keine Ahnung, auf
>> was sich diese Kuerzel beziehen...?
[...]
>> Responding to Volker Borchert:
>> > Die javadoc der hierzu erforderlichen statischen Methode enth�lt neben
>> > einer ausf�hrlichen Erl�uterung der Funktionsweise einschlie�lich
>> > bytecode Listing auch S1/2, S53, S61; ich werde allerdings deinen
>> > Hinweis vielleicht in der Form aufgreifen, da� ich noch S57 hinzuf�ge.
>>
>> Wird das dann auch in den 27B-6 eingetragen? ;) IOW: Keine Ahnung, auf
>> was sich diese Kuerzel beziehen...?
> * S 57 Zur Vermeidung einer Kontamination der Umwelt geeigneten Beh�lter
> verwenden.
Ok, danke. :) S57 waere dann in der Tat genau mein Vorschlag - nur nicht
> verwenden.
als Dokumentation sondern for real.
Viele Gruesse,
Patrick
Wanja Gayk
Mar 27, 2013, 7:51:14 AM3/27/13
to
In article <kifum3$s1d$2...@Gaia.teknon.de>, Volker Borchert
(v_bor...@despammed.com) says...
> Methode beim Aufrufer im Anschluß an den Aufruf erfolgt und deshalb
> http://brixomatic.wordpress.com/2010/04/29/hack-of-the-day-unchecking-
checked-exceptions/ <
Gruß,
-Wanja-
--
..Alesi's problem was that the back of the car was jumping up and down
dangerously - and I can assure you from having been teammate to
Jean Alesi and knowing what kind of cars that he can pull up with,
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
(v_bor...@despammed.com) says...
>
> Jochen Theodorou wrote:
> > >
> > > On 21.03.2013 14:41, Jochen Theodorou wrote:
> > >> Ja, kommt darauf an ob das aus einem Javacompiler kommt oder nicht. In
> > >> Bytecode geht durchaus einiges, was in Java selbst nicht geht.
> > >
> > Ich meine garnicht geht. Zum Beispiel eine Methode machen, die eine
> > checked Exception wirft, dies in der Signatur aber nicht ausweist.
>
> Das geht auch so, ist ein ziemlich gruseliger Trick mit Generics, der
> darauf beruht, daß die Typprüfung des generischeb Rückgabewerts einer
> Jochen Theodorou wrote:
> > >
> > > On 21.03.2013 14:41, Jochen Theodorou wrote:
> > >> Ja, kommt darauf an ob das aus einem Javacompiler kommt oder nicht. In
> > >> Bytecode geht durchaus einiges, was in Java selbst nicht geht.
> > >
> > Ich meine garnicht geht. Zum Beispiel eine Methode machen, die eine
> > checked Exception wirft, dies in der Signatur aber nicht ausweist.
>
> Das geht auch so, ist ein ziemlich gruseliger Trick mit Generics, der
> Methode beim Aufrufer im Anschluß an den Aufruf erfolgt und deshalb
> nicht erreicht wird, wenn die Methode "terminates abruptly" also die
> verkleidete Exception wirft.
Schamloser Pointer auf mein Blog:
> verkleidete Exception wirft.
> http://brixomatic.wordpress.com/2010/04/29/hack-of-the-day-unchecking-
checked-exceptions/ <
Gruß,
-Wanja-
--
..Alesi's problem was that the back of the car was jumping up and down
dangerously - and I can assure you from having been teammate to
Jean Alesi and knowing what kind of cars that he can pull up with,
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
Wanja Gayk
Mar 27, 2013, 8:11:22 AM3/27/13
to
In article <kihkbt$2lu$1...@newsreader4.netcologne.de>, Patrick Roemer
(sang...@netcologne.de) says...
> >> Methode beim Aufrufer im Anschluￜ an den Aufruf erfolgt und deshalb
verfï¿œgbarkeit von EasyMock oder ï¿œhnlichem.
Sah etwa so aus:
TestImplementation implements MyInterface{
Throwable doSomethingException;
@Override
public void doSomething() throws SomeCheckedException{
if(doSomethingException != null){
Unchecked.rethrow(doSomethingException);
}
//do something test related, count number of invocations, etc
}
}
mit:
@Test
public void testWhateverCallsDoSomethingRuntimeEx(){
TestImplementation mock = new TestImplementation();
mock.doSomethingException = new RuntimeException("TestRuntimeEx");
objectUnderTest.setMyInterface(mock);
objectUnderTest.doWhateverCallsSoSomething();
//TODO: check if exception was handled;
}
@Test
public void testWhateverCallsDoSomethingSomeCheckedEx(){
TestImplementation mock = new TestImplementation();
mock.doSomethingException = new SomeCheckedEx("TestCheckedEx");
objectUnderTest.setMyInterface(mock);
objectUnderTest.doWhateverCallsSoSomething();
//TODO: check if exception was handled;
}
Es gibt aber, habe ich jï¿œngst gelernt, einen einfacheren Ansatz, um
Exceptions zu "unchecken", der ist nicht minder dreckig und liest sich
irgendwie noch gefï¿œhrlicher als der Generics-Hack:
import java.io.FileNotFoundException;
public class SimpleExceptionUncheckNoGenerics {
public static void main(final String[] args) {
try {
Thread.currentThread().stop(new FileNotFoundException("test"));
} catch (Exception e) {
System.out.println("Hello!");
e.printStackTrace();
}
}
}
Gruￜ,
(sang...@netcologne.de) says...
>
> Responding to Jochen Theodorou:
> > Am 21.03.2013 22:39, schrieb Volker Borchert:
> >> Jochen Theodorou wrote:
> >>> Ich meine garnicht geht. Zum Beispiel eine Methode machen, die eine
> >>> checked Exception wirft, dies in der Signatur aber nicht ausweist.
> >>
> >> Das geht auch so, ist ein ziemlich gruseliger Trick mit Generics, der
> >> darauf beruht, daￜ die Typprￜfung des generischeb Rￜckgabewerts einer
> Responding to Jochen Theodorou:
> > Am 21.03.2013 22:39, schrieb Volker Borchert:
> >> Jochen Theodorou wrote:
> >>> Ich meine garnicht geht. Zum Beispiel eine Methode machen, die eine
> >>> checked Exception wirft, dies in der Signatur aber nicht ausweist.
> >>
> >> Das geht auch so, ist ein ziemlich gruseliger Trick mit Generics, der
> >> Methode beim Aufrufer im Anschluￜ an den Aufruf erfolgt und deshalb
> >> nicht erreicht wird, wenn die Methode "terminates abruptly" also die
> >> verkleidete Exception wirft.
> >
> > probier es mal aus, geht imho nicht in 1.7/1.8
>
> http://brixomatic.wordpress.com/2010/04/29/hack-of-the-day-unchecking-checked-exceptions/
>
> Geht in 1.7/1.8 (und Wanja geht ja auch recht ausfuehrlich darauf ein,
> warum das nicht so ueberraschend ist).
>
> Nicht, dass der Ansatz empfehlenswert waere...
Habe ich letztens fï¿œr Unit-Tests gut gebrauchen kï¿œnnen, mangels
> >> verkleidete Exception wirft.
> >
> > probier es mal aus, geht imho nicht in 1.7/1.8
>
> http://brixomatic.wordpress.com/2010/04/29/hack-of-the-day-unchecking-checked-exceptions/
>
> Geht in 1.7/1.8 (und Wanja geht ja auch recht ausfuehrlich darauf ein,
> warum das nicht so ueberraschend ist).
>
> Nicht, dass der Ansatz empfehlenswert waere...
verfï¿œgbarkeit von EasyMock oder ï¿œhnlichem.
Sah etwa so aus:
TestImplementation implements MyInterface{
Throwable doSomethingException;
@Override
public void doSomething() throws SomeCheckedException{
if(doSomethingException != null){
Unchecked.rethrow(doSomethingException);
}
//do something test related, count number of invocations, etc
}
}
mit:
@Test
public void testWhateverCallsDoSomethingRuntimeEx(){
TestImplementation mock = new TestImplementation();
mock.doSomethingException = new RuntimeException("TestRuntimeEx");
objectUnderTest.setMyInterface(mock);
objectUnderTest.doWhateverCallsSoSomething();
//TODO: check if exception was handled;
}
@Test
public void testWhateverCallsDoSomethingSomeCheckedEx(){
TestImplementation mock = new TestImplementation();
mock.doSomethingException = new SomeCheckedEx("TestCheckedEx");
objectUnderTest.setMyInterface(mock);
objectUnderTest.doWhateverCallsSoSomething();
//TODO: check if exception was handled;
}
Es gibt aber, habe ich jï¿œngst gelernt, einen einfacheren Ansatz, um
Exceptions zu "unchecken", der ist nicht minder dreckig und liest sich
irgendwie noch gefï¿œhrlicher als der Generics-Hack:
import java.io.FileNotFoundException;
public class SimpleExceptionUncheckNoGenerics {
public static void main(final String[] args) {
try {
Thread.currentThread().stop(new FileNotFoundException("test"));
} catch (Exception e) {
System.out.println("Hello!");
e.printStackTrace();
}
}
}
Gruￜ,
Jochen Theodorou
Mar 29, 2013, 11:06:28 AM3/29/13
to
Am 27.03.2013 12:51, schrieb Wanja Gayk:
[...]
gelesen haben! Dein blog wurde schon lï¿œngst verlinkt ;)
[...]
> Schamloser Pointer auf mein Blog:
>
>> http://brixomatic.wordpress.com/2010/04/29/hack-of-the-day-unchecking-
> checked-exceptions/ <
Na na Wanja.... erst schamlos sein und dann auch noch den thread nicht
>
>> http://brixomatic.wordpress.com/2010/04/29/hack-of-the-day-unchecking-
> checked-exceptions/ <
gelesen haben! Dein blog wurde schon lï¿œngst verlinkt ;)
Wanja Gayk
Apr 6, 2013, 4:13:33 PM4/6/13
to
In article <arlovk...@mid.individual.net>, Jochen Theodorou
(blac...@gmx.org) says...
..und als ich es gesehen habe, habe ich mehrmals versucht das Posting zu
canceln, aber mein User Agent brachte den Cancel nicht raus, weiￜ der
Admin warum (oder auch der Geier).
Gruￜ,
(blac...@gmx.org) says...
>
> Am 27.03.2013 12:51, schrieb Wanja Gayk:
> [...]
> > Schamloser Pointer auf mein Blog:
> >
> >> http://brixomatic.wordpress.com/2010/04/29/hack-of-the-day-unchecking-
> > checked-exceptions/ <
>
> Na na Wanja.... erst schamlos sein und dann auch noch den thread nicht
> gelesen haben! Dein blog wurde schon lï¿œngst verlinkt ;)
Das habe ich sogar mit Freude zur Kenntnis genommen :-)
> Am 27.03.2013 12:51, schrieb Wanja Gayk:
> [...]
> > Schamloser Pointer auf mein Blog:
> >
> >> http://brixomatic.wordpress.com/2010/04/29/hack-of-the-day-unchecking-
> > checked-exceptions/ <
>
> Na na Wanja.... erst schamlos sein und dann auch noch den thread nicht
> gelesen haben! Dein blog wurde schon lï¿œngst verlinkt ;)
..und als ich es gesehen habe, habe ich mehrmals versucht das Posting zu
canceln, aber mein User Agent brachte den Cancel nicht raus, weiￜ der
Admin warum (oder auch der Geier).
Gruￜ,
0 new messages