Little remarks:

The first constructor of Node assigns null to fields, but it is unnecessary, as it is the default value. Idem for the BTree constructor. Unless you see that as a kind of documentation for the unexperimented...
Just FYI, you can also write either:
Node(int v) { val = v; }
Node(int v, Node l, Node r) { this(v); left = l; right = r; }
or
Node(int v) { this(v, null, null); }
Node(int v, Node l, Node r) { val = v; left = l; right = r; }
This allows to keep the constructors in synch. Trivial here, more useful with more complex constructors. I mention this because some people doesn't know the trick of calling this() in a constructor.

makeEmpty() is often called clear() in the Java APIs. Just FYI as you might find your name clearer (no pun intended...).

return new Node(in, null, null);
You can just call Node(in): you define a nice constructor, just use it.

Now to your request. A way to do it is:

1.   boolean insert(int in) {
2.     Node r = insert(in, root);
3.     if (r == null) return false;
   
4.     root = r;
   
5.     return true;
   
6.   }
7.   Node insert(int in, Node curr) {
8.     if (curr == null) return new Node(in);
9.     if (in < curr.val) curr.left = insert(in, curr.left);
10.     else if (in > curr.val) curr.right = insert(in, curr.right);
11.     else curr = null; // Found, nothing to insert, indicate it
    
12.     return curr;
13.   }

Last note: I suppose you do this for learning purpose (which is always a good idea). Because Java already has efficient Tree collections.

I don't really understand how this() works. I put in null all of those times because I am not used to working with it and wanted to be certain it would do what I expected. I did simplify the constructor a bit below, but I feel dumb using this() if I don't understand it.

Ah, indeed, the insert() code needed a little improvement. I show it below. I paste the whole code, as I made some debug traces which might interest you...

1. BTree tree = new BTree();
2.  
3. void setup() {
4.   size(400, 400);
5.   tree.insert(4);
6.   tree.insert(2);
7.   tree.insert(1);
8.   tree.insert(3);
9.   tree.insert(6);
10.   tree.insert(5);
11.   tree.insert(7);
12.   println("Contains 1: " + tree.contains(1)); //<>//
13.   println(tree.root);
14.   println(tree.insert(1));
15.   println("Contains 1: " + tree.contains(1));
16.   tree.printTree();
17.   exit();
18. }
19.  
20. void draw() {
21. }
22. class BTree {
23.   Node root;
24.   
25.   void clear() {
26.     root = null;
27.   }
28.  
29.   boolean contains(int in) {
30.     return contains(in, root);
31.   }
32.   boolean contains(int in, Node curr) {
33.     println("contains: " + in + " - " + curr);
34.     if (curr == null) return false;
35.     if (in < curr.val) return contains(in, curr.left);
36.     else if (in > curr.val) return contains(in, curr.right);
37.     else return true;
38.   }
39.  
40.   int findMax() {
41.     if (isEmpty()) {
42.       println("The tree was empty! Returning 0 to avoid an error");
43.       return 0;
44.     }
45.     else return findMax(root).val;
46.   }
47.   Node findMax(Node curr) {
48.     if (curr == null) return null;
49.     else if (curr.right == null) return curr;
50.     return findMax(curr.right);
51.   }
52.  
53.   int findMin() {
54.     if (isEmpty()) {
55.       println("The tree was empty! Returning 0 to avoid an error");
56.       return 0;
57.     }
58.     else return findMin(root).val;
59.   }
60.   Node findMin(Node curr) {
61.     if (curr == null) return null;
62.     else if (curr.left == null) return curr;
63.     return findMin(curr.left);
64.   }
65.   
66.   int treeHeight() {
67.     return treeHeight(root);
68.   }
69.   int treeHeight(Node curr) {
70.     if (curr == null) return -1;
71.     else return 1+max(treeHeight(curr.left), treeHeight(curr.right));
72.   }
73.  
74.   boolean isEmpty() {
75.     return root == null;
76.   }
77.  
78.   boolean insert(int in) {
79.     Node r = insert(in, root);
80.     println("inserted: " + in + " - " + r);
81.     if (r == null) return false;
82.     root = r;
83.     return true;
84.   }
85.   Node insert(int in, Node curr) {
86.     println("insert: " + in + " - " + curr);
87.     if (curr == null) return new Node(in);
88.     Node res = null;
89.     if (in < curr.val)
90.     {
91.       res = insert(in, curr.left);
92.       if (res != null)
93.       {
94.         curr.left = res;
95.       }
96.     }
97.     else if (in > curr.val)
98.     {
99.       res = insert(in, curr.right);
100.       if (res != null)
101.       {
102.         curr.right = res;
103.       }
104.     }
105.     return res == null ? null : curr;
106.   }
107.  
108.   void printTree() {
109.     if (isEmpty()) println("The tree is empty");
110.     else printTree(root);
111.   }
112.   void printTree(Node curr) {
113.     if (curr != null) {
114.       printTree(curr.left);
115.       println(curr.val);
116.       printTree(curr.right);
117.     }
118.   }
119.  
120.   void remove(int in) {
121.     root = remove(in, root);
122.   }
123.   Node remove(int in, Node curr) {
124.     if (curr == null) return curr;
125.     if (in < curr.val) curr.left = remove(in, curr.left);
126.     else if (in > curr.val) curr.right = remove(in, curr.right);
127.     else if (curr.left != null && curr.right != null) {
128.       curr.val = findMin(curr.right).val;
129.       curr.right = remove(curr.val, curr.right);
130.     }
131.     else curr = (curr.left != null)?curr.left:curr.right;
132.     return curr;
133.   }
134. }
135.  
136. class Node {
137.   int val;
138.   Node left;
139.   Node right;
140.   Node(int v) {
141.     val = v;
142.   }
143.   Node(int v, Node l, Node r) {
144.     val = v;
145.     left = l;
146.     right = r;
147.   }
148.   public String toString() {
149.     if (left == null && right == null) return "N(" + val + ")";
150.     return "N(" + val + ", " + left + ", " + right + ")";
151.   }
152. }

