About jobfuscate
srinivas...@gmail.com
Can I include "jobfuscate" command in the build.xml for
generating the jar.
Thanks in advance....
Srinivas.
twerp...@gmail.com
> Hi All,
>
> Can I include "jobfuscate" command in the build.xml for
> generating the jar.
If you think that there's any point in doing so, well ... I have this
bridge I've been trying to unload that I'm willing to let go for the
low, low price of $17,569.99 ...
Owen Jacobson
I had a look at their site and the Duckware people don't seem to have
made any ant tasks for jobfuscate. However, you can run any arbitrary
program using the ant <exec> task:
<http://ant.apache.org/manual/CoreTasks/exec.html>
-o
Daniel Dyer
wrote:
Alternatively, try Proguard (http://proguard.sourceforge.net). Not only
does it have an Ant task, it's also "proper free". I've used it on a
number of projects and found it to be the best of the obfuscators that I
have tried over the years.
Dan.
--
Daniel Dyer
http://www.uncommons.org
twerp...@gmail.com
> Alternatively, try Proguard (http://proguard.sourceforge.net). Not only
> does it have an Ant task, it's also "proper free". I've used it on a
> number of projects and found it to be the best of the obfuscators that I
> have tried over the years.
Yup, and if you think that there's any point at all in using it,
Daniel Dyer
Perhaps it won't fully satisfy the OP's desire to protect their code, but
that doesn't make it useless.
You could make a case that it has merit since it raises the barrier for
reverse-engineering. However, ignoring that argument completely (since I
sense you are taking the position that obfuscation provides no benefit in
this respect), obfuscators still perform another important function.
An obfuscator will typically reduce the size of the compiled code by 50%
or more. This can be useful for applets and Web Start applications (saves
on data transfer costs and download times) but even more so for mobile
development. In fact, for J2ME, the primary reason for using an
obfuscator is for the shrinking, the IP considerations are secondary.
So yes, I do think there is a point in using an obfuscator for certain
projects. Now where do I collect that bridge?
nebul...@gmail.com
> Perhaps it won't fully satisfy the OP's desire to protect their code, but
> that doesn't make it useless.
Funny how language like "protect their code" gets used. Also the silly
blurb at the end of just about every movie saying "This movie is
protected by..."; discouraging the copying of information, far from
protecting it, actually endangers it as it's more likely for every
copy to get wiped out somehow and for the information in question to
go extinct. Think what happens to a species of life that quits
reproducing!
What someone is actually trying to protect is a business model and an
artificially high price for a good in some market -- "protect" as in
"protectionism", a failed economic policy of centuries past that lives
on in a few obscure niches mostly concerning the fiction known as
"intellectual property".
> You could make a case that it has merit since it raises the barrier for
> reverse-engineering.
I don't believe that to have any value whatsoever. There is evidence
from research in economics and other disciplines that raising the
barrier for reverse engineering costs a bit but has a net payoff of
precisely zero. Except sometimes when the payoff is negative, because
bugs go unfixed, or possible synergistic third-party interoperable
products that add value don't get created. In the Doom days, id
Software learned that allowing reverse engineering can have a net
benefit when third-party add-ons for Doom started appearing that made
the game more valuable and id Software more money.
Inhibiting reverse engineering does allow you to create a vertical
monopoly on accessories, consumables, and other interoperable
products, but it's not one consumers will enjoy and that will bite you
someday, and it's also a fragile monopoly, as makers of certain
printers and garage-door openers discovered to their chagrin. That
monopoly is also not legally protected by the DMCA, as those same
companies also discovered to their chagrin.
> An obfuscator will typically reduce the size of the compiled code by 50%
> or more.
This is a benefit I had not considered, but it is also merely a side
effect of an obfuscator. A simple binary-stripper not specifically
designed for obfuscation would serve this purpose equally well.
I'm also unsure how much a LZW-compressed JAR will benefit from this;
the uncompressed code may be 50% of the original size, but the
compressed code may be only a smidgen smaller. I'd need to see real
data on this; in particular, you didn't claim that the *compressed*
compiled code would be 50% smaller and it seems much more likely that
the uncompressed code is what gets 50% smaller.
Regardless, it is likely that there are tools specifically designed to
shrink binaries as much as possible without mutating their semantics
that will outperform an obfuscator at binary compression, but would be
outperformed by an obfuscator at obfuscating (as measured by how high
it raises the barrier to reverse engineering, not by measuring the
zero-to-negative benefits of doing so).
So if obfuscation is the goal, I don't believe the OP's larger goals
are actually served by doing so, and if compression is the goal, a
tool dedicated to making binaries smaller would be a better choice --
right tool for the right job, and all that -- so I wouldn't recommend
an obfuscator be used by the OP in either case.
Daniel Dyer
> On Dec 31 2007, 1:38 pm, "Daniel Dyer" <"You don't need it"> wrote:
>> An obfuscator will typically reduce the size of the compiled code by 50%
>> or more.
>
> This is a benefit I had not considered, but it is also merely a side
> effect of an obfuscator. A simple binary-stripper not specifically
> designed for obfuscation would serve this purpose equally well.
>
> I'm also unsure how much a LZW-compressed JAR will benefit from this;
> the uncompressed code may be 50% of the original size, but the
> compressed code may be only a smidgen smaller. I'd need to see real
> data on this; in particular, you didn't claim that the *compressed*
> compiled code would be 50% smaller and it seems much more likely that
> the uncompressed code is what gets 50% smaller.
Yes. Clearly the uncompressed class files will see a bigger reduction in
size than a compressed JAR/zip. I've seen 50% reductions in zipped JAR
size, but I would be hesitant to say that this is the usual performance,
perhaps 30% is a more realistic estimate. It is also dependent on whether
the classes were compiled with debug information. If not, then there will
be less information that can be removed from the class files.
LZW is lossless. A key point about the compression offered by an
obfuscator/shrinker is that it is lossy. It reduces the amount of
information in the class files (hopefully without modifying their
behaviour), so it should still offer reductions beyond what you can
achieve with a lossless compression scheme.
On a releated noted, you may also be interested in Pack200, a compression
scheme specifically for JARs. I haven't used it but Sun claims compressed
file sizes of 1/9 of the original for large JARs:
http://java.sun.com/j2se/1.5.0/docs/guide/deployment/deployment-guide/pack200.html
> Regardless, it is likely that there are tools specifically designed to
> shrink binaries as much as possible without mutating their semantics
> that will outperform an obfuscator at binary compression
Of the tools I've seen there doesn't appear to be a distinction between
obfuscators and shrinkers. I believe the techniques are so similar (both
are concerned with removing information) as to make the differences
largely academic.
Roedy Green
wrote, quoted or indirectly quoted someone who said :
> Can I include "jobfuscate" command in the build.xml for
>generating the jar.
Have a look at how I included genjar and jet which are also not
directly supported. See http://mindprod.com/jgloss/ant.html
for examples.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
Joe Attardi
> If you think that there's any point in doing so, well ... I have this
> bridge I've been trying to unload that I'm willing to let go for the
> low, low price of $17,569.99 ...
obfuscation. We all know that closed-source or proprietary software is
the evil work of the devil, but spare this guy the lecture and just let
someone answer his question...
Arne Vajhøj
> Yes. Clearly the uncompressed class files will see a bigger reduction
> in size than a compressed JAR/zip.
> LZW is lossless.
Not that it mean anything for your argument, but jar/zip does
not use LZW. LZW is a LZ78 type but ZIP is a LZ77 type.
Arne
Joshua Cranmer
> Of the tools I've seen there doesn't appear to be a distinction between
> obfuscators and shrinkers. I believe the techniques are so similar
> (both are concerned with removing information) as to make the
> differences largely academic.
I've heard "optimizer" used for a tool performing shrinking in this
manner (rather ambiguous term, IMO, but meh).
Just as a note, there are three types of obfuscation: name obfuscation,
string obfuscation, and flow obfuscation. Most obfuscators as such do
all three while the space benefits accrue only from name obfuscation
(indeed, the other two will inflate space while not making code more
terribly difficult to reverse-engineer).
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
Mark Space
It is nevertheless humorously appropriate in this case. The OP may be
unaware that obfuscation isn't going to provide much benefit.
Mike Schilling
Quibble:
If you're building a library of any complexity, it can be very
difficult to ensure that only the classes and methods you want to be
public (that is, that you intend to support in future version of the
library) are called across package boundaries. E.g, I build a utility
class and call if from various places in my library, knowing full well
that I haven't really thought its use through and may want to refactor
it later. I have no real choice but to make it a public class with
public methods. Users of such libraries have a distressing habit of
finding such classes, figuring out what they do, using them, and then
complaining when upgrading to a later release breaks their
application. Using an obfuscator to change the class name to
NJvbuuU456 and its methods to jkkKJ66, jJhgf88, and IIUysdgsgG33 is a
handy way of preventing that.
(I'm wondering now: does the JVM enforce the Java rules for class and
method names? It would be even better for the obfuscated names to
contain spaces, making them uncallable from Java.)
nebul...@gmail.com
> LZW is lossless.
Of course. One does not normally use lossy compression on code.
Stripping debug info etc. aside.
> A key point about the compression offered by an obfuscator/shrinker is
> that it is lossy. It reduces the amount of information in the class
> files (hopefully without modifying their behaviour), so it should
> still offer reductions beyond what you can achieve with a lossless
> compression scheme.
True, but I have to wonder how effective that tends to be when
combined with "real" compression (e.g. LZW). What a binary stripper
removes tends to be text, such as function names, and tends to have
been duplicated all over the place. The "real" compression would
replace all of the copies with a single short symbol and perhaps, if
its occurrence was predictable, further reduced those. Text compresses
well, and what's left after obfuscation doesn't, and that remnant may
even compress worse than before after a true obfuscation (but not
after mere symbol-stripping).
I wouldn't be surprised if your 30%-further-reduction estimate is
optimistic, nevermind 50%. Even so, I'd expect better results with
something designed for shrinking binaries than with something designed
with a less benign motive and optimized by somewhat different criteria
as a result.
> On a releated noted, you may also be interested in Pack200, a compression
> scheme specifically for JARs. I haven't used it but Sun claims compressed
> file sizes of 1/9 of the original for large JARs:
>
> http://java.sun.com/j2se/1.5.0/docs/guide/deployment/deployment-guide...
Does this strip runtime-unnecessary information from the binaries?
> > Regardless, it is likely that there are tools specifically designed to
> > shrink binaries as much as possible without mutating their semantics
> > that will outperform an obfuscator at binary compression
>
> Of the tools I've seen there doesn't appear to be a distinction between
> obfuscators and shrinkers. I believe the techniques are so similar (both
> are concerned with removing information) as to make the differences
> largely academic.
I find this surprising. Obfuscators usually don't just remove debug/
symbol information from binaries but also perform semantics-preserving
transformations of the actual code designed to make decompilation
produce very nasty and human-unreadable source code (deeply nested
crap, inlining out the wazoo, what-have-you). Many of these
transformations resemble those performed by optimizing compilers, but
may include "sideways" changes that don't improve run time (or even
slightly worsen it) in exchange for producing nastier decompiled code.
In the case of Java, I'd expect such obfuscatory transformations to
play hell with JIT compilation (these days with Hotspot one actually
gets better performance from unoptimized bytecode than optimized, or
so I've heard). I'd also expect obfuscation to reduce the
compressibility of the code relative to a straight symbol-stripping.
Then again, perhaps the Java obfuscators don't tend to perform those
additional, non-symbol-stripping transformations. Perhaps there's
little mileage in it due to the nature of the bytecode language or
something.
Anyone who knows more about this stuff, feel free to pipe up and
settle some of these questions. :)
nebul...@gmail.com
> twerpina...@gmail.com wrote:
> > If you think that there's any point in doing so, well ... I have this
> > bridge I've been trying to unload that I'm willing to let go for the
> > low, low price of $17,569.99 ...
>
> The OP was not asking for your philosophical opinion on code
> obfuscation.
What philosophical opinion? What I wrote was an economic opinion: it's
not worth the time and hassle and, if jobfuscate itself is expensive,
the money. The OP's ROI may be zero, or it may actually be negative.
(Think of id Software's ROI if, hypothetically, they'd obfuscated the
heck out of DooM and had thereby succeeded in stopping its eventual
reverse engineering by hackers -- they might still be a two-man garage
band instead of the big-name act they became in reality. Or they might
have disappeared completely, or been absorbed into a big and
uninnovative company like EA for a mediocre cashing-out, or something.
They'd have less money, anyway. And we'd have no Quake, and therefore
no HL2, no Quake 3: Arena, no Quake 4, no ET:QW, no DooM 3, no none of
it. Ouch!)
> We all know that closed-source or proprietary software is the evil
> work of the devil, but spare this guy the lecture and just let
> someone answer his question...
I don't have a beef with him developing closed-source software. Going
out of his way to mess up reverse engineering is somewhat nasty though
(reverse engineering is fair use under U.S. copyright law) and likely
pointless anyway.
At least, unlike that other guy, he doesn't seem to be asking how to
make his software buggier and less valuable by adding phone-home
"license management" crud. License managers such as Adobe products use
are a solution looking for a problem IMO.
nebul...@gmail.com
Last I checked, zip at least can use several sorts of compression from
the LZ family, and even some from outside it. Perhaps jar doesn't tend
to use the full range, though.
LZW is definitely used in GIF and LZSS in some other lossless-
compressed file formats (maybe PNG?); GIFs may well occur *inside*
jars.
nebul...@gmail.com
> It is nevertheless humorously appropriate in this case. The OP may be
> unaware that obfuscation isn't going to provide much benefit.
That was exactly my point. Obfuscators (and also copy protection) are
snake oil. Any kind of expensive cryptography or similarly that relies
on security through obscurity (including any that put the decryption
keys on untrusted systems but try to hide them from those systems'
administrators, including in turn every form of copy protection known
to Man) is snake oil and not worth so much as one lousy thin dime or
moment of your time, nevermind whatever's actually being charged for
it.
Obfuscation is, essentially, weak encryption. Copy protection (or
using *real* encryption on the binary and an obfuscated stub that
decrypts it, which is a stronger form of obfuscation) is stronger
encryption but leaves a decryption key in the hands of every would-be
attacker, albeit hidden or obfuscated in some manner. It only takes
one to manage to decrypt and crack your app and upload it to p2p and
warez sites and free copies are out there and easy for anyone else to
download and install, so it doesn't matter if Joe Average can't crack
it; Joe Average *can* use Limewire and someone else *can* both crack
it *and* use Limewire. And sooner or later, someone will, unless your
product is so obscure that your main problem is low volume. In that
case, free copies will, through network effects, actually raise sales
volume anyway, and right when you want it least your copy protection
suddenly is actually effective! Ouch.
Crypto that relies on secrecy of the algorithm is similarly snake oil.
The MPAA found this out to their chagrin when the CSS* copy-protection
emperor was discovered to be devoid of clothing a decade or so ago.
The same mistake keeps being repeated over and over in computing
history though, with the odd prominent case (a vulnerable e-voting
machine here, some ATMs being hacked there...) or high-profile
individual leak of supposedly-secure data and a constant low-grade
churn of instances that go unnoticed. AES, Blowfish, and the
asymmetric ciphers used to encode symmetric session keys for things
like SSL are all you really need (with a big enough key size; stay
away from 56-bit DES, which is dead).
Of course, some entities just don't learn. The MPAA learned a little
after the CSS debacle and relied on stronger crypto with their HD-DVD
AACS encryption. Too bad they forgot that copy protection is
invariably essentially DOA anyway because it puts the keys in the
hands of the untrusted parties. AACS has, predictably, been cracked
wide open, and all their fancy key-revocation nonsense did was make it
need cracking every few months instead of just once. :P
* Check out http://en.wikipedia.org/wiki/Content_Scramble_System --
just the phrase "proprietary 40-bit stream cipher" is sufficient to
give any security expert the willies, and enable him to accurately
guess its current essentially-defunct status at the same time, if it
weren't that any security expert worthy of the title already knows
what CSS is and what happened to it. CSS got pretty much *everything*
wrong, since it a) was copy protection and thus gave potential
attackers the decryption keys, b) had fewer bits than even DES, and c)
had a proprietary algorithm ALL AT THE SAME TIME. :P And millions of
dollars were wasted on this boondoggle, and again on its successor
AACS which made at least the first of the three mistakes all over
again and likewise was rapidly cracked.
nebul...@gmail.com
wrote:
> If you're building a library of any complexity, it can be very
> difficult to ensure that only the classes and methods you want to be
> public (that is, that you intend to support in future version of the
> library) are called across package boundaries. E.g, I build a utility
> class and call if from various places in my library, knowing full well
> that I haven't really thought its use through and may want to refactor
> it later. I have no real choice but to make it a public class with
> public methods. Users of such libraries have a distressing habit of
> finding such classes, figuring out what they do, using them, and then
> complaining when upgrading to a later release breaks their
> application. Using an obfuscator to change the class name to
> NJvbuuU456 and its methods to jkkKJ66, jJhgf88, and IIUysdgsgG33 is a
> handy way of preventing that.
How crufty.
The proper thing to do, of course, is to make various things
(preferably the entire class) package-private instead of public.
There are other things you can do, e.g. if you have a multi-package
structure such that the above will not work:
* Structure your packages better/differently, so that it *does* work.
* Stick these in a .internal package and don't publish any javadocs
for this package.
* *Do* publish javadocs for it but put a big bold warning at the top
of every class comment and the package.html saying INTERNAL CLASS
WHOSE API MAY CHANGE. USE AT OWN RISK. (Sun chose a similar tack
with the sun.* packages used to implement the standard library.
No javadocs for them, but stern warnings everywhere else not to
directly use sun.* for anything.)
* Deprecate everything in the class and, if possible, the class
itself,
and put up with the annoying warnings when compiling your library.
* Version the internal class. If you change its API, do this to a copy
with a changed name (e.g. Foobarv2, Foobarv3...) and change all your
internal uses to point to the new version. This way, nothing that
uses the old version gets (more) broken as a result of your changes.
This isn't significantly more work with a refactoring IDE like
Eclipse that makes changing every reference to a class a snap.
It will bloat your successive versions with legacy code, though.
If you do this, clearly indicate that these classes are unsupported
though have stable APIs, either in their javadocs or, if they have
none, in other documentation.
* Actually refactor the internal stuff BEFORE releasing the library.
Make it good. Make it yummy. Document it and commit to supporting
it.
After all, if you found it useful, someone else might as well.
You may also find and fix some bugs and improve your design while
you're at it.
Some would say that the existence of anything "private" that isn't
data is a sign of a design problem. Call it the "shame smell".
Implementation detail of class A though it may be, it might better
belong to a class B and be a public, maintained utility method.
Got a Rational class with a private GCD method in it that has a
superior algorithm? Why not make that a public MyMath.gcd() that
others can use and that your Rational class also happens to use?
Your collection class has an entire red/black tree implementation
hidden in it in the form of private nested classes? Why not
refactor this into a public red/black tree implementation that
is privately used by your collection class?
But it's ultimately up to you. In the long run, though, you will have
to maintain your class as part and parcel of maintaining its
dependents. Maintaining the whole shebang will, in the long run, be
easier if the internal interface is just as stable and well-specified
and everything as your external interfaces hopefully are. And then the
class may as well be published.
Joshua Cranmer
> Obfuscation is, essentially, weak encryption. Copy protection (or
> using *real* encryption on the binary and an obfuscated stub that
> decrypts it, which is a stronger form of obfuscation) is stronger
> encryption but leaves a decryption key in the hands of every would-be
> attacker, albeit hidden or obfuscated in some manner.
Encryption is even easier to break than obfuscation. There is one point
through which all Java classes must be defined (a chokepoint in
java.lang.ClassLoader), and anyone with the wits to mess around the
bootclasspath can easily defeat even the strongest encryption this way.
Flow obfuscation makes most decompilers choke, and (despite being
obvious to detect) requires much more time to work out. Far better to be
obfuscated than encrypted.
Arne Vajhøj
> On Jan 3, 7:33 pm, Arne Vajhøj <a...@vajhoej.dk> wrote:
>> Daniel Dyer wrote:
>>> Yes. Clearly the uncompressed class files will see a bigger reduction
>>> in size than a compressed JAR/zip.
>> ...
>>> LZW is lossless.
>> Not that it mean anything for your argument, but jar/zip does
>> not use LZW. LZW is a LZ78 type but ZIP is a LZ77 type.
>
> Last I checked, zip at least can use several sorts of compression from
> the LZ family, and even some from outside it. Perhaps jar doesn't tend
> to use the full range, though.
The ZIP file format allows for multiple compression algorithms.
But in practice no compression and the zip deflate algorithm are
the ones used.
> LZW is definitely used in GIF and LZSS in some other lossless-
> compressed file formats (maybe PNG?);
PNG also uses zip deflate.
I doubt that any modern software or format uses LZSS.
> GIFs may well occur *inside*
> jars.
Yep. But that does not make jar use LZW.
Arne
Arne Vajhøj
> On Jan 3, 4:03 pm, "Daniel Dyer" <"You don't need it"> wrote:
>> A key point about the compression offered by an obfuscator/shrinker is
>> that it is lossy. It reduces the amount of information in the class
>> files (hopefully without modifying their behaviour), so it should
>> still offer reductions beyond what you can achieve with a lossless
>> compression scheme.
>
> True, but I have to wonder how effective that tends to be when
> combined with "real" compression (e.g. LZW). What a binary stripper
> removes tends to be text, such as function names, and tends to have
> been duplicated all over the place. The "real" compression would
> replace all of the copies with a single short symbol and perhaps, if
> its occurrence was predictable, further reduced those. Text compresses
> well, and what's left after obfuscation doesn't, and that remnant may
> even compress worse than before after a true obfuscation (but not
> after mere symbol-stripping).
Not so relevant.
If compression is needed then jar provides that.
The point is that the output from an obfuscator shrinking
is valid byte code.
Compressed data are not.
Two different purposes.
> I find this surprising. Obfuscators usually don't just remove debug/
> symbol information from binaries but also perform semantics-preserving
> transformations of the actual code designed to make decompilation
> produce very nasty and human-unreadable source code (deeply nested
> crap, inlining out the wazoo, what-have-you). Many of these
> transformations resemble those performed by optimizing compilers, but
> may include "sideways" changes that don't improve run time (or even
> slightly worsen it) in exchange for producing nastier decompiled code.
> In the case of Java, I'd expect such obfuscatory transformations to
> play hell with JIT compilation (these days with Hotspot one actually
> gets better performance from unoptimized bytecode than optimized, or
> so I've heard). I'd also expect obfuscation to reduce the
> compressibility of the code relative to a straight symbol-stripping.
> Then again, perhaps the Java obfuscators don't tend to perform those
> additional, non-symbol-stripping transformations. Perhaps there's
> little mileage in it due to the nature of the bytecode language or
> something.
The main function of Java obfuscators is to mangle names. And that
has zero impact on runtime performance.
Arne
Lew
> Far better to be obfuscated than encrypted.
I've maintained some code whose original authors must have subscribed to that
philosophy proactively. Running an obfuscator over their code would be redundant.
What's worse, this also holds true for wizard-generated JSF code I've seen
come out of the Rational Application Developer (RAD) IDE, whose maker shall
remain nameless lest they take not kindly to being mentioned by name.
I can see a competitive advantage to letting the opposition have some source
code unchanged.
--
Lew
nebul...@gmail.com
> [unprovoked attack post deleted]
You're wrong. None of the nasty things that you have implied about me
are at all true.
(All forms of encryption and obfuscation are "weak" in absolute terms,
though, because the untrusted party has all the information they need,
in principle, to defeat it.)
nebul...@gmail.com
> [much of unprovoked attack post posted in response to my own
> perfectly civil and on-topic post deleted]
>
> The ZIP file format allows for multiple compression algorithms.
I believe that is more or less what I said.
> But in practice [snip]
That's not been my observation.
> > LZW is definitely used in GIF and LZSS in some other lossless-
> > compressed file formats (maybe PNG?);
>
> PNG [snip]
That's also not been my observation. PNG supports several compression
types also, and pngcrush will try many of them to reencode your pngs
smaller, with no quality loss.
> I doubt that any modern software or format uses LZSS.
That's not been my observation either.
> [remainder deleted]
Joe Attardi
> On Jan 7, 5:46 pm, Joshua Cranmer <Pidgeo...@verizon.invalid> wrote:
>> [unprovoked attack post deleted]
disagreement can be seen as an attack?
> You're wrong. None of the nasty things that you have implied about me
> are at all true.
Isn't it you who goes off on people for saying flat out, "You're wrong"
- but apparently it's OK for you to say?
He didn't imply anything nasty about you. He didn't even commit the
cardinal sin, and say "you're wrong" - he simply gave his point of view
which differs from yours. How is this implying something nasty?
nebul...@gmail.com
> [snip much of unprovoked attack post posted in response to my
> perfectly civil and on-topic post]
>
> Two different purposes.
You're completely missing the point, of course, which is that you are
going to be stuffing your class files into a compressed jar either
way, and even large savings in class file size from symbol stripping
may translate into only small-to-modest shrinkage of said jar.
> The main function of Java obfuscators is to mangle names. And that
> has zero impact on runtime performance.
And approximately zero impact on file sizes, unless it actually makes
them larger by using really long and mangled names.
Flow obfuscation likewise doesn't improve anything file-size-wise.
Only debug data stripping might, and can be done without an
obfuscator.
Name mangling and flow obfuscation both harm compressibility as well,
by adding entropy in various places.
P.S. None of the nasty things that you have implied about me are at
all true.
nebul...@gmail.com
> Joshua Cranmer wrote:
> > [fragment of Joshua's unprovoked attack post deleted]
None of the nasty things that Joshua has implied about me are at all
true.
> I've maintained some code whose original authors must have subscribed to that
> philosophy proactively. Running an obfuscator over their code would be redundant.
I think it's likely that we all have. :P
> What's worse, this also holds true for wizard-generated JSF code I've seen
> come out of the Rational Application Developer (RAD) IDE, whose maker shall
> remain nameless lest they take not kindly to being mentioned by name.
Code generated by such tools is more object code than source code; the
real source code is whatever the input is to the automatic code-
generator. Similarly with parser generators and the like. It's
expected that you maintain the code-generator's input, not its output,
the same as you'd maintain your .java files, not your .class files.
> I can see a competitive advantage to letting the opposition have some source
> code unchanged.
I can see a bigger advantage to not assuming an "us vs. them"
adversarial attitude in the first place. So can a lot of others, as
evidenced by the enormous success of sites like Sourceforge. Of
course, that first sentence can also be applied to certain people's
attitudes in this newsgroup, particularly those who cannot seem to
avoid responding with veiled insults and general nastiness even to a
civil and on-topic post my me. Such individuals as completely lack any
self-control in this area should obviously killfile me, but some of
them clearly have not.
Owen Jacobson
> nebulou...@gmail.com wrote:
> > On Jan 7, 5:46 pm, Joshua Cranmer <Pidgeo...@verizon.invalid> wrote:
> >> [unprovoked attack post deleted]
>
> What attack? What in Joshua's message was an attack? Unless now
> disagreement can be seen as an attack?
This is not a new state of affairs. Please do not feed the trolls.
John W. Kennedy
"nebulous99" (he uses several aliases) is literally insane; this is his
standard response to anyone who points out that he's made a mistake --
any mistake. PLONK him and move on.
--
John W. Kennedy
A proud member of the reality-based community.
Joe Attardi
> "nebulous99" (he uses several aliases) is literally insane; this is his
> standard response to anyone who points out that he's made a mistake --
> any mistake. PLONK him and move on.
Other aliases are twisted0n3, twerpinator, bbound, and probably some
others too - all aliases for Paul Derbyshire, a 31 year old Canadian*
who has nothing better to do than pick fights.
*Source:
http://tinyurl.com/yooc6w (MySpace search for one of his email addresses
he posts under, twist...@gmail.com)
http://www.openoffice.org/servlets/ReadMsg?list=users&msgNo=117339&raw=true
(OpenOffice email archive showing his name, Paul Derbyshire, with a
Reply-To address of twist...@gmail.com
Why go through such trouble to identify this troll? Because Paul
Derbyshire has a history of going around usenet causing trouble. Here's
the hilarious but true Paul Derbyshire FAQ:
http://groups.google.com/group/carleton.general/browse_thread/thread/107c44a6274df3a6/27478594699fd22e?lnk=st&q=paul+derbyshire+cabal#27478594699fd22e
Don't worry though Paul, I'm not from the Cabal!
bbo...@gmail.com
> nebulou...@gmail.com wrote:
> > On Jan 7, 5:46 pm, Joshua Cranmer <Pidgeo...@verizon.invalid> wrote:
> >> [unprovoked attack post deleted]
>
> What attack? What in Joshua's message was an attack?
He implied a rather nasty accusation in his post. That accusation is
of course false.
> > You're wrong. None of the nasty things that you have implied about me
> > are at all true.
>
> Isn't it you who goes off on people for saying flat out, "You're wrong"
> - but apparently it's OK for you to say?
I go off on people for saying "You're wrong" to me when I'm not. It's
quite OK for me to say "You're wrong" to someone else when they are.
And there is nothing inconsistent in this.
> [remainder of unprovoked attack post deleted]
bbo...@gmail.com
> [insult deleted]
None of the nasty things that you have said or implied about me are at
all true.
bbo...@gmail.com
> [multiple vicious insults deleted]
None of the nasty things that you have said or implied about me are at
all true.
bbo...@gmail.com
> John W. Kennedy wrote:
> > [insult deleted]
>
> Other aliases are twisted0n3, twerpinator, bbound
True.
> all aliases for Paul Derbyshire
False.
> [numerous nasty insults and other assorted BS deleted]
None of the nasty things that you have said or implied about me are at
all true.