ProGuard Java Optimizer and Obfuscator

Well.. the simplest one has to be a class full of constants, with no
subclasses.

This could be combined with pretty much any other class, if the methods
don't clash.

In fact, classes like this could probably be merged at least with each
other first.

Ok, so it was indeed me who failed to see the complexities :)

Among the alternatives for J2ME developers are the use of a preprocessor
and writing /really/ long classes. None is attractive.

Do you have any idea of what can be done?
Any restricted form of class merging that could be safe to use under a
small set of limitation?

ProGuard 4.0 has changed a lot internally, so the extensions to ProGuard
3.7 will not be compatible.

I understand the use, but I can see many potential hurdles:

- How to detect reliably that exactly one instance is created?
(multiple constructors, chained constructors, exceptions,...).
- What if the field is volatile?
- What if the code synchronizes on instances of class A or
class B? How to detect this 100% reliably?
- Even if only one class A has only one field of type B,
class A will probably have code that uses it, passing it around
in local variables and even method parameters. What if the
field is added to a vector, which is then passed on?
(escape analysis)
- What if one instance of class A passes its instance of class B
to another instance of class A?
- What if one instance of class A retrieves the instance of
class B from another instance of class A?

Some problems are easy to solve, but quite a few are already difficult to
detect. If thinking about it for a few minutes brings up these pitfalls,
surely much more will pop up later on. I estimate that the other type of
class merging is simpler to handle automatically.

thanks for the references. does Torbjorn Soderstedt's extension is
supposed to work on the latest ProGuard?

it could be that class merging is indeed more complex than how i perceive
it. however, in some specific scenarios it appears to be quite simple, and
tremendously useful.

specifically, when coding for J2ME, it is necessary to limit the number of
classes in order to prevent jar size bloat. fewer classes leads to
difficulty in readability and maintainability of the code. this pain
intensifies as the application grows.

suppose we had limited class merging, only for all the singletons (or
classes that have up to one instance). not "a class that is referenced by a
field is inlined" but "a class that is ONLY referenced by ONLY ONE field IN
THE ENTIRE APP is inlined". this restricted merging appears to be simpler
to implement, and could be a great relief to a very painful problem.

or do i fail to see the complexities?

Class merging has already been suggested several times before (e.g.,
requests #1481773 and #1517957). This is also what the commercial tool
seems to do, judging by the web page. Torbjorn Soderstedt has written an
implementation for an older version of ProGuard.

What you suggest is a different and more complex variant, where a class
that is referenced by a field is inlined. I have thought about it before,
and it's a very interesting idea, but the constraints are pretty complex,
and not straightforward to implement. Please don't hold your breath for
it...