DrJava

It also contains bookkeeping classes, such as {@link edu.rice.cs.drjava.Version}, which holds the version number information, and {@link edu.rice.cs.drjava.CodeStatus}, which indicates whether the current build is Stable or Development. These classes are automatically generated by the build process and should not be manually modified.

GlobalModel's Role

The GlobalModel is the central point of DrJava, coordinating all components and communicating with the user interface.

To maintain state, the GlobalModel keeps a list of the OpenDefinitionsDocuments, each of which is responsible for its own DefinitionsDocument object and document specific actions on that object, such as saving and compiling.

The GlobalModel also provides a set of public methods which allow it to communicate with the user interface. This gives the ui package access to the OpenDefinitionsDocuments, compiler, console, and interactions code.

To keep the user interface up-to-date, the GlobalModel fires events to all GlobalModelListeners which have registered with it. Events are fired after actions which can affect the user interface, such as the opening, saving, and closing of files, or the starting and ending of compilation or interaction.

Subpackages

• The compiler package provides an interface between the model and the available compilers, allowing DrJava to compile documents and maintain any errors produced as a result.
• The definitions package provides the model of the documents and editor kit, as well as the reducedmodel package for lightweight representation of a document for easy parenthesis matching and similar syntactic features.
• The repl package contains the classes used for the Interactions window, allowing the dynamic execution of Java code from within DrJava.

The idea behind this new interface is that the rest of the model should not talk directly to the document cache but rather to an adapter to the cache. For example, in the old implementation, when the OpenDefinitionsDocument needed to get the DefinitionsDocument, the code would look like this:

DefinitionsDocument getDocument() {
  ... 
  return _cache.get(this);
  ...
}

public boolean isModifiedSinceSave() { 
  if(_cache.isDDocInCache(this)){ 
    return getDocument().isModifiedSinceSave();
  }
  else{
    return false; 
  }
}

But now the code looks like this:

DefinitionsDocument getDocument() { 
   ... 
  return _cacheAdapter.getDocument(); 
  ...
}

public boolean isModifiedSinceSave() { 
  if(_cacheAdpater.isReady()){ 
     return getDocument().isModifiedSinceSave(); 
  }
  else{
     return false; 
  }
}

On the inside of the cache, these DCacheAdapters serve as managers for the instances of the DefinitionsDocuments. They are responsible for storing the unique reference to the document. The cache that created it keeps an LRU of these managers/adapters and tells the manager to discard its document if its place in the LRU has expired.

The tree is composed of {@link edu.rice.cs.drjava.model.definitions.indent.IndentRule}s, and asks a series of yes or no questions about the current position before determining the appropriate action. All nodes use helper methods from {@link edu.rice.cs.drjava.model.definitions.DefinitionsDocument} and the {@link edu.rice.cs.drjava.model.definitions.reducedmodel Reduced Model} package for context.

The tree itself is built in the {@link edu.rice.cs.drjava.model.definitions.indent.Indenter} class, where a singleton instance is made available to DefinitionsDocument for using on a single line. An outline of the tree is given below.

