iConcept Press was listed on Beall’s List, though, at some point before January 15, 2013.

http://web.archive.org/web/20130115225454/http://scholarlyoa.com/publishers/

Thanks for your comments to let me know that I’m not the only one experiencing this, and for your hard work in finding a work-around. I’ll see if this can help us too.

final Toolkit toolkit = Toolkit.getDefaultToolkit(); if (toolkit instanceof apple.awt.CToolkit) { final boolean isRunningInHiDPI = ((apple.awt.CToolkit)toolkit).runningInHiDPI(); if (isRunningInHiDPI) setScrollMode(SIMPLE_SCROLL_MODE); toolkit.addPropertyChangeListener(“apple.awt.contentScaleFactor”, new PropertyChangeListener() { private int oldScrollMode = isRunningInHiDPI ? SIMPLE_SCROLL_MODE : BLIT_SCROLL_MODE;

1
2
3
4
5
6
7
8
9
10
            @Override

            public void propertyChange(PropertyChangeEvent evt) {

                if ("apple.awt.contentScaleFactor".equals(evt.getPropertyName())) {

                    final int currentScrollMode = getScrollMode();

                    setScrollMode(((apple.awt.CToolkit)toolkit).runningInHiDPI() ? SIMPLE_SCROLL_MODE : oldScrollMode);

                    oldScrollMode = currentScrollMode;

                }

            }

        });

    }

There was no attempt to remove / cleanup the new property listener that is getting added, and it is causing the JVM to not garbage collect the objects associate with the JViewport being created. I found if I manually add the following code to my application, the memory leak is resolved, but it probably breaks their scrolling change since I’m just removing all of these listeners, even ones that are still in scope:

final Toolkit toolkit = Toolkit.getDefaultToolkit(); if (toolkit instanceof apple.awt.CToolkit) { PropertyChangeListener[] leak = toolkit.getPropertyChangeListeners(“apple.awt.contentScaleFactor”); for(int i=0; i<leak.length; i++){ toolkit.removePropertyChangeListener("apple.awt.contentScaleFactor",leak[i]); } }

I filed a Radar bug #10473138 for this, hopefully Apple will fix it, but at least I have a workaround now.

I’ve confirmed that 1.6.0_29 on Windows does not have the problem, only Mac. Fortunately for me I have very few users of my application on Mac, and have been able to help them manually roll back their Java version until we can find a proper solution. I’ve chased down and fixed memory leaks before, but I can’t find anything that I’m doing to cause this one. Seems to be rooted in a pretty similar path as your post shows, AppContext -> property change listener -> JViewport.

If I find a solution, I’ll try to post it back on your blog in case others are looking for it.

Glad to see your post, I was starting to wonder if I was the only one who’d encountered this issue!

I had just installed Mac OS X 10.7 Lion. When I clicked on the DrJava icon, my MacBook Pro asked me to download Java. After doing that and installing it, DrJava worked.

Could you please send an email to drjava at rice dot edu (change at to @ and dot to .) with as much system information as you can provide? That way, other developers of DrJava can try to help you too.

Thanks!

What are the exact things you did when you first used DrJava? My DrJava merely shows the logo then nothing happens when I open it even after downloading Java. :(

Any help would be hugely appreciated!