🚀 go-pugleaf

Seweryn Habdank-Wojewódzki wrote:

> Ale poco łamać ochronę? Czy nie ufasz sprzedawcy kodu? Czy to chodzi o kod
> tworzony dynamicznie - lokalna kompilacja kodu zdalnego?

Kodowi, który kupuję, to zazwyczaj już ufam.  Nie ufam temu, który 
odpalam, np. z JWS, lub jako aplet, czy jakiś inny kod Java, co do 
którego spodziewać się mogę niecnych zamiarów...  Nie uruchamiasz 
takiego kodu?

> 
> Nie kapuję, czy przypadkiem to nie jest bardziej kwestia prawna, że kupując
> czyjś kod ufasz, że nie zrobi ci nic złego?

Zaufanie to jedno, możliwość sprawdzenia, to drugie.


>> Jeśli jednak uważasz, że ochrona kodu oferowana w Javie jest dziurawa,
>> to chętnie pooglądam kod, który ją łamie.  Znasz taki?

[...]

>> (Oczywiście nie wskazuj mi na JNI, gdzie Java się kończy a zaczyna
>> natyw, pytam o kod Javy, który np. spowoduje, że java.lang.String
>> przestanie być immutable, wbrew swojej definicji i publicznemu
>> interfejsowi...)
> 
> Rozumiem.

Z innej odnogi wątku widzę, że nie rozumiesz!

Nie chcę słyszeć o JNI, bo to _nie jest Java_, a jej interfejs do natywa 
-- czyli czegoś, co dziurawe jak sito może być, i temu najrzadziej nie ufam!

> W sumie to jest jedyna rzecz którą znam która to może wywalić JVM.
> Ale jak to powiadam zazwyczaj o C używanym w C++ - "Jak ktoś przecina
> przewody paliwa w samochodzie co niech nie płacze, że nie jedzie."

W Javie jest różnica taka, że nawet jeśli będziesz próbował poprzecinać, 
to jedynie może Cię prąd kopnie, kable zostaną całe!!

> Tu też to odnoszę więc JNI nie podaję jako przykład.

Bo to nie jest żaden przykład!  Tak samo, jak zabronić np. zatrzymania 
wątków, security-manager może zabronić niezaufanemu kodowi uruchamiania 
natywnego kodu.  To, że z natywa możesz rozwalić wszystko, to już nie 
jest problem Javy, a natywa własnie (napisanego np. w C++)!


piotr