jdn would like dasho to add an option to allow a specific classname
specification prefix. For example, instead of aa.class, it would
be jsse_aa.class.

This bug will serve as a reminder.

bradford.wetmore@eng 2001-02-28


Hi Paul/Bill. I'm following up on some email that was exchanged
earlier between Maxine and Paul (Feb/March 2001), and Bill Leach and I
(April/May 2001). I'm finally up to speed on Dasho 2.2, so I can
finally write about the experiences we had.

> Paul Tyma wrote:
>
>> Maxine wrote:

>> 1. We need a way added for us to pass in a class name prefix
>> for use when obfuscated class names are generated.
>>
>> We need this because we use Dash-O's option to generate
>> the name-obfuscated classes in their original package name
>> spaces but we want to prevent name clashes in the case that
>> someone else does the same thing with the same 3rd-party
>> toolkit that we use (in our case, Crypto-J from RSA).
>> Instead of Dash-O generating names like "a.class" we need
>> to put a prefix in front like "com_sun_" so the name is
>> generated like "com_sun_a.class".

> I think since Dasho 1.0 you could specify "RenamePrefix:" in the .dop file.
> It will do exactly as you require as in:
>
> -RenamePrefix:
> com_sun_
>
> In fact, if you trail your prefix with a slash, DashO will generate
> a package for it. So:
>
> -RenamePrefix:
> com_sun/

> will actually put your classes all in that package.

and then:

> Bill Leach wrote:
>
>> Brad Wetmore wrote:
>>
>> You apparently cannot specify both "Maintain Package Hierarchy" and
>> "Rename Classes-Prefix". What happens is that all the classes get
>> placed into the default package, or package specified by the prefix
>> field:
>>
>> prefix/*

> You are correct about renaming. The current version of Dasho won't let
> you specify "Maintain Package Hierarchy" along with a renaming prefix.
> You can only induce package membership with the renaming prefix on a
> global basis. If you tell me why you need to do this I may be able to
> suggest an alternative.

Here's our situation. We have contracted with a vendor, and are
modifying their library, and shipping that modified code in our jar
file. However, an end user may have already installed the original jar
into the JRE. If such a scenario were to occur, both jars would
contain the com.foo.bar.fubar.class. If that's the case, depending on
load ordering, either our modified code or theirs will get loaded.
We want to make sure the modified code loads with our jar,
and their original code when called from the original jar.

If we use the prefix as suggested above, then it lumps all renamed
classes from multiple original packages into that one package with the
given prefix name. For many classes, including ours, this breaks
things that depend on package private access. All these classes are
now lumped into one package which gives inappropriate package access
between the classes lumped into that package and also changes package
accesses between the renamed classes and any non-renamed classes from
their original packages. In order to "fix" this, Dash-O changes all the
access modifiers in the classes to be public by default. This is
obviously not good for our security sensitive code. If we prevent this
by using the (previously) undocumented NOMAKEPUBLIC option then it
leaves the original access modifiers in place but things don't work
because of illegal access exceptions on package-level access since the
classes got moved to different packages.

So, what we really need is a way have maintain package hierarchy
together with a named prefix so that renamed classes are generated into
the original package but with a prefix on the renamed class like
"com.foo.bar.SUNWJSSE_a.class" and "com.foo.bar.SUNWJSSE_b.class"
instead of just "com.foo.bar.a.class and "com.foo.bar.b.class" which it
otherwise wants to do. That way we can leave the original access
modifiers alone since we aren't changing packages, we get to use
package private access modes, files get renamed and obscured, and
renamed classes resulting from multiple users obscuring common bundled
class libraries in one application will not conflict.

Since we do have source to the vendor's library, we could
go through and change it by hand, but each update we get would
have to be similarly updated. Ugh...

Brad

bradford.wetmore@eng 2001-05-21