Compile: % javac "sourceFile"
Run: % java "classFile"

Notes:

• "sourceFile" is a file that ends with the suffix ".java". Every Java source file must be given the name of the class defined in that source file. For example, if the Java source file began:

        package uoregon.cs.cis425.prog1;
  
        public class Foo extends Object implements Comparable
        {
          private Goo g1, g2;
  
  	public Foo(Goo g1, Goo g2){...}
  
  	...
        }
  

  Then the sourceFile would have to be called "Foo.java" and be located in the directory "./uoregon/cs/cis425/prog1/". Don't worry about packages, as you probably won't have to use them for this course. They are interesting and sometimes helpful for organizing your work, though.
• The Java compiler (javac) has a feature that, given a single source file to compile, it will compile all other source files referred to in the given source file (sort of a built in 'make' functionality). So, if you typed:

     % javac Foo.java 
  

  for the above class definition, the Java compiler would also compile Goo.java if no Goo.class file existed. You will likely have a single directory for each project that contains all the .java and .class files for that project. When you want to compile the project, just type:

     % javac *.java
  

• A Java 'runnable' application should have the following form:

        public class MainApp
        {
          public static void main(String[] argv)
  	{
  	  ...
  	}
        }
  

  The important part here is the "public static void main(String[] argv)". This has to be exactly as above since Java expects that type signature for the entry function for the class. When the program is invoked by: % java MainApp arg1 arg2 the Java Virtual Machine (java) calls MainApp.main(["arg1", "arg2"]). That is, the JVM looks for a static method called main and passes it the command-line arguments as an array of Java Strings.

Compile C source: % cc -o "outputFile" "sourceFile" or % gcc -o "outputFile" "sourceFile"
Compile C++ source: % CC -o "outputFile" "sourceFile" or % g++ -o "outputFile" "sourceFile"
Run: "outputFile"

Notes:

• cc is the Solaris c compiler, CC (notice capitals) is the Solaris C++ compiler.
• gcc is the GNU c compiler, g++ is the GNU C++ compiler.
• You may use either the Solaris or GNU compiler, but some code may work on one but not on the other. Notice that cc and gcc only compile C source (no classes or objects). Use CC or g++ if you have classes and objects.
• If you leave the -o "outputFile" option off, the compiler will generally create an executable called "a.out" (or a.exe in Windows).
• C source files usually end in '.c' and C++ source files generally end in '.c', '.C', '.cc', or '.cpp'. However, unlike the Java compiler, C/C++ compilers don't really care what you name the source file.
• Once you run the C/C++ compiler, you have created an executable binary file that can be run just by typing its name. For example, running:

      % g++ -o fooRunnable Foo.C
  

  will generate a file called "fooRunnable" that you can execute by typing:

      % fooRunnable
  

  Although you may have to type:

      % ./fooRunnable
  

  depending on how your PATH variable is set.
• C/C++ programs must have an entry point declared as:

      int main(int argc, char *argv[])
      {
        ...
      }
  

  It is a convention that main returns 0 on successful termination or some non-zero error code (-1, etc) on unsuccessful termination. You can also use declare main to have a void return, but you may get a warning.
• Command-line arguments are given the same way as in Java, but C/C++ uses a pointer to a string of characters instead of a String object type. So, the argv parameter to main is an argument vector, i.e., is an array of "strings" (pointers to char). Just recall that C/C++ uses character strings (arrays of char or type equivalently pointers to char) rather than String objects. There is a string class in the C++ standard library, but it is not used for the command line arguments. Also, there is no such thing as array.length in C/C++. The length of an array must be passed to methods as in the following example, or a sentinel value might be used in the array to indicate the end of the valid element values.

      int array_sum(int *array, int n)
      {
        int sum = 0;
  
        for(int i=0; i'<'n i++)
         sum += array[i];
      }
  

• C++ allows interfaces and implementations to be in separate files. By convention, so-called header files are used to do this. These are somewhat like interfaces in Java. Header files conventionally end in .h and might look like:

      #ifndef _FOO_H_
      #define _FOO_H_
      
      class Foo
      {
        public:
          Foo(int v);
  	int getVal() const;
  	void setVal(int val);
        private:
          int value;
      };
      #endif
  

  (Actually a "header file" is just any C/C++ code to be included in the program compilation and the "#incude" directive just means to compile the contents of the named file as if it were part of the source file. Everything starting with "#" is a preprocessor directive. The pre-processor is used (and abused) for all types of things, the most common being the inclusion of class/struct definitions or function declarations used by the implementation.)
  In the above example, the class definition file should be named Foo.h. This file is then included in any file that needs to know what the Foo class has to offer as well as the implementation of the Foo methods themselves. It may be a complete definition with all methods defined, but it may be more like an interface, with the method implementations specified outside of the class definition. In this case to implement the class, you might write a new file called Foo.C:

      #include "Foo.h"
  
      Foo::Foo(int v){ value = v; }
  
      int Foo::getVal() const { return value; }
  
      void Foo::setVal(int val){ value = val }
  

  Notice the syntax of the methods: they are prefixed with "Foo::", the scope resolution operator, to indicate that they are methods of the class Foo. The compiler will check that these method signatures are indeed in the class definition. But otherwise, the code in the method body is treated just as if it were within the class definition (as in Java) and so can refer to any variables or methods in the class Foo.