Skip to main content

UniObject for Java Memory Leaks

  • October 2, 2026
  • 0 replies
  • 20 views

Doug Averch
Forum|alt.badge.img+2

In all my years of using UniObjects for Java (UOJ), I have not paid attention to memory leaks in my syntax. They existed I am sure, but why bother if the process is pretty quick and was getting re-used by the web server. Of course, I would make sure that I closed files or make sure that I close sessions. I have a Windows machine running a 3.5 gig of memory that has been working for years.

This year (2026) I upgraded the web server from Apache Tomcat 9 to Apache Tomcat 11. I upgraded Java from 17 to to 25. It was painful because of the Javax libraries which are no longer supported at this Java release and had to be replaced with Jakarta libraries. All of the all other libraries like BIRT, our Unidata/Universe Report writer, required updates to run in Java 25 as well.

All of this increased my war file size by at 25%. That does not sound much but on this particular machine the margin of error was gone we would run out of memory several times a month. Every minute or so depending on what the client was doing, that process named uv_slave.exe by Rocket Software would grow by 0.2MB. By morning the process could be 50MB and if the ran for a week or so that process could be over 100MB.

This forced me to look at the web site a couple of times a week and restart Apache Tomcat to release the memory. I initially thought that logging out the growing processes would solve the problem but another U2 process would replace the dead process grabbing memory. I re-read the entire UOJ documentation and found no relief.

It turns out that my code only had two memory leaks according to Gemini AI. I did not close two UniDataSet variables after I used them which did support the close option, surprise that was a something new I missed in 20 years of using UOJ Java.

However, other UOJ commands like UniCommand and UniSelectList do not have a close option. Gemini AI suggested that I set them to null and hope that Java Garbage Collection with recycling the memory. Java garbage collection never made a significant dent in the running processes.

I still have the problem. Any UOJ code warriors that have fixed this issue.