1. TOOLS FOR DESIGN AND DEVELOPMENT ENVIRONMENTS. Case study - ECLIPSE Lecture notes 5

2. Java Project Configuration Eclipse features of: - enhancing rapid development by Content Assist, code templates, etc - accelerating navigation - learning of unfamiliar code - controlling compilation&building: - automatic - immediate feedback on code changes - immediate feedback on project status are based on correct configuration of the project workspace.

3. Java Project Configuration Goals Configure project source and output folders. Configure dependencies between Java projects. Add libraries to the build path. Create named user libraries composed of related JAR files. Override workspace compiler preferences with project specific settings. Used at: - compilation - build - run time

4. Java Project Configuration Project builder Builds the project from its resources. A simple project has no builders. Java project includes a builder that compiles its resources from source into output folders. Other project types can add relevant builders that apply appropriate compilers or transformation utilities to the files. Project is built automatically by applying the appropriate builder, whenever one of its files is saved. The Java project builder uses Java compiler settings configured in the workspace preferences or overriden in a project.

5. Java Project Configuration Java Build Path Specifies all dependencies from: - other Java projects in the workspace, - Java archive files (*.jar), - folders containing *.class files, required to compile the project. Configurable properties: Source - source and output folders ( can be multiple => to separate source code and unit tests; to accommodate source code created outside Eclipse, etc.) Projects – projects in the workspace whose output folders should be added to the build path Libraries – archive files required Order and Export Order of projects and libraries in: - build path - default runtime path Export – the projects it depends on and (part of) its shared libraries to the projects that depend on it.

6. Java Project Configuration Source and Output folders Java builder automatically -compiles every *.java file in source folder and its subfolders -saves *.class files in output folder -copy non-java file unchanged from source folder in output folder, keeping the hierarchy. Recommendation: Put non-Java files in a regular folder, outside the source tree. Recommendations: -place model and view components of the UI in separate projects to prevent unnecessary coupling -create separate project for Junit test cases (they often need different Java Build Path) Additional facilities: -splitting sources into logically separate projects or source folders without changing the original structure of the application, -adding inclusion and exclusion filters on a source folder. -configuring preexisting code within an Eclipse project.

7. Java Project Configuration Project dependencies A project P1 set as dependency for a project P2 means: -include in build path of P2 all classpath entries marked as “export” of P1 -include in build path of P2 the output folder of P1  available during compiling classes from P2  included in Quick Assist completion list of P2

8. Java Project Configuration Project libraries Library component types: -*.jar file -*.zip file -folder containing *.class files Options: Add JARs – files from the current workspace Allows great portability. Is not always possible or desirable when using libraries from other vendor products. Add external JARs – files on the file system, external to the current workspace The least portable (specifies absolute paths in certain file systems). Add variable – Java classpath variable as the base for external archives Allows great portability (indirection to JARs avoiding local file system paths). Add library – create or select from a list of user libraries Add class folder – folder from the current workspace containing *.class files Native library location – specifies where can be found the native library required for the library to operate.

9. Java Project Configuration Project libraries (continued) For more information in Javadoc hover and Content Assist: -Attach folder or *.jar file containing Java source code for classes in library -Specify Javadoc location – URL or external location containing a folder or *.zip file with Javadoc HTML for classes in the library Access rules Def. Access rule = Ant pattern defined on build classpath entries. Rules: -forbidden  type that match the pattern specified as “forbidden” must not be referenced -discouraged  type that match the pattern specified as “discouraged” should not be referenced -accessible  type that match the pattern specified as “accessible” can be referenced Compiler signals the use of types that match the patterns.

10. Java Project Configuration User library = named collection of *.jar files. Shared User Library Combination of several JARs. Provides a single entry shared by multiple projects. Useful when working with third-party commercial or open-source libraries and with standard APIs. Identified by absolute paths external to Eclipse workspace for the included JAR files. May be located in a vendor product installation directory. Allows more flexibility  recommended when application may be deployed on several different application servers.

11. Java Project Configuration Linked Library Project Hybrid strategy: configure a user library that is also available as linked folder in Eclipse workspace. Created as a simple project in the workspace ( using a linked folder location for the project contents ) to which is linked an external directory containing libraries to be shared. Recommended procedure: -gather all needed libraries in a common folder; -download binary, source, Javadoc, and other related specifications into the same folder; -create a simple “libraries” project in each Eclipse workspace using a linked folder location for the project contents; even multiple projects can share the same reference files; -create user libraries when several JAR files are used in combination; export user library definitions to share them between workspaces; -use the “libraries” project to add other individual JAR files to the build path of Java projects.

12. Java Project Configuration Java Compiler Settings Java Compiler property page (File > Properties > Java Compiler) from the context menu on a created project or the File menu Enable to control the problem messages produced while building the project. The severity of a problem can be set as: -Error -Warning -Ignore It is associated with a specific marker in the generic Problems view. A project can either reuse workspace default settings or use its own custom settings. At any time, it is possible to revert to workspace defaults, by using the button Restore Defaults.

13. Debugging the code Debugging Run a project within the debugger  enables detailed analysis of its control flow and state. Typical operations: -step through the program statement-by-statement -view and modify: -the state of the fields, -method parameters, -local variables values. Eclipse specific enhancements: -customizable debugging facilities -additional workbench views

14. Debugging the code Debug Perspective Views specialized for debugging activities: -Debug – view of running threads and, when suspended, their stack frames -Variables -Expressions -Display -Breakpoints – for managing a list of all breakpoints in the code, set in a specific workspace and spread across several projects. Variables view shows: -fields -local variables -method parameters for the stack frame selected in the Debug view. The stack frame provides the execution context for these variables. Allow evaluate code snippets that - display - inspect - update program state.

15. Debugging the code Breakpoints (can be added in the source code at any time) Suspend execution. Variable and expressions can be inspected. Variable values can be modified. Code can be modified. Execution can either: Resume / Terminate / Step through the program structure by structure Variables, Expressions, and Display views Pop-up windows – used to display or inspect selected expressions within a Java editor during a debug session. Detailed Formatter - defines a customized output string used to display values of any class during debugging ( overrides class’s toString() method ). Hot Code Replace Facilitates experimental development by allowing to make changes to the code in the midst of a debug session without restarting the Java VM. Uses a remote debugger connection.

16. Debugging the code Debugger Debug process is set up in the launch configuration dialog  tabs for specifying -JRE to be used; -command-line arguments, -classpath locations, -environment variables needed to start the application. Other debug configurations for running -Java Applets, -JUnit tests, -a runtime instance of the Eclipse workbench itself are used when debugging plug-ins.

17. Debugging the code Options to control program execution (in the workbench Run menu): Obs. If a breakpoint is encountered while performing a step operation, the execution will suspend at the breakpoint, and the step operation is ended. The most general control: -Resume. Resume execution of a thread until it either ends or encounters a breakpoint. -Suspend. Suspend an executing thread. -Terminate. Terminate the Java VM.

18. Debugging the code Options to control program execution (in the workbench Run menu) (continued): Control behavior of the step commands ( is relative to the stack frame for the selected thread in the Debug view ): -Step Into. Step into the next executed method. Stepping into a method causes the stack frame to grow by one. -Step Over. Finish execution of the current line and suspend on the next executable line. -Step Return. Step out of the current method. Execution resumes until a return statement is executed in the current method. -Run to Line. Resume execution up to the selected line. This is a convenient way to suspend execution at a line without setting a breakpoint. -Use Step Filters. When this command is toggled on, each of the step commands will apply the set of step filters that are defined in the user preferences page Java > Debug > Step. -Filtering. When a step action is invoked, stepping will continue until an unfiltered location is reached or a breakpoint is encountered.

