Playing Card & Deck Class in Java

Naming

private static final String BACK_IMAGE_DIR = ("image/back_image.png");

You call this BACK_IMAGE_DIR which suggests that it is a directory, but it's actually a file path. Just BACK_IMAGE might be a better name.

Are you sure that you want this to be a property of a Card? It seems more common to make all cards in a deck share the same back.

Keep it simple

        if(this.suit.compareTo(card.suit) > 0){
            return 1;
        } else if (this.suit.compareTo(card.suit) < 0){
            return -1;
        } else {
            return 0;
        }

You could write this section more simply as

        return this.suit.compareTo(card.suit);

And this section

    if (rank != other.rank)
        return false;
    if (suit != other.suit)
        return false;
    return true;

could be simplified to

    return rank == other.rank && suit == other.suit;

Variable types should be interfaces

private ArrayList<Card> deck = new ArrayList<>();

As a general rule, prefer

private List<Card> deck = new ArrayList<>();

This allows you to change the implementation easily, without affecting other parts of the program. The exception would be if you were using some functionality that was in ArrayList but not List. I don't see such functionality here nor in the other ArrayList declarations, so they could each be changed to List instead.

Keep it simple, again

        Card drawnCard = deck.get(deck.size() - 1);
        deck.remove(deck.size() - 1);
        return drawnCard;

You could just say

        return deck.remove(deck.size() - 1);

with the same effect.

Block form is clearer than statement form

    } else throw new EmptyDeckException();

As a general rule in the C-style languages, it is more robust and clearer to use block form in control statements.

    } else {
        throw new EmptyDeckException();
    }

Also consider writing the method the other way

    if (deck.size() <= 0) {
        throw new EmptyDeckException();
    }

    return deck.remove(deck.size() - 1);

That handles the exceptional case before going through the main logic.

Favor built-ins over custom

    ArrayList<Card> tempOldDeck = new ArrayList<>();

    for (Card card: deck){
        tempOldDeck.add(card);
    }

You can just say

        List<Card> tempOldDeck = new ArrayList<>(deck);

Then you don't have to specify the for loop.

    for (int i = 0; i < deck.size(); i++){  
        deck.set(i, tempOldDeck.get(randomPermutation[i] - 1));
    }

You can write this as

    deck.empty()
    for (int i : randomPermutation) {
        deck.add(tempOldDeck.get(i - 1);
    }

1. Use interfaces as much as you can.

   private List<Card> deck = new ArrayList<>();
   

2. Checked Exceptions are bad, don't use them

   public class EmptyDeckException extends RuntimeException{
    ..
   }
   
   public Card draw(){ // no throws 
   }
   

3. You don't need to write a shuffle method yourself, there is a one in the JDK already

   List<Integer> numbers = new ArrayList<>();
   
   for (int i = low; i <= high; i++){
       numbers.add(i);
   }
   Collections.shuffle(numbers);
   

Other than the excellent answers already posted one thing that I asked myself while looking through these is Why even have the empty constructors?

You generally wouldn't want someone coming in an instantiating a card(). remove them to ensure that each object is properly instantiated.

I'll start with more style oriented comments and move to more general OO concepts. And I'll skip what's already been said.

Enums

I much prefer to see enum values declared on individual lines, for readability. I also don't think including the word "enum" in your enum definitions is helpful. I'd like to see

public enum Suit {
    Diamonds,
    Clubs,
    Hearts,
    Spades
}

Spacing

You use spaces both inconsistently. In general, this suggests a lack of attention to your code and is unpleasant to read. The end of your compareTo method, for example, looks like

            return 0;
        }

    }


}

and should look like

            return 0;
        }
    }
}

Overrides

compareTo is an interface method, but you've missed the @Override annotation. Always include that annotation when implementing a method from an inherited base class or from an interface.

Builders

Most methods in builders (it's a general design pattern) return a reference to the builder so you can chain method calls like such

private Strin generateImageLocation(){
    return new StringBuilder()
            .append(IMAGE_FOLDER)
            .append("/")
            .....
            .toString()
            .toLowerCase();
}

Data Types

This was you first bigger OO mistake to me. When you think of a deck of cards, do you think of a randomly accessible array of cards? Do you think of a stack of cards? It is possible that your game may require your ability to draw cards from anywhere in the deck, but from the code you've provided it doesn't seem this is the case. I'd like to see

    private Stack<Card> deck = new Stack<Card>();

Then your draw method would look like

 public Card draw(){
    if(deck.size() > 0) {
        return deck.pop();
    } else {
        throw new EmptyDeckException();
    }
}

Hashing

We know enough about decks and cards to write a perfect hash function (one which will return a different value for each of the 52 different possible cards we could have) with the use of enum orinals.

public int hashCode(){
    return (suit.ordinal() * 13) + rank.ordinal();
}

Separation of Concerns

I would like to see the association between a Card and an Image in a different place in your program. In general when you build GUI applications, you want to separate the things the User sees from the representation of data in your program. With you current design, you make it challenging to build a flexible UI. What if 3 months from now you decide you've got a good game, and now you want to support multiple "skins" on your cards, so that users can customize the UI to their liking. Now you've got to come change the implementation of the Card class - not something you should have to do to make a change to the way the UI looks.