A little summary of what this library is for would have been welcome. I scanned quickly some pages to get an idea of what it is for. Looks like a regular Java library, no?

Using Swing (or even AWT) in Processing is generally problematic, with conflict between the drawing thread and the Swing thread. There are some workarounds, like stopping the drawing loop before popping out a Swing dialog (like the file select one), but it is not straightforward.

Alternatively, you can use this library and Processing side-by-side in a classical Java program (Processing sketch inside a frame).

A little summary of what this library is for would have been welcome.

Sorry for the lack of further explanation. That is for a Java's course on YouTube filmed at Stanford University.
It's a framework API similar to Processing.

Looks like a regular Java library, no?

Yup! That's why I've published it at this "Integration and Hardware" sub-forum.

What I want is just some hacks to make it work in Processing's IDE.
No matter opening extra screens/canvas. No need to mix Processing's API w/ ACM's API.

I just wanna run the course's examples in a more familiar IDE for me. 
I know that something like Eclipse or even a command line compilation would work.
Just wanna know whether it's possible. 

" Just wanna know whether it's possible."
In short, I don't think it is possible... But I am rather uninformed about this library, and it is a bold statement anyway, I am sure that somebody, with enough time to work on the challenge, can prove me wrong...
So I would rather say it is not a natural mix, and spending time on this challenge rather than trying to learn or master Eclipse might be a waste of time.
Just my opinion, of course.

I think trying to use the ACM library inside the Processing IDE is more trouble than it's worth, even if it is possible to get it running.  I have just a tiny bit more knowledge of the framework than PhiLho, but in one way it is a competitor to Processing.  UC Santa Cruz uses Processing for their introductory Java programming class(es), and Stanford uses the ACM library.  Both of them simplify Java for new programmers, but one way they do it is by hiding the way the program is controlled (you never actually write the main() method that is used to run your Java program).

GoToLoop, I've seen enough of your code to know that you've got the skill to grow beyond the friendly confines of the Processing IDE and learn a new one like Eclipse (or NetBeans, or IntelliJ).

Well, I've already sipped from Code:Blocks when programming in C. 
But I guess for small "sketches", I prefer Processing's IDE.
Eclipse is indeed very bloated at 1st glance though. 

I've got a substantial progress w/ acm's library now.
While reading Rationale.pdf, by chance I've found a code
which taught how to use acm's library on regular Java.
With little modifications, I've converted it into Processing's. 

Still I need some hacking template to make a more regular approach like that in my post to work in Processing.

import acm.io.*;
import java.awt.*;
import javax.swing.*;

void setup() {
  size(300, 200);
  noLoop();

  new Add2Application();
}

class Add2Application {
  Add2Application() {
    final JFrame frame = new JFrame("Add2Application");
    final IOConsole console = new IOConsole();

    frame.getContentPane().add(BorderLayout.CENTER, console);
    frame.setSize(500, 300);
    frame.show();

    console.println("This program adds two numbers.");

    final int n1 = console.readInt("Enter n1: ");
    final int n2 = console.readInt("Enter n2: ");
    final int total = n1 + n2;

    console.println("The total is " + total + ".");
  }
}

here is one way to bypass the PApplet instantiation.


ACMButton, etc... has to be a nested class (not an inner class).
http://docs.oracle.com/javase/tutorial/java/javaOO/nested.html

1. import acm.program.ConsoleProgram;
2. import javax.swing.JButton;
3. import java.awt.event.ActionEvent;
4. import acm.program.ConsoleProgram;
5. 
   
6. static class ACMButton extends ConsoleProgram {
7.  
8.   void init() {
9.     setFont("Courier-24");
10.     add(new JButton("Hi"), SOUTH);
11.     addActionListeners();
12.   }
13.   void actionPerformed(ActionEvent e) {
14.     if (e.getActionCommand().equals("Hi"))  println("Hello there!");
15.   }
16.  
17. }
18. 
    
19. public static void main(final String args[]) {
20.   println(">> Sketch: "+ new Object(){}.getClass().getEnclosingClass().getSimpleName());
21. 
    
22.   new ACMButton().start();
23. }

that way you can use the PDE more or less as any other java-ide. but i too would recommend to use eclipse for that.

Thx a lot, Thomas! It's worked perfectly
So, isn't there another way to hide Processing's frame otherwise?!

ACMButton, etc... has to be a nested class (not an inner class).

Looking at the resultant .java file after exporting, class ACMButton is still an inner class! 
Also, I've read somewhere that Java doesn't allow more than 1 public top class in the same file!

the top class (enclosing class) is the class that extends PApplet which has the name of the sketch.
this one is public.

so everything you do in processing (PDE) is inside that class( unless you're using .java files in the PDE)
which makes all classes either inner or nested.

when the inner class is "static" it means its a nested class, otherwise its an common inner class.
the main difference is, that nested classes dont need an instance of an enclosing class. inner classes need such an instance but therefore have access to the members of the enclosing class.

... and, inner classes are noticeable slower than nested ones.

Most you said above I already knew. 
What I didn't know is that static inner classes had a different name -> nested. 

And bumping the question again:
Is there any way to hide Processing's frame after it shows up? 

" inner classes are noticeable slower than nested ones"
I was intrigued by this statement. Do you have a reference to back up this information?

I made a simple Caliper test instantiating (in a loop) an inner class (from always the same base class), a nested class and a top-level class in the same compilation unit than the base class (package protected). And calling a (similar) method from each of these classes.
The inner class was slightly faster, but by a non-significant margin.

i cant remember which project it was where i recognized this.

but here's a simple test:

  int iterations = 100000000;
  public void setup() {

    // warmup
    for(int i = 1000000; --i >= 0;){
      new NestedVec(i,i);
      new NestedVec(i,i);
      new InnerVec(i,i);
      new InnerVec(i,i);
    }
    
    System.gc();

    
    runNested();
    runNested();
    runInner();
    runInner();
    runNested();
    runNested();
    runInner();
    runInner();
    
    exit();
  }
  
  
  void runNested(){
    long timer = System.currentTimeMillis();
    for(int i = iterations; --i >= 0;){
      NestedVec v = new NestedVec(i,i);  v = null;
    }
    System.out.println("NestedVec: "+(System.currentTimeMillis()-timer)+" ms");
  }
  
  void runInner(){
    long timer = System.currentTimeMillis();
    for(int i = iterations; --i >= 0;){
      InnerVec v = new InnerVec(i,i);  v = null;
    }
    System.out.println("InnerVec: "+(System.currentTimeMillis()-timer)+" ms");
  }
  
  
  public static class NestedVec{
    public float x, y;
    public NestedVec(int x, int y){
      this.x = x;
      this.y = y;
    }
  }
  
  public class InnerVec{
    public float x, y;
    public InnerVec(int x, int y){
      this.x = x;
      this.y = y;
    }
  }

my timings:
NestedVec: 860 ms
NestedVec: 812 ms
InnerVec: 1250 ms
InnerVec: 1250 ms
NestedVec: 734 ms
NestedVec: 735 ms
InnerVec: 1125 ms
InnerVec: 1172 ms

Rather than: 

for (int i = iterations; --i >= 0;) {

this cleaner look: 

for (int i = iterations; i-- != 0;) {