Using this class, you can simplify the addActionListener calls like this:

button_two.addActionListener(new NumberActionListener("2"));

On closer look, I see that the action listeners of the operators do almost the same thing as the number buttons, but using some padding with space.
You could improve on the NumberActionListener to handle that case too.

Find a formula to replace hardcoded numbers

The positioning of the buttons clearly follows some kind of logic,
but the values are hardcoded, for example:

As it is, this is a maintenance nightmare.
If you want to resize the buttons,
or increase padding in between,
you'll have to recalculate and change in many places.
It would be better to come up with a formula,
and position these buttons using a loop.

The main method should really just create an instance of your application, not contain all logic. In Java it is typical to extend JFrame and add all the buttons etc in the constructor. This gets rid of the nasty static variables.

Rather than setting the bounds of all the buttons directly it's better to use a LayoutManager of some sort. See the visual guide for some ideas.

A lot of your action listeners do the same thing, adding text to your textfield. You could factor out the common bits.

Calling out to javascript to do your maths is a bit weird. I'd expect someone to actually write code to do the maths.

\$\begingroup\$typical to extend JFrame? Yes. Recommended to do so? Actually not. In most cases (can't think of any exceptions right now), it is better to use JFrame than extend it. Goes along with "prefer composition over inheritance".\$\endgroup\$
– Simon ForsbergApr 30 '15 at 20:53

Layouts

I agree with @Simon's comment to use a layout manager, so that you don't need to use hard-coded numbers for positioning with the added benefit of freely resizing your application without worrying about alignment.

Dealing with repetition

Another way of getting the button text that triggered the ActionListener is the following:

Going this way means you don't really need to re-specify your buttons' text and the values you want to store differently. If you happen to be on Java 8, the functional interfaces feature mean that your ActionListener need not be more than:

Calculation (and validation)

I think it's fine to get a ScriptEngine and then eval() the mathematical expression, but this two-step process is not as instantaneous. Therefore, I will prefer to store engine as a class-level field, and pressing the = button will only perform the evaluation. You may want to do a dummy evaluation first so that the very first calculation performed appears faster.

As you should have assessed by now, providing a reduced set of mathematical operators and doing calculations are easy, but validating and accepting a simple mathematical expression... not so much. Shameless plug alert: my take on a GUI calculator attempts to resolve that by enabling or disabling buttons depending on the existing input, so you may want to consider something like that. In that case, you wouldn't have to be concerned about a user entering + - * / =.

Should ScriptEngine throw an Exception related to your text field (e.g. when users absent-mindedly press the next expression to give you the following 'garbage' input: 1 + 2 = 34 + 5<= error, do not compute>), it will be more helpful to display it within your GUI, instead of just exception.printStackTrace(). This prepares you for dealing with Exceptions properly in the future, too.

Memorization

This is where you run into two usability-breaking problems:

You memorize the entire text field instead of the previous result

You don't have two separate buttons to separate the features of clearing the screen or the memory

Effectively, this means your memorization is broken as I can't reuse my past result! In order to enter a new mathematical expression to use the (R)ecall feature, I have to press (C)lear... which clears the memory too. Without fixing this (by implementing point 2), it's as good as not providing any memorization at all. :(

One small bit of code improvement suggestion, you don't need an else if (negation-of-if-boolean-condition) following an if statement. That if statement you have for your (M)emory button should be just: