5

I'm willing to use Spring boot technology in my JavaFX application (to get the advantage of its dependency injection), but I'm wondering about the consequences on the memory, as you know any class with a "component" notation will be loaded to the MetaSpace (since it Spring boot will create a static object from it), so with tens of JavaFx view controllers loaded to the MetaSpace they will never get garbage collected from the launching of the application to the end, which is obviously a bad thing, is there any way to get around of this issue?

Youssef Idraiss
  • 396
  • 5
  • 19
  • 1
    hi, the framework is fairly lightweight, memory usage would mostly depend on concurrent requests and application code – jspcal Dec 24 '21 at 04:17
  • I don’t know what you mean by spring boot creating static objects from things. And I really don’t know what you mean by a class being loaded from the metaspace - all class information is stored in the metaspace; why do you think using a DI framework would make a difference? – Boris the Spider Dec 24 '21 at 04:19
  • @BoristheSpide i believe for classes with Component notation spring boot creates a static object of it during the launching of the application in the spring boot container, and we get access to it by using Autowired notation (at least this is what I understand from a youtube tutorial), which means a lot classes with Component notation = a lot of static variables that will never get garbage collected which is a major disadvantage ? – Youssef Idraiss Dec 24 '21 at 04:33
  • 4
    The total memory of those objects is likely to be small; e.g. ~100Kb. This small increase in memory usage is far outweighed by the advantages of using Spring Boot, Spring DI and so on. (This question sounds to me like premature optimization.) But if you think it will make a difference ... *measure it*. – Stephen C Dec 24 '21 at 04:47
  • First and foremost, Spring doesn’t create static anything. Secondly metaspace is a red herring. To your actual question - if you register these objects as Spring singletons, that implies they are currently also singletons; so do they get garbage collected _now_? – Boris the Spider Dec 24 '21 at 04:51
  • 1
    @StephenC you are totally right, but I think this is for the web development case, for the JavaFX applications when the view controller doesn't get garbage collected means also the view objects will always stay there TableViews,ListViews,Panes ... which may take some important space, I will try to do a test to it, thank you. – Youssef Idraiss Dec 24 '21 at 04:59
  • @BoristheSpider if they are singletons that explicitly means static, so I think the answer is no? – Youssef Idraiss Dec 24 '21 at 05:02
  • 1
    (For the record, 100kB is a guestimate. But even if the memory overhead was 10MB, I still wouldn't think it mattered.) – Stephen C Dec 24 '21 at 05:02
  • 3
    Singleton means “single instance”. Static is an implementation detail. A singleton by no means has to be static! – Boris the Spider Dec 24 '21 at 07:05
  • @BorisTheSpider i got you now, i should do more researching about how spring boot manage its container, i appreciate your help – Youssef Idraiss Dec 24 '21 at 07:22

1 Answers1

5

You write in comments:

JavaFX applications when the view controller doesn't get garbage collected means also the view objects will always stay there TableViews,ListViews,Panes ... which may take some important space

But I don’t think it needs to be that way.

The controller instance which references the Java nodes is just a Java object like any other and will be available for garbage collection when there are no more references to it in the JVM.

Let’s say you configure your JavaFX SpringBoot integration like this:

So you configure your controller factory to use Spring beans:

fxmlLoader.setControllerFactory(
    springContext::getBean
);

Then your controllers are Spring beans whose scope you can control.

If you use prototype scope:

@Bean
@Scope("prototype")
public PersonController personControllerPrototype() {
    return new PersonController();
}

Then the behavior is as specified in:

Spring does not manage the complete lifecycle of a prototype bean: the container instantiates, configures, and otherwise assembles a prototype object, and hands it to the client, with no further record of that prototype instance.

Typically you will create a controller and add a reference to the object tree that it instantiates into the scene graph. If you replace the tree in the scene graph when you navigate, and you don’t keep a reference to the controller anywhere, then the controller and any other associated nodes which have been removed from the scene graph can be garbage collected.

Or, if you wanted to just load the fxml once and keep the controller around forever you could use singleton scope to do that.

So basically, you can choose the scope and lifecycle of your controllers to be as best fits your application or the individual controllers that you are using.

jewelsea
  • 150,031
  • 14
  • 366
  • 406
  • 3
    You almost certainly want prototype scope for controllers anyway, just from an application logic perspective. If you loaded the same FXML twice, and you had singleton scope for the controllers, strange things would happen because the one-and-only controller instance would only be able to refer to one UI instance. – James_D Dec 25 '21 at 10:15