• 1. QuestionInsideComment
  
  • 2. Yes: QuestionPrevLineStartsComment
    
    • 3. Yes: QuestionCurrLineEmptyOrEnterPress
      Starting first line of a mutli-line comment
      • 4. Yes (no auto-close): ActionStartPrevLinePlus(" * ")
        Without auto-close comments, we always do the same thing.
      • 42. Yes (auto-close): QuestionFollowedByStar
        
        • 4. Yes: ActionStartPrevLinePlus(" * ")
          We are already inside a comment - no need to close it.
        • 41. No: ActionStartPrevLinePlusMultiline
                    (new String[] { " * \n", " */" }, 0, 3)
          We are starting a new block comment - close it.
      • 5. No: ActionStartPrevLinePlus(" ")
        Revisiting first line of a mutli-line comment
    • 6. No: QuestionPrevLineStartsWith("*")
      
      • 7. Yes: QuestionCurrLineStartsWith("*")
        
        • 8. Yes: ActionStartPrevLinePlus("") (Goto 12)
          Revisiting middle line of a mutli-line comment (with star)
        • 9. No: QuestionCurrLineEmptyOrEnterPress
          
          • 10. Yes: ActionStartPrevLinePlus("* ")
            Starting middle line of a mutli-line comment
          • 11. No: ActionStartPrevLinePlus("") (Goto 12)
            Revisiting middle line of a mutli-line comment (without star)
      • 12. No: ActionStartPrevLinePlus("")
        Following a line with no start in a mutli-line comment
  • 13. No: QuestionBraceIsParenOrBracket
    
    • 14. Yes: QuestionNewParenPhrase
      
      • 15. Yes: ActionBracePlus(" ")
      • 16. No: ActionBracePlus(" " + 1 level)
    • 17. No: QuestionBraceIsCurly
      
      • 18. Yes: QuestionCurrLineStartsWithSkipComments("}")
        
        • 19. Yes: ActionStartStmtOfBracePlus("")
        • 20. No: QuestionStartAfterOpenBrace
          
          • 21. Yes: ActionStartStmtOfBracePlus(1 level) (Goto 36)
          • 22. No: QuestionHasCharPrecedingOpenBrace
            
            • 23. Yes: ActionStartStmtOfBracePlus(1 level) (Goto 36)
            • 24. No: Goto 25.
      • 25. No: QuestionStartingNewStmt
        
        • 26. Yes: QuestionLineContains(":")
          
          • 27. Yes: QuestionExistsCharInStmt("?", ":")
            
            • 28. Yes: ActionStartPrevStmtPlus("", false) (Goto 30)
            • 29. No: ActionStartStmtOfBracePlus(1 level) (Goto 36)
          • 30. No: ActionStartPrevStmtPlus("", true)
        • 31. No: QuestionCurrLineStartsWithSkipComments("{")
          
          • 32. Yes: ActionStartCurrStmtPlus("")
          • 33. No: QuestionLineContains(":")
            
            • 34. Yes: QuestionExistsCharInStmt("?", ":")
              
              • 35. Yes: ActionStartCurrStmtPlus(1 level) (Goto 37)
              • 36. No: ActionStartStmtOfBracePlus(1 level)
            • 37. No: ActionStartCurrStmtPlus(1 level)

This package provides a framework for abstracting platform-specific calls away from the platform-independent DrJava codebase. The main code tree contains platform-independent code to access and execute the platform-specific implementations, which are kept in separate code trees.

The PlatformSupport interface defines the calls which must be supported by all platform implementations. DefaultPlatform provides a platform-independent implementation. For convenience, all platform implementations extend DefaultPlatform, inheriting default implementations for all methods that are not tailored for that platform. PlatformFactory is a factory class which contains all logic for identifying the host platform and instantiating the appropriate PlatformSupport implementation. This is performed statically, and the result is stored as a singleton field for easy access. Client code can access platform-specific calls like so: PlatformFactory.ONLY.method(). PlatformFactory currently differentiates between Windows, Mac OS X, and the default platform. Note that in order to reference a new platform implementation, it must already be compiled and added to the classpath. The current platforms are built with special ant targets which add the class files to platforms.jar in the lib directory.

In order to add a new platform-specific feature to DrJava, you must follow these steps:

