implements #60 EventHandler and ConsHandler by patrickguenther · Pull Request #62 · scipopt/JSCIPOpt

patrickguenther · 2025-11-16T22:28:06Z

Sorry for the large PR, but it turns out EventHandler with the SCIP_Event data union has a lot of possible types.

patrickguenther · 2025-11-16T22:37:41Z

+        @Override
+        protected SCIP_Retcode scipExec(Scip scip, SCIP_Event event) {
+            assert (event.getEventtype() & EventType.BESTSOLFOUND) != 0 : "Unexpected event caught";
+            Solution solution = new Solution(SCIPJNI.getEventDataSolution(event));


This is how I would envision a user to be implementing an event handler: He get's the raw SCIP_Event passed and has to call one of the SCIPJNI.getEventData*(SCIP_Event) methods to access the union member that corresponds to his event type. Would that be alright? Is it too complicated?

We could also implement custom scipExec* methods for each event type, but the documentation doesn't really say, which union member corresponds to which event type, so it would be a lot of untested code.

This is not acceptable this way. The SCIPJNI class is not supposed to be user API. The event handler should be getting an object-oriented wrapper that supports getters such as event.getSolution().

See, e.g., how my ExpressionHandler class works, e.g., how createObjExprhdlr implements scip_eval, constructing the object-oriented Expression and Solution wrappers, then calling ExpressionHandler.eval with the object-oriented abstractions.

I see. The event data struct in SCIP however is a union (at least for SCIP 9, haven't looked at version 10 yet). I assume each member of the union corresponds to a specific event type. Would you then also have a different event class corresponding to each event type or would it suffice to have a single event class with all possible union member accessors on it? Potentially returning garbage or crashing if the wrong accessor is being called for the wrong event type.

I can do it either way, but I think if I go the route of having multiple Event subclasses each with their own data accessors, it would be tough to test all possible event types, since I'm not even sure under which conditions they get triggered. For that we should probably have a proper maven build with Junit tests.

What you can do to make the union accessors safe is to have the object-oriented accessors first check the event type before calling the SCIPJNI C-style accessor functions, e.g.:

public Solution getSolution() { if ((_eventptr.getEventtype() & EventType.SOLEVENT) == 0) { throw new UnsupportedOperationException("getSolution() not available for this event"); } return SCIPJNI.getEventDataSolution(_eventptr); }

(SOLEVENT is the event type mask for all events involving a solution, defined in the SCIP C code as follows:

/* event masks for primal solution events */ #define SCIP_EVENTTYPE_SOLFOUND (SCIP_EVENTTYPE_POORSOLFOUND | SCIP_EVENTTYPE_BESTSOLFOUND) #define SCIP_EVENTTYPE_SOLEVENT (SCIP_EVENTTYPE_SOLFOUND)

There are similar SCIP_EVENTTYPE_*EVENT masks for all the other union fields.)

patrickguenther · 2025-11-16T22:41:12Z

+
+import java.util.Objects;
+
+public class ResultHolder {


I picked this pattern up from the Fico Xpress java library. It corresponds to an output pointer that is passed to the user as a call back and the user is expected to set the result of the handler there.

One could also pass an instance of SCIP and make the corresponding JNI call when the user passes the result immediately, but this would not be safe, if the user somehow leaks the ResultHolder outside of the EventHandler and calls the set method later.

The result should just be the return value of the callbacks in the end user API, rather than an output argument. The user API should not contain SCIP_Retcode at all, instead, the retcode should always be SCIP_OKAY unless an exception is thrown in the user code (then your Obj*Hdlr implementation should catch the exception and return SCIP_ERROR). This frees up the return value for the actual result (and callbacks without a result just return void). See, e.g., ExpressionHandler.scip_bwdiff.

(Then you do not need this wrapper class at all.)

What do I do with the methods that return a SCIP_Retcode and get passed 2 output pointers like scip_getnvars with output pointers nvars and success; and scip_getdivebdchgs with output pointers success and infeasible. I guess the object oriented way of doing it would be to return a value object with the respective pair of fields.

The easiest way in those particular cases with success is to return a flag value for the failure case. One thing that you can always do is return the boxed type (e.g., Boolean instead of boolean for infeasible) and use null for failure. You can also use, say, a negative nvars as a failure value. For the boolean, you could also instead return an int that is 0 for false, >0 for true, <0 for failure, or an enum with the entries Feasible, Infeasible, and Failure. But I think the boxed Boolean is the cleanest solution in this case. (For nvars, though, I would probably just use negative numbers as failure.)

If you have truly multiple results, then returning a result object (a basic data object, like a C struct) is indeed the way. But for a result and a success flag, I would not do it that way.

E.g., ExpressionHandler uses null flag values (though in that case, I did not have to box anything, because the return value was already an object) for the success flag in scip_estimate and scip_curvature and for the infeasible flag in scip_reverseprop.

patrickguenther · 2026-06-17T17:35:43Z

@kkofler any chance this can make it into master? Do I need to make changes? 😁
I know, it looks like a large PR, but it's also mostly generated code.

kkofler · 2026-06-18T00:16:26Z

So my first question would be: What version(s) of SCIP have you tested this with? Does it work with the latest (i.e., 10.0.x)? Do you know what the minimum version of SCIP it works with is? (That said, if I merge my exprhdlr branch, the minimum required SCIP version for the current JSCIPOpt will be 10.0.0 anyway.)

kkofler · 2026-06-18T01:00:10Z

@kkofler any chance this can make it into master? Do I need to make changes?

Yes to the latter (unfortunately): as I commented above, I do not like at all the way this exposes some C/C++ API internals (raw SCIP_Event with accessors only through SCIPJNI, SCIP_Retcode, out(put) arguments instead of return values) to the JSCIPOpt user. I would like the API to look like the expression handler one on my exprhdlr branch. (The only reason I have not yet merged that one is that I was reluctant to bump the minimum SCIP requirement to 10.0.0 just yet. But I already use that branch in production. I have in fact already used the backport to SCIP 9.2 in production before, but due to additional changes to ObjExprHdlr in SCIP 10, SCIP 9.2 with ObjExprHdlr backported and SCIP 10 are neither API- (source-) nor ABI- (binary-) compatible with each other, so the current exprhdlr branch does not work with the backport.)

patrickguenther · 2026-06-18T07:13:03Z

Thank you for your comments.
This was tested with the latest 9.x version of SCIP. I wasn't sure about the maturity of SCIP 10.x, which is why I'm still reluctant to upgrade. I can give it a try with version 10 over the weekend.

I wasn't aware of your exprhdlr branch. I'd be happy to take a look at it for inspiration.

The only reason I have not yet merged that one is that I was reluctant to bump the minimum SCIP requirement to 10.0.0 just yet.

Maybe we should just branch from the current master and keep it for SCIP 9.x compatibility and update master going forward to use SCIP 10.x only.

patrickguenther · 2026-06-19T23:56:14Z

+/**
+ * Illustrates the use of ConsHandler to solve the traveling salesman problem.
+ */
+public class ConsHandler {


Renamed the example classes to be in line with existing examples: naming them after the shown feature, rather than the problem type used.

patrickguenther · 2026-06-20T00:00:10Z

+                    Solution solution = new Solution(sol);
+                    GetDiveBdChgsResult result = getdivebdchgs(jScip, solution);
+                    if (result == null) {
+                        return SCIP_Retcode.SCIP_OKAY;


Right now using a return of null to indicate "not implemented". Should return OKAY here and not touch the pointers. Probably better to have a dedicated enum constant?

patrickguenther · 2026-06-20T00:07:04Z

+                    if (result == null) {
+                        return SCIP_Retcode.SCIP_OKAY;
+                    }
+                    switch(result) {


I rewrote this based on your comment, but I'm not sure I like it. Just looking at SCIP's API this method has 3 outputs: SCIP_RetCode, success and infeasable and all 3 seem to be independent of each other. Also because most methods here don't have the success output pointer.
By writing it like this, it is no longer possible for a user to return success = 0 and SCIP_Retcode.OKAY. Not sure what the usecase would be for that, but that's also the point: I wouldn't have to make that decision.

I'll have to double-check with SCIP's code/documentation what the API of these methods is supposed to be.

patrickguenther · 2026-06-27T11:05:37Z

@@ -0,0 +1,4 @@
+package jscip;
+
+public interface Event {


This is the SCIP_Event::data union type in scip. I chose to call it just Event instead of EventData

patrickguenther · 2026-06-27T11:07:00Z

Maybe I should put all Event related files in a new package jscip.events?

patrickguenther · 2026-06-27T11:12:20Z

+        return result;
+    }
+
+    private static class AllEventHandler extends jscip.EventHandler {


TODO: remove this class, just used for debugging.
I was curious if a triggered event by SCIP could have multiple Event types at the same time. Glad to see each event is only of a single type (at least for this problem).

patrickguenther · 2026-06-27T11:16:51Z

+                double[] returns,
+                double[][] covarianceMatrix
+        ) {
+            super("SolutionObserver", "Implements custom stopping criterion.", EventType.BESTSOLFOUND);


Should the user actually have to use this EventType? SCIP Api makes it possible to add the same event listener for multiple different event types. This however makes it necessary, that the user only gets a callback with the base type Event and has to inspect it's runtime class and cast it accordingly. I could circumvent this, by introducing dedicated subscription Methods like:

scip.addSolEventHandler(...)

scip.addBestSolEventHandler(...)

scip.addPoorSolEventHandler(...)

etc.

patrickguenther · 2026-06-27T11:18:27Z

@@ -0,0 +1,4 @@
+package jscip;
+
+public class EventRowAddedLp implements Event {


Some of these events, I have not bothered to implement properly. The row and node events look rather complicated and I would leave this up to a separate PR.

patrickguenther · 2026-06-27T11:22:24Z

+    }
+
+    static {
+        // Java 8 does not support switch statements over long. Using this map as a replacement.


I assume Java 8 is still the java version to use? Otherwise this could be replaced by a switch?

patrickguenther added 7 commits November 9, 2025 18:25

implements scipopt#60 event handlers

852595d

60 event handlers and accessors for SCIP_Event::data union members

0fc73a4

adds travelling sales man problem

6e04348

60 Tsp implemented using ConstraintHandler

5553e4e

60 Tsp adds best solution in output

a12a1b3

60 clean up tsp example, adds more arguments java handler methods

1a9c090

60 event handlers regenerated scipjni_wrap.cxx

98a7e03

patrickguenther commented Nov 16, 2025

View reviewed changes

Comment thread src/scipjni.i

wip scipopt#60

979af56

patrickguenther commented Jun 19, 2026

View reviewed changes

patrickguenther commented Jun 20, 2026

View reviewed changes

patrickguenther marked this pull request as draft June 20, 2026 00:08

wip scipopt#60 add specific class for each event type

0cd1eb9

patrickguenther commented Jun 27, 2026

View reviewed changes

kkofler mentioned this pull request Jul 20, 2026

add event handler support #63

Closed

		@@ -0,0 +1,4 @@
		package jscip;

		public class EventRowAddedLp implements Event {

Conversation

patrickguenther commented Nov 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kkofler Jun 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

patrickguenther Jun 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kkofler Jun 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kkofler Jun 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

patrickguenther commented Jun 17, 2026

Uh oh!

kkofler commented Jun 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kkofler commented Jun 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

patrickguenther commented Jun 18, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

patrickguenther Jun 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

patrickguenther Jun 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

patrickguenther commented Nov 16, 2025 •

edited

Loading

kkofler Jun 18, 2026 •

edited

Loading

patrickguenther Jun 18, 2026 •

edited

Loading

kkofler Jun 18, 2026 •

edited

Loading

kkofler Jun 18, 2026 •

edited

Loading

kkofler commented Jun 18, 2026 •

edited

Loading

kkofler commented Jun 18, 2026 •

edited

Loading

patrickguenther Jun 20, 2026 •

edited

Loading

patrickguenther Jun 27, 2026 •

edited

Loading