Code Health: Observable in java.util has been deprecated

[metaprime]

• Ripme version: main, 2.1.13+1

• Java version: openjdk 21.0.5 2024-10-15
  OpenJDK Runtime Environment (build 21.0.5+11-Ubuntu-1ubuntu124.04)
  OpenJDK 64-Bit Server VM (build 21.0.5+11-Ubuntu-1ubuntu124.04, mixed mode, sharing)

• Operating system: WSL2 Ubuntu 24.04

• Exact URL you were trying to rip when the problem occurred: N/A

• Please include any additional information about how to reproduce the problem:

./gradlew clean
./gradlew test

Expected Behavior

No warnings

Actual Behavior

ripme/src/main/java/com/rarchives/ripme/ripper/AbstractRipper.java:37: warning: [deprecation] Observable in java.util has been deprecated
                extends Observable
                        ^

[soloturn]

what do you suggest to use instead @metaprime ?

[metaprime]

Just logging the issue that was shown in the build. I think it's potentially a pretty big fix.

[metaprime]

It's not clear whether there's an equivalent replacement or whether we really need to care about this. I dislike when things get deprecated without an equivalent better option recommended, but it does happen.

[soloturn]

chatgpt says flow is alternative, das this fit our use case?

import java.util.Observable;
import java.util.Observer;

public class ObservableExample {
    public static void main(String[] args) {
        // Create an observable
        MyObservable observable = new MyObservable();

        // Create an observer
        Observer observer = (o, arg) -> {
            System.out.println("Received: " + arg);
        };

        // Add the observer
        observable.addObserver(observer);

        // Notify observers with some data
        observable.setData("Hello");
        observable.setData("World");
    }
}

// Custom Observable class
class MyObservable extends Observable {
    private String data;

    public void setData(String data) {
        this.data = data;
        setChanged(); // Mark the observable as changed
        notifyObservers(data); // Notify observers
    }
}

import java.util.concurrent.Flow;
import java.util.concurrent.SubmissionPublisher;

public class FlowExample {
    public static void main(String[] args) throws InterruptedException {
        SubmissionPublisher<String> publisher = new SubmissionPublisher<>();

        // Create a subscriber
        Flow.Subscriber<String> subscriber = new Flow.Subscriber<>() {
            private Flow.Subscription subscription;

            @Override
            public void onSubscribe(Flow.Subscription subscription) {
                this.subscription = subscription;
                subscription.request(1); // Request one item at a time
            }

            @Override
            public void onNext(String item) {
                System.out.println("Received: " + item);
                subscription.request(1); // Request the next item
            }

            @Override
            public void onError(Throwable throwable) {
                System.err.println("Error: " + throwable.getMessage());
            }

            @Override
            public void onComplete() {
                System.out.println("Done!");
            }
        };

        // Subscribe to the publisher
        publisher.subscribe(subscriber);

        // Publish some items
        publisher.submit("Hello");
        publisher.submit("World");
        publisher.close();

        Thread.sleep(1000); // Allow time for processing
    }
}

[metaprime]

Not sure. I don't think our case is really about concurrency, although it does have to do with concurrent updates. It might not matter that it's in the concurrency library; it might work anyway.

[metaprime]

Technically Observer is a pattern that doesn't really need the standard library to implement. The library's observer doesn't really provide all that much behavior per se. We could even essentially implement our own that is exactly what they do but keeps the method we want so that there's no other change to the code.

[metaprime]

And at that point, we should not bother moving off of the deprecated one. Nothing's broken here and it seems like change for change's sake. Maybe we can add some annotation to suppress the warning instead