The dependencies are massive

[fair-acc]

The dependencies are massive

[wirew0rm]

Thanks for bringing this up, we're looking into it. Some preliminary remarks:

• javafx-web: removed with only minor changes
• fastutils: low usage because it was added only recently. "A type-specific array-based list; provides some additional methods that use polymorphism to avoid (un)boxing" <- our usecase, DGrowArray is missing a lot of features that we want to have + we want to concentrate on charting instead of primitive data types.
• svg: is an inhouse functional requirement (remaining pngs will also be migrated to vector based)
• jfxtras: currently used in DataViewer, will probably be removed after overhaul of that class.
• java's NumberFormatter is actually a lot less suited for formating axis labels, where we need to control the number of digits and dynamically switch to exponential representations. -> nontrivial change affecting core usecases of our library
• slf4j: slf4j is the standard logging solution in chart-fx's main application, so we will not get rid of it, but we aim to provide better out of the box experience by providing sample/default configuration.

[ennerf]

• fastutils: In my use case I assume that ProGuard can shrink away whatever isn't used, so I'm not all that worried about it. It does noticeably increase packaging time, but that's not a deal breaker.

• svg: I've spent several hours today trying to get all the dependencies sorted out in ProGuard, but so far I haven't managed to produce an executable that still works. I realize that this is a functional requirement for you, but would it be possible to turn this into an optional feature? For example,

// Pseudo code (maybe reflection or explicit install by user)
static {
   // check if SvgImageLoaderFactory is on classpath
   // If so -> install support for .svg
}

// API with fallback
public Image getIcon(String name) {
    try {
       return read(name + ".svg");
    }catch(cant-read-svg-exception e){
       return read(name + ".png");
    }
}

This way you automatically get svg support if the library is on the classpath, or if a user installs support in some other way. It's your library, so it's obviously your call, but if possible I'd really like to avoid having to maintain a fork. This seems like a really small change and I'm probably not the only user who will run into this.

[ennerf]

I was able to work around this by excluding everything that isn't absolutely necessary. My only remaining issue is that I've so far been unable to remove or shrink com.ibm.icu. ~15MB total is already a lot more reasonable though.