Migrate from LocalSolver to Hexaly

Since November 2023, LocalSolver has become Hexaly. This new name is intended to better reflect what our solver has become, moving progressively from a solver based on local search techniques to a global optimization solver, combining numerous optimization techniques. For more information on this new identity, please consult the corresponding page on our blog.

In addition to our commercial content, we have decided to deploy this identity to the heart of our existing products by changing all our APIs, binaries and installers. We invite all our users to take this step with us and adapt their software accordingly. However we are aware of the major changes this may represent for our customers. That is why, to ensure a smooth transition, the old APIs will be supported for a transition period of one year. You will find all the information you need to make this transition and the corresponding schedule below.

Schedule

The migration from LocalSolver to Hexaly is taking place in 3 progressive phases:

  • Hexaly 12.5 (November 2023): Change of website and product names. The old LocalSolver trademark disappears in favor of Hexaly, but nothing changes technically in our products (same installers, same binaries, same APIs).

  • Hexaly 13.0 (July 2024): Our APIs and binaries migrate to the new identity. To ensure a smooth transition, the old APIs are still supported, but no new feature will be added. The old APIs allow you to benefit from the latest performance enhancements and bug fixes, without having to change your code.

  • Hexaly 14.0 (mid-2025): The old LocalSolver APIs disappear completely. The transition to Hexaly is complete. Old LSP and LSB files and older versions of LocalSolver will continue to be supported.

Installers and packages

The installers are renamed to bear the new name “Hexaly”. We ship just one installer under the Hexaly brand, but it installs both versions of the APIs for C#, Java and Python. You may have to change your deployment scripts slightly if you automated the installation of Hexaly Optimizer on your servers by automatically retrieving our deliverables from our website: you will need to update the scripts by changing “LocalSolver” to “Hexaly”.

Environment variables

The location of LocalSolver and its license was controlled by 3 environment variables LS_HOME (for Windows only), LS_LICENSE_PATH and LS_LICENSE_CONTENT. These variables now become HX_HOME, HX_LICENSE_PATH and HX_LICENSE_CONTENT respectively. The old variables continue to operate, but have a lower priority than the new ones if both are specified.

Pip packages (wheels)

We distribute two Python wheels (pip installable packages) during the transition phase. You can still use pip install localsolver or pip install hexaly, but in keep in mind that no new feature will be added to the old Python API. You can, however, benefit from the latest performance enhancements of the optimizer and bug fixes without changing a line in your code or existing Python projects.

Changes to our APIs

Our rebranding involves a complete renaming of our APIs from LocalSolver to Hexaly. The changes brought by these new APIs are detailed below.

If you don’t want to switch to the new APIs straight away, you can also use the old Python, Java and C# APIs, which will be maintained for another 1 year (for Hexaly 13.0 and Hexaly 13.5). But keep in mind that no new feature will be added to these old APIs. They nevertheless allow you to benefit from performance improvements or bug fixes without changing a line in your code.

If you’d like to make the switch now, here’s a list of the main changes you’ll need to take into account:

  • Main class name LocalSolver becomes HexalyOptimizer

  • Main class name LSPModeler becomes HexalyModeler

  • The LS prefix for all classes has been changed to Hx (note the lowercase Hx)

  • The LSP prefix for all classes has been changed to Hxm (note the case, which is Hxm).

  • The modeler and optimizer now have two distinct namespaces. Previously, there was a localsolver namespace and a child localsolver.modeler namespace. Now the two are separated and are no longer parents but siblings, hexaly.optimizer and hexaly.modeler.

  • Some long-deprecated features and methods have been removed.

  • In general, all references to ls and lsp have disappeared.

More language-specific changes have also been made. These are detailed below.

C# API changes

  • The name of the binary (the DLL) has been renamed from localsolvernet.dll to Hexaly.NET.dll (case is important). The change better reflects C# library naming conventions.

  • The localsolver namespace becomes Hexaly.Optimizer.

  • The namespace localsolver.modeler becomes Hexaly.Modeler.

  • Public methods previously called GetLocalSolver() or CreateLocalSolver() have been renamed GetOptimizer() and CreateOptimizer().

Java API changes

  • localsolver.jar becomes hexaly.jar

  • The localsolver package becomes com.hexaly.optimizer.

  • The localsolver.modeler package becomes com.hexaly.modeler. The new names are aligned with the Java convention (which uses the company’s reversed internet domain name).

  • Public methods previously called getLocalSolver() or createLocalSolver() have been renamed getOptimizer() and createOptimizer().

Python API changes

  • The localsolver module becomes hexaly.optimizer.

  • The localsolver.modeler module becomes hexaly.modeler.

  • We maintain two pip packages (wheels): one for localsolver (old API), the new one for hexaly.

  • Public methods previously called get_localsolver() or create_localsolver() have been renamed get_optimizer() and create_optimizer().

C++ API changes

Unlike other languages, we’ve opted for a single namespace instead of the old two. So localsolver and localsolver ::modeler simply become hexaly. Please note that only the new C++ API is supplied. The old one, under the name localsolver, has been permanently withdrawn.

Binaries / executables

Unlike APIs, executables and the native library are not supplied with the double naming hexaly / localsolver. Even if you wish to retain the old LocalSolver API for the next releases, you need to change at least the binaries you integrate as dependencies in your projects. This may require a small change in your deployment scripts.

  • localsolver.exe becomes hexaly.exe.

  • lskeygen.exe becomes hxkeygen.exe.

  • lstokenserver.exe becomes hxtokenserver.exe.

  • localsolver130.dll / liblocalsolver130.so / liblocalsolver130.dylib becomes hexaly130.dll / libhexaly130.so / libhexaly130.dylib.

Modeling language (LSP)

  • Files that previously had the extension .lsp will now have the extension .hxm (for HeXaly Modeler).

  • Hexaly will continue to read .lsp files without any trouble.

  • The names of global variables such as lsTimeLimit, lsNbThreads, lsSeed… previously prefixed with ls, are now prefixed with hx (hxTimeLimit, hxNbThreads, hxSeed). The old names are still supported, but the new ones take precedence over the old. In other words, if you enter both hxSeed and lsSeed, only the variable prefixed with hx will be taken into account.

  • The module previously called localsolver is now called hexaly.

  • The old localsolver module still exists, but it’s just an alias for the new hexaly module.

In short, all LSP files will continue to function without any code changes. Only the name of the called executable changes from localsolver.exe to hexaly.exe. Unlike the dual Java, C# and Python APIs, which will be phased out in a year, there are no plans to remove support for these old .lsp files, or for the old global variables. They will simply be deprecated over time.

LSB files

Nothing changes except the file extension, which changes from .lsb to .hxb. Hexaly will continue to read the .lsb format, and there are no plans to remove support for it in future versions.

In a nutshell, for the next two versions 13.0 and 13.5 (a one-year transition), we’ve decided to provide our users with a dual API (Hexaly and LocalSolver) for Java, C# and Python. You’ll be able to continue using the old ones under the LocalSolver name without changing a single line of code which means that, for a time, you can benefit from Hexaly’s performance improvements and patches without migrating to the new APIs.

Please note, however, that even if the old APIs remain supported, no new functionality will be added, and you will almost certainly need to change your CI/CD scripts slightly, as the name of the native library has been changed and we don’t provide double binaries (only a double API).