This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Scala + Project Jigsaw

No replies
Joshua.Suereth
Joined: 2008-09-02,
User offline. Last seen 32 weeks 5 days ago.
Hi Scala Internals!

I've been trying to keep track of the progress of the "Project Jigsaw", or the modularization of Java core.   I wanted to start a discussion here on the concepts that will eventually (hopefully) spark a full up SIP, so we can keep scala in lock-step with Java 7.  From what I can tell so far, Project Jigsaw will have the following impacts on Scala:

  • New Syntax for defining modules (see here for java side):
    • We need some way of defining "module" classes. 
      • The "requires" syntax for specifying dependencies on other modules.  
      • The  "permits" syntax for notions of "no one else can depend on me".
      • The "provides" syntax for notions of "This module also satisfies the needs of users of module X"
      • Promoting "required"/dependency modules to visibility when including this module
      • Specifying versions for modules
    • We meed to support "module" visibility along with public/private
      • Could we use private[moduleName] ?
  • Byte code changes (see here for current jigsaw plans)
    • Support for ACC_MODULE access flags
    • Output the "Module Attribute" of a classfile (telling which module a class belongs to)
    • Output a "module-info.class" and "package-info.class" when creating scala-based modules
  • Compilation changes (see here for javac changes)
    • I recommend a new tool in the toolchain that will take .class files and enforce various aspects to ensure an appropriately built module.  It may also be possible to use whatever tool sun plans to provide in OpenJDK.
    • Support for a "Module Repository" location where scala will look for modules/imports etc.  Sbaz could be upgraded to install versioned-modules into this directory.  Scalac could even become smart enough to auto-magic-ly fill out your ModuleInfo class based on what imports are used throughout the classes.

As an aside, I would like to try to modularize the Scala library itself.  From my experimentation, I've come to the following realizations:

  • The scala packages are mostly very modular.  You can rip out collection, util, io, parsing, etc. fairly easily.  This can also drastically decrease the core footprint depending on usage.
  • scala.Predef includes most of the packages, and therefore needs to be split/modularized
  • Allowing things like "a new collection library" to be a completely new module could allow it to be devleoped/released independently of core scala (as long as no new language features were required).
I'd like to propose finding a method of sneaking "Predef" style objects (or references to them) into every ModuleInfo.class and have the option (when depending on a module) to also include its Predef in your scala files.   I believe this coudl be rather slick AND dangerous.  Therefore it should be easy to turn on/off.


Obviously there's a ton to talk about here, I just wanted to open the discussion and provide my initial thoughts.  There was a point where I was going to try to modularize scala using OSGi (Which is still quite possible to do, and would require similar changes to those above).  However, I think trying to stick closer to Project Jigsaw would  be a better idea at this point.

A large downside to Project-Jigsaw (so far) is that it has no real "extension point" mechanism for modules.  That makes things like "plugins" and "services" that are easy to do in OSGi, rather more difficult.  I'd love to see scala *not* make this mistake.

Look forward to hearing your thoughts.

-Josh



Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland