Idea: make compiled Scala programs independent of Scala library

On 19/10/2011 14:12, igorrumiha wrote:
> I just had a silly idea: equip the Scala compiler with proguard-like
> functionality that will make it emit bytecode not only for the program
> you are compiling but also for all its dependencies from the Scala
> library. That would enable Scala programs to run "standalone" on the
> JVM, similar to the Mirah language.
> Does this make sense? Maybe this has been discussed before but I
> couldn't find any references to such a topic. I'm not really familiar
> with the Scala compiler's architecture but I assume that it might be
> feasible to write a compiler plugin that can achieve this.

I am not sure I fully understood your idea.
It looks like you can achieve something similar with external tools, like ProGuard,
precisely, and making a fat jar including both your classes and those needed to run them.
Why would you need a compiler plugin for that? What I am missing?

On Thu, Oct 20, 2011 at 10:33, Philippe Lhoste wrote:
> I am not sure I fully understood your idea.
> It looks like you can achieve something similar with external tools, like
> ProGuard, precisely, and making a fat jar including both your classes and
> those needed to run them.
> Why would you need a compiler plugin for that? What I am missing?
>

Well, the motivation for this is mostly convenience. An external tool
like ProGuard must resort to bytecode analysis and building the call
graph to decide what goes in the resulting jar. This makes it
impossible to do the right thing in some environments. For instance,
on the Android platform your Activity classes are usually never used
directly from your code. Instead, they are instantiated by the
runtime. Without additional configuration ProGuard throws these
classes out (from its point of view nobody is using them) making your
application unusable. So, being able to do the right thing without
additional work seems like a win to me.

One other point is that ProGuard seems to have problems with Scala
objects. It throws hundreds of warnings on each invocation, like this:

Maybe this is program field 'scala.xml.Elem$ { scala.xml.Elem$ MODULE$; }'

I don't really know what to do with all these. I'm actually never
certain that my application will work correctly after I run it through
ProGuard. I think that the Scala compiler is in a much better position
to have quality information on what classes should end up in the
target directory. Of course, this approach is not without limitations,
things like on-demand class loading (Class.forName etc.) would need to
be handled separately (manually?) but I doubt there are many such
cases in the Scala library.

As a user of Scala on Android, I understand exactly what you are
saying. I would love it if I didn't have to use Proguard just to use
Scala. But, even if this feature were in Scala, you could still need
to use Proguard to strip down any of the external libraries that you
utilize.

Maybe if there were some Scala specific support for proguard? Maybe
there is some way for Scala to help tools like Proguard to the right
thing, and make it easier for users to configure?

JamesJ

On Thu, Oct 20, 2011 at 5:31 AM, Igor Rumiha wrote:
> On Thu, Oct 20, 2011 at 10:33, Philippe Lhoste wrote:
>> I am not sure I fully understood your idea.
>> It looks like you can achieve something similar with external tools, like
>> ProGuard, precisely, and making a fat jar including both your classes and
>> those needed to run them.
>> Why would you need a compiler plugin for that? What I am missing?
>>
>
> Well, the motivation for this is mostly convenience. An external tool
> like ProGuard must resort to bytecode analysis and building the call
> graph to decide what goes in the resulting jar. This makes it
> impossible to do the right thing in some environments. For instance,
> on the Android platform your Activity classes are usually never used
> directly from your code. Instead, they are instantiated by the
> runtime. Without additional configuration ProGuard throws these
> classes out (from its point of view nobody is using them) making your
> application unusable. So, being able to do the right thing without
> additional work seems like a win to me.
>
> One other point is that ProGuard seems to have problems with Scala
> objects. It throws hundreds of warnings on each invocation, like this:
>
> Maybe this is program field 'scala.xml.Elem$ { scala.xml.Elem$ MODULE$; }'
>
> I don't really know what to do with all these. I'm actually never
> certain that my application will work correctly after I run it through
> ProGuard. I think that the Scala compiler is in a much better position
> to have quality information on what classes should end up in the
> target directory. Of course, this approach is not without limitations,
> things like on-demand class loading (Class.forName etc.) would need to
> be handled separately (manually?) but I doubt there are many such
> cases in the Scala library.
>
>
> --
> Igor
>