W dniu czwartek, 16 maja 2013 08:36:25 UTC+2 użytkownik boryspower napisał:

> Właśnie - ukrycie kodu źródłowego to jedna z tych rzeczy o których
> zapomniałem wspomnieć, że przydałaby się :) Ale przecież java "kompiluje"
> się do *.class a te później pakuje się w JARy... z class'ów chyba nie da się
> kodu wyciągnąć?
Z tego co wiem, a także z kilku prób które zrobiłem, da się odzyskać kod.
Jedyne różnice to zamiana pętli for na while :)

Znajomy mi mówił (wykłada Javę na uczelni) że widział eksperyment z
jakimiś narzędziami do utrudniania procesu odzyskiwania kodu. Jednak
też udało mu się odzyskać kod i jak powiedział "był jeszcze łatwiejszy
w czytaniu". Więc te narzędzia raczej nic nie dadzą. Są jeszcze jakieś
kompilatory javy do kodu natywnego. Kiedyś jakiś sprawdzałem, po
skompilowaniu czas wykonania wzrósł 2-3 krotnie i już nie chciało mi
się sprawdzać, czy w pliku naprawdę są instrukcje maszynowe.


> Co do ultra wydajności - jakiś czas temu na wykopie było AMA
> programisty który w Javie właśnie pisze hiper-szybkie aplikacje
> na giełdę... więc się da ;)
To prawda. Java jako język i zestaw dostępnych narzędzi daje możliwość
tworzenia wydajnych aplikacji. Jednak C/C++ jest jeszcze lepszy pod
tym względem.


Pozdrawiam

do góry

W dniu czwartek, 16 maja 2013 15:46:48 UTC+2 użytkownik Borneq napisał:
> U�ytkownik "boryspower" napisa� w wiadomo�ci
>
> news:c22abf8b-a3c0-4c2b-aa9d-9d756f84bc2a@googlegrou
ps.com...
>
> > Hmm... Delphi wygl�da/zapowiada si� interesuj�co... tylko jedn� z rzeczy
o
>
> > kt�rych
>
> > zapomnia�em wspomnie� jest, �e przyda�aby si� technologia nie
wymagaj�ca
>
> > du�ych
>
>
>
> Mo�e Lazarus? Wersja 1.08 naprawd� nie�le dzia�a.

Ostatnio Lazarusa używałem ponad rok temu... albo i dawniej... versja była chyba 0.8
- był bardzo obiecujący... i tak jak w Delphi - błyskawicznie kompilował :) OK -
zaczynam ściągać i testować :)

--
Przemek

do góry

Użytkownik "boryspower" <b...@g...com> napisał w wiadomości
news:05cd220f-d496-4c6d-88ab-ed01f6ca5041@googlegrou
ps.com...
> Ostatnio Lazarusa używałem ponad rok temu... albo i dawniej... versja była
> chyba 0.8 - był > bardzo obiecujący... i tak jak w Delphi - błyskawicznie
> kompilował :) OK - zaczynam
> ściągać i testować :)

Wesja 1 w porównaniu do 0.9.x mi się dużo więcej podoba. Na przykład jest
import z Delphi z mośliwością ustawienia że ma kompilować równiez pod Delphi
(może używać dfm) więc można zrobić nawet źródła przenośne.
Delphi<->FreePascal

do góry

On Wed, 15 May 2013 23:29:02 -0700 (PDT), boryspower
<b...@g...com> wrote:


>
>Dzięki :) lecz trochę mam już dość "prymitywnej" zabawy w różnych językach -
chciałbym w którymś
>osiągnąć trochę wyższy stopień zaawansowania i w końcu ukończyć jakiś większy
projekt, opublikować >
>go i mieć satysfakcję z obserwowania licznika pobrań oraz feedbacku od userów :)

Troche zaczynasz "od konca". Na ogol jest tak ze sie chce cos zrobic i
szukasz najlepszego narzedzia. Ty studiujesz narzedzia dla narzedzi,
nie majac jasnej koncepcji co chcesz zrobic.

To troche tak jak z moim znajomym ktory ma takie hobby ze gromadzi
narzedzia stolarskie. Godzinami potrafi rozprawiac nad wyzszoscia
heblarki Bosh nad heblarka B&D. Pytany po co mu te narzedzia, mowi ze
jak tarfi na wlasciwe, bedzie robil antyki w stylu Ludwika
jakiegostam. Poki co nei zbudowal nawet karmnika dla ptakow.

Drugi znajomy na pile krajzege, wlasnorecznie zrobiony hebel, mlotek i
dluto. I rzeczywiscie robi antyki w stylu Ludwika jakiegostam

Jezyki programowania to narzedzie i "lepszosc" jednych wzgledem
drugich da sie ocenic tylko w kontekscie problemu do ktorego sa
uzywane. Nie da sie ich oprawic w ramki, powiesic na scianie i
podziwiac

Przy okazji: nasz miszmasz terminologiczny. JEZYK PROGRAMOWANIA to
jesyk. Do tego dochodzi kompilator. Programy oisze sie w odpowiednim
srodowisku wspierajacym edytowanie tekstu programu i korzysta z
bibliotek. Ty zas wrzucasz wszystko do jednego worka, twierdzac ze
"kolorowanie sytnaksu" jest czescia "jezyka programowania". Nie, nie
jest. Jest czescia edytora. Jest multum edytorow ktore mozna uzywac do
pisania programow w tym samym, konkretnym jezyku.