1. Add a new method to PlatformSupport. Make sure it is properly documented.
2. Provide a default implementation in DefaultPlatform. Often this will be an empty method body. Document why it does what it does (or doesn't).
3. Privode a platform-specific implementation for the necessary platforms. Platforms which will use the default method do not need to be modified.
4. Write a test case that reveals the platform-specific behavior, or ensures that all platforms produce expected results.
5. Rebuild the modified platform code using the appropriate systems.

Additional Logic

The SingleDisplayModel is a subclass of DefaultGlobalModel, primarily providing the constraint that exactly one document is active at any time. It adds public methods for getting and setting the currently active document to the interface provided by GlobalModel, and fires a corresponding event through the SingleDisplayModelListener class, which is a subclass of GlobalModelListener.

Note that this behavior is not included in the DefaultGlobalModel because the notion of a single active document is specific to this user interface. Alternative GUIs might choose to display multiple documents simultaneously, eliminating the need for this additional constraint. Housing this logic in a subclass of DefaultGlobalModel, rather than in MainFrame itself, allows us to verify through unit tests that only one document can be active.

User Interface

The graphical user interface is implemented in Swing and is coordinated through the MainFrame class. The general layout and primary components of the interface are shown in the image below.

MainFrame

The MainFrame is the JFrame which houses all other components of the GUI. It is solely a means of displaying the state and logic kept within its SingleDisplayModel, and maintains as little state of its own as possible. The MainFrame consists of a JMenuBar containing the menus, current filename, and toolbar buttons, together with a collection of panes for displaying the various components of DrJava. These include a scrollable JList with the OpenDefinitionDocuments, a DefinitionsPane for displaying and editing the source code, and a tabbed pane at the bottom which houses the InteractionsPane, CompilerErrorPanel, and OutputPane.

In addition to setting up the GUI and passing action requests to the model, MainFrame is also responsible for listening to events fired by both the GlobalModel and the document itself, in order to keep the display current.

Other Components

• The primary GUI component outside the MainFrame is the DefinitionsPane, which is a JEditorPane that is tied to a specific OpenDefinitionsDocument in the model. This pane handles all highlighting and text indenting for its document, as well as undoing actions specific to the document.
• The InteractionsPane is held in the tabbed pane at the bottom of the interface and provides the actual interaction with the repl interpreter within the GlobalModel.
• The CompilerErrorPanel is another tab in the tabbed pane, and contains both a JComboBox for selecting the compiler and an ErrorListPane for displaying all the errors from the most recent compilation, sorted by document. The ErrorListPane is an inner class of CompilerErrorPanel, and is responsible for highlighting errors in the list and in the source consistently.
• The OutputPane is the third tab in the tabbed pane, and is simply where System.out and System.err are redirected when DrJava is run.
• The FindReplaceDialog is a separate JDialog which handles the logic and state of finding and replacing text in the code, including highlighting and changing the source position as necessary. Only one FindReplaceDialog exists in the GUI, and it must be notified each time the active document is changed.

This package is a system to allow the invocation and control of a new Java virtual machine. The two JVMs can communicate by using RMI.

To simply invoke a new JVM with no communications links, use the class {@link edu.rice.cs.util.newjvm.ExecJVM}. The rest of this page explains how to use this framework to create a new JVM and set up bidirectional communications using RMI. This system runs a second JVM using the same classpath as the current JVM (by invoking {@link edu.rice.cs.util.newjvm.ExecJVM#runJVMPropagateClassPath}).

1. Create a remote interface that the master JVM will support, extending {@link edu.rice.cs.util.newjvm.MasterRemote}. This interface must specify of the methods that the slave JVM can call on the master JVM. All methods in this interface must be declared to throw {@link java.rmi.RemoteException.}
2. Create a remote interface that the slave JVM will support, extending {@link edu.rice.cs.util.newjvm.SlaveRemote}. This interface must specify of the methods that the master JVM can call on the slave JVM. All methods in this interface must be declared to throw {@link java.rmi.RemoteException.}
3. Create the master JVM implementation, which must extend {@link edu.rice.cs.util.newjvm.AbstractMasterJVM} and implement YourMasterInterface. Note that the super() call must pass to AbstractMasterJVM the fully-qualified class name of the slave JVM implementation.
4. Create the slave JVM implementation, which must implement YourSlaveInterface. Don't forget to implement {@link edu.rice.cs.util.newjvm.SlaveRemote#quit()}, which is called when the main JVM requests the slave to quit, and {@link edu.rice.cs.util.newjvm.SlaveRemote#start(edu.rice.cs.util.newjvm.MasterRemote)}, which is called when the slave JVM is started.

Now you can create an instance of your master JVM class and use its {@link edu.rice.cs.util.newjvm.AbstractMasterJVM#invokeSlave()} method to start the slave JVM.