Thanks :)

toString() is called automatically by some methods like println(), or when we do string concatenation with an object, etc.
I added public out of habit, since I override a public method, but it might not be necessary here. It is a bit long to explain here and now, sorry. Search public, private, protected in Java for more information.

Hey asimes!

I was also curious on how a Processing code becomes a valid Java one.
Its secret is the usage of a preprocessor parsing before calling JDK for actual compilation.

You can check that out yourself by using Export Applet <Ctrl+E> from Processing IDE, and reading the generated .java file:

• The whole processing code is wrapped up and becomes a class which extends PApplet.
• Declarations which don't specify their access level is prefixed by public!
• The pseudo data-type color is replaced by a single int.
• Same happens to the Processing "web-color" codes, like #CA00FE. Their # parts replaced by 0xff. So #CA00FE becomes 0xffCA00FE, a hexadecimal integer literal.
• And finally, the "main" method is appended at the end of our wrapped up class.

I had wondered that for a long time, thanks. I've shown Processing code to Java people and they thought the structure was too different from Java, now that makes more sense.

If we are not required to type public, we shouldn't for void either! 

Well, I'd say that learning what void is (and its replacements for returnables) is significantly more complicated than public, but who knows why they made that choice.

Processing already prefixes -> void draw() { } w/ public void draw() { }.
I don't get why prefixing w/ void as well would be so complicated! 
If no access scope is specified, assume it is public.
Likewise, if no returning type is set, assume it is void! 

If no access scope is specified, assume it is public.

In Processing all methods and variables are public (because there is effectively just one top-level class, any classes declared in the sketch would be inner-classes and also public throughout) so it is a safe assumption if public is not there.

It is also simple to identify variable declarations because they have the format

data-type name;

it is also easy to identify methods because they have the format

data-type name(optional parameters)

NOTE: This format makes it easy for Processing to know where to put public when the programmer hasn't.

Although you are comfortable with the idea of data types e.g. int, float, boolean etc. you should be aware that Java (and C++) also treats void as a data type (it means ' nothing')

So

void setup(){...

can be identified as a method signature simply because it has the format

data-type name(optional parameters)

removing the 'void' would make it much harder for Processing to recognise this as a method.

Likewise, if no returning type is set, assume it is void!

Possible but the only way to find out is to search the code inside the method - a lot of work!

As you do more and more programming especially when start creating your own top-level classes much of what I have said will become clearer. I promise

Wow, thx quarks! Forgotten about that, in declaration of functions/methods, if no "adjectives" would prefix them, they would get mistaken by method/function calling instead!
And the role of void would be so that there is something in front of them, so they can be recognized as such.
Perhaps the curly bracers after the parenthesis would serve as a "signature" for declaration, instead of simple calling up? 

All this is possible (and way out of topic for this thread...) but honestly, that's would be lot of work to avoid typing five characters, and it would be more confusing than helping.

Pure Java has a very confusing & threatening huge code declarations, with things like -> protected static final int myMethod (int x, float calc, myClass[]) {}.
A casual programmer would run away after thinking they'd have to learn such swearings! 

Data-type declarations like int, float, String are easy to grasp and reasoning w/ beginners why they're needed.
It's not so true for the other Java's eccentricities!

It was a wise move for Processing to have an auto public declaration; besides also sparing us from wrapping the code as a class and that static main method!
I was just thinking an auto void would make Processing even more appealing for new-comers.
setup() {} & draw() {} look so much cleaner w/o void!

I agree, it would be a little easier, I remember not understanding what void meant for a long time when I started Processing, I just knew I had to put it to not get an error. On the other hand if I hadn't gotten used to it going to plain Java would have been even harder. I wonder how many Processing users try plain Java eventually though.