19. Debugging the code Debugger Execution is suspended when either: -the Suspend button on the Debug view toolbar is presses or Run > Suspend from the workbench menu is picked, -it hits the next breakpoint. When an application execution thread is suspended: -Debug view shows one or more stack frames for that thread; A stack frame shows the execution context containing local variables and arguments for the method in that position of the call stack (similar to the stack trace received when a program throws an exception, except that here the thread is suspended during execution). -any stack frame from the call stack in the Debug view can be selected; -Variables view shows fields, local variables, and method parameters for the selected frame. Kinds of progress highlighted steps ( when stepping through a program's execution ): -Current Instruction Pointer contains the statement that will be executed next when the thread resumes. -Debug Call Stack marks the line where the selected stack frame was suspended.

20. Debugging the code Inspecting and displaying state in Display view Expressions view Details pane (at the bottom of Variables view). Inspect  in a pop-up Inspector window ( Inspect option from the context menu ). The Display view serves as a scratch pad for output results. It also provides an output area for results of expressions evaluated in other views. The contents of this view are saved between Eclipse workbench sessions so it can be used to record and save several snippets used during debugging activities. Code snippets The Details pane can also be used to evaluate code snippets. This evaluation occurs within the context of the selected variable, or if no variable is selected, then the selected stack frame context is used. This context determines the value of the identifier this and also determines which other variable names are available within the code snippet. While typing in the Details pane, Content Assist can be invoked. The Display view serves also as a scratch pad for code snippets. Ways to evaluate code snippets in debug views: -Execute. Run the code. -Display. Run the code and display the result. -Inspect. Run the code and show a "live" version of the result, which can be browsed like a variable.

21. Debugging the code Inspecting and displaying state (continued) Expressions view accumulates references to several expressions to be inspected or watched while debugging the code. Inspected expression  field in one of the objects from the execution context  expression selected in the Java Editor. An inspected value might be "live" if it holds an object whose fields are updated as you step through your code. Watch expression -result of an expression that is reevaluated each time a thread is suspended. includes a Details pane for -viewing values of selected fields -evaluating expressions Value shown in a Details pane or the Display view is produced by either: -toString() method of the displayed object. -Detail Formatter.

22. Debugging the code Managing debug session Breakpoints view: -allows to enable or disable breakpoint; -remove one or all breakpoints; -set the number of times a breakpoint must be hit before it causes the application to be suspended. Add Java Exception Breakpoint option - the debugger breaks exactly at the point before the specified exception occurs. Conditional breakpoint: Enable Condition option plus a Java expression that will be evaluated at runtime, using fields or variables available at breakpoint's position in the code. Select to suspend when: -condition is true, -value of condition changes.

23. Debugging the code Managing debug session (continued) Hot code replacement = ability to change code in the midst of a debug session, without stopping and restarting the Java VM. Standard technique in Java VM specifications to facilitate experimental development and to foster trial-and-error coding. Enabled by default when Eclipse is installed. Can be customized using the Java > Debug preferences page. Supported when running with a 1.4.1 or later Java VM, or the IBM J9 VM. There are restrictions on what changes can be hot swapped, depending in part on the support provided by a particular VM. Generally, replacement only works when the signature of existing classes does not change. YES: -add new classes. -change the body of a method. NO: -add or remove fields to existing classes or change their types after those classes are loaded in the VM. -add or remove methods to existing classes or change their signatures (name, parameters, return type, or visibility) after those classes are loaded in the VM. -add or remove inner classes. Obs. This list depends on the VM being used.

24. Debugging the code Managing debug session (continued) Hot code replacement = ability to change code in the midst of a debug session, without stopping and restarting the Java VM. Standard technique in Java VM specifications to facilitate experimental development and to foster trial-and-error coding. Enabled by default when Eclipse is installed. Can be customized using the Java > Debug preferences page. Supported when running with a 1.4.1 or later Java VM, or the IBM J9 VM. There are restrictions on what changes can be hot swapped, depending in part on the support provided by a particular VM. Generally, replacement only works when the signature of existing classes does not change. YES: -add new classes. -change the body of a method. NO: -add or remove fields to existing classes or change their types after those classes are loaded in the VM. -add or remove methods to existing classes or change their signatures (name, parameters, return type, or visibility) after those classes are loaded in the VM. -add or remove inner classes. Obs. This list depends on the VM being used.

25. Debugging the code Remote Java applications Client / server architecture of the debugger allows to: -launch a Java program from a computer on the network so that it will wait for a connection from the debugger -debug it from Eclipse running on the local workstation. The technique for launching the program and connecting the debugger are specific to the JVM. The basic steps are as follows: 1.Build the Java program with available debug information. Attributes are controlled from the Compliance and Classfiles tab of Window > Preferences > Java > Compiler. 2.Install it to the target computer. This involves copying the.class files or JAR files to the appropriate location on the remote computer. 3.Invoke the Java program on the remote computer using the appropriate JVM arguments to specify debug mode and a communication port for the debugger. 4.Start the debugger in Eclipse workbench using a remote launch configuration that specifies the address and port of the remote computer.

26. Debugging the code Remote Java applications (continued) Required settings: Create project at external location Create a new Remote Java Application launcher - configured to provide information about connecting to the application: -project location -connection type ( ex.(standard (Socket Attach) ) -connection properties: -host (IP), -port (number): port used by the JVM for remote debug connections; must be configured in the startup script of the application server on which the application is installed.