Some questions about MaterialFX

[Glavo]

@palexdev

I am the maintainer of the HMCL project. We're hoping to migrate from JFoenix to MaterialFX later this year or next year, but I'm a little confused about the current state of MaterialFX, so I'd like to ask you some questions:

1. What is the current progress of the MaterialFX rewrite?
   If we use the current main branch of MaterialFX, will it be
   expensive to migrate in the future?

2. I noticed that the rewrite branch is currently using Java 25. Will this also happen to the main branch in the future?

   We just left Java 8 and plan to stay on Java 17 for a long time.
   Because Java 17 is the last LTS compatible with Windows 7, it is unlikely that we will be able to upgrade to a later version before 2029. If MaterialFX stops being compatible with Java 17 in the future, we might have to maintain our own fork, which would be a bit annoying :(

3. Can we easily exclude unnecessary resources from mfxresources?

   Our application is a fat jar that is less than 10MiB. JFoenix is less than 600KiB, so it's fine for us.

   However, mfxresources contains so many resources that the entire MaterialFX is close to 9 MiB, which is too large for us to accept. If possible, we would like to exclude all font resources in mfxresources. Is this possible?

[palexdev]

Hello @Glavo, I'm honestly surprised that JFoenix is still working after all these years.

Unfortunately, the rewrite is taking longer than I hoped. There’s still a lot of work to do. Right now I’m working on a showcase to have a visual checklist of what's already done and to prepare for making it the main branch. There aren’t many controls implemented yet, but I don’t expect the APIs to change much going forward. I believe the ones that are implemented are already production-ready.

As for JDK compatibility, I don't really care to be honest, sorry. This is a hobby project, and I want to use the latest technologies available. That said, I’ll probably upgrade only to future LTS versions.

Excluding resources isn’t straightforward. You’d either need to fork the project or manipulate the JAR using Maven or Gradle. There are two types of resources:

• Icon resources, which are required for MFXFontIcon to work
• Fonts, which are quite heavy and could theoretically be removed, but the themes depend on Montserrat, so you’d need to provide an override CSS to replace them

[Glavo]

I'm honestly surprised that JFoenix is still working after all these years.

It was actually corrupted, but we maintained our own fork to fix some issues. We also used some techniques to make a single JAR work well on Java 8~25.

However, as we move away from Java 8, the need to maintain it begins to decline, so we want to migrate to a more modern library.

Unfortunately, the rewrite is taking longer than I hoped. There’s still a lot of work to do. Right now I’m working on a showcase to have a visual checklist of what's already done and to prepare for making it the main branch. There aren’t many controls implemented yet, but I don’t expect the APIs to change much going forward. I believe the ones that are implemented are already production-ready.

I understand. We will begin trying to migrate to MaterialFX in the coming months.

As for JDK compatibility, I don't really care to be honest, sorry. This is a hobby project, and I want to use the latest technologies available. That said, I’ll probably upgrade only to future LTS versions.

Excluding resources isn’t straightforward. You’d either need to fork the project or manipulate the JAR using Maven or Gradle. There are two types of resources:

Icon resources, which are required for MFXFontIcon to work
Fonts, which are quite heavy and could theoretically be removed, but the themes depend on Montserrat, so you’d need to provide an override CSS to replace them

I see. Thank you for developing such a great library.

The need to fork this repository ourselves is not surprising to us. While this will increase our maintenance costs, it also allows us to customize it more deeply.

For example, we don't need icon fonts because we simply embed the Material Symbols icons we need and draw them using SVGPath. We also have deeper customization needs for localization.

Considering that we previously maintained a version of JFoenix even without the source code (yes, the author of that fork lost the source code, and we've been maintaining it by decompiling and patching binary files), maintaining the MaterialFX fork won't add any more maintenance costs for us compared to before.

Finally, thank you very much for your reply :)