Podobnie z bibliotekami.

Wiec nei jest jasne czego szukasz. Jezyka, kompilatoar, edytora,
bibliotek czy czegos innego. Bo to moga byc zupelnie osobne
poszukiwania

A.L.

P.S> Jakbys naciskal klawisz ENTER od czasu do czasu to twoje posty
byloby latwiej czytac.

do góry

On Wed, 15 May 2013 21:16:54 -0700 (PDT), "M.M." <m...@g...com>
wrote:

>W dniu środa, 15 maja 2013 20:08:41 UTC+2 użytkownik boryspower napisał:
>> pchnąć w odpowiednim kierunku.
>Takie pchnięcie kogoś może okazać się po jakimś czasie że było w
>złym kierunku. Można natomiast dyskutować o samych językach i
>dostępnych narzędziach. Wtedy masz podstawę do tego aby samemu na
>coś się zdecydować.
>
>
>> Teoretycznie wszystkie te warunki najlepiej spełnia Java
>> (tak mi się wydaje), tylko ten 8 punkt mi pod Javę nie pasuje...
>> Co Wy byście mi polecili?
>Polecam właśnie Javę, jest najbliżej mojego ideału. Java to bardzo dobry
>język który nadaje się do większości zastosowań. O ile się nie mylę, o
>ma jedynie problemy w zastosowaniach do sterowania.

Akurat niekoniecznie. Zalezy do sterowania czego. Jest w koncu
standard Real Time Java i jakies implementacje...

A.L.

do góry

On Thu, 16 May 2013 07:55:28 -0700 (PDT), "M.M." <m...@g...com>
wrote:

>
>Znajomy mi mówił (wykłada Javę na uczelni) że widział eksperyment z
>jakimiś narzędziami do utrudniania procesu odzyskiwania kodu. Jednak
>też udało mu się odzyskać kod i jak powiedział "był jeszcze łatwiejszy
>w czytaniu". Więc te narzędzia raczej nic nie dadzą. Są jeszcze jakieś
>kompilatory javy do kodu natywnego. Kiedyś jakiś sprawdzałem, po
>skompilowaniu czas wykonania wzrósł 2-3 krotnie i już nie chciało mi
>się sprawdzać, czy w pliku naprawdę są instrukcje maszynowe.

Komercjalne "obfuscatory" sa dosyc trudne do zlamania

A.L.

do góry

On Thu, 16 May 2013 06:47:09 +0100, Andrzej Jarzabek
<a...@g...com> wrote:

>variables. Teoretycznie wbudowane w język synchronized i notify trochę
>upraszaczają pisanie programów,

Dlaczego "teoretycznie"?...

A.L.

do góry

On 17/05/2013 01:46, A.L. wrote:
> On Thu, 16 May 2013 06:47:09 +0100, Andrzej Jarzabek
> <a...@g...com> wrote:
>
>> variables. Teoretycznie wbudowane w język synchronized i notify trochę
>> upraszaczają pisanie programów,
>
> Dlaczego "teoretycznie"?...

Może nie najszczęśliwiej dobrane słowo. Chodzi o to, że to to samo, co
mutex i condition variable. Główny problem z użyciem tych konstruktów
jest poprawny projekt, a w tym temacie synchronized/notify nie pomaga.

do góry

Dnia Thu, 16 May 2013 19:44:57 -0500 po głębokim namyśle A.L. rzekł:

> On Thu, 16 May 2013 07:55:28 -0700 (PDT), "M.M." <m...@g...com>
> wrote:
>
>
>>Znajomy mi mówił (wykłada Javę na uczelni) że widział eksperyment z
>>jakimiś narzędziami do utrudniania procesu odzyskiwania kodu. Jednak też
>>udało mu się odzyskać kod i jak powiedział "był jeszcze łatwiejszy w
>>czytaniu". Więc te narzędzia raczej nic nie dadzą. Są jeszcze jakieś
>>kompilatory javy do kodu natywnego. Kiedyś jakiś sprawdzałem, po
>>skompilowaniu czas wykonania wzrósł 2-3 krotnie i już nie chciało mi się
>>sprawdzać, czy w pliku naprawdę są instrukcje maszynowe.
>
> Komercjalne "obfuscatory" sa dosyc trudne do zlamania

Na tyle trudne, żeby nikomu się nie chciało?

--
Edek

do góry

Dnia Fri, 17 May 2013 07:33:00 +0100 po głębokim namyśle Andrzej Jarzabek
rzekł:

> On 17/05/2013 01:46, A.L. wrote:
>> On Thu, 16 May 2013 06:47:09 +0100, Andrzej Jarzabek
>> <a...@g...com> wrote:
>>
>>> variables. Teoretycznie wbudowane w język synchronized i notify trochę
>>> upraszaczają pisanie programów,
>>
>> Dlaczego "teoretycznie"?...
>
> Może nie najszczęśliwiej dobrane słowo. Chodzi o to, że to to samo, co
> mutex i condition variable. Główny problem z użyciem tych konstruktów
> jest poprawny projekt, a w tym temacie synchronized/notify nie pomaga.

Nie, nie "to samo". Przykład pierwszy z brzegu:
mutex1.lock();
mutex2.lock();
mutex1.unlock(); // jak to zrobić blokami "synchronized"?

Dopiero pakiet concurrent uzupełnia tego typu braki. Najciekawsze jest
to, że bajtkod Javy umożliwia zakodowanie powyższego.

--
Edek

do góry