Visualvm is not satisfied with icedtea-bin, but installing all of it's deps then doing `emerge --nodeps visualvm` on it seems to produce a fully functional version. emerge --info: https://gist.github.com/2867053
Visualvm also works with proprietary JDKs, at least it should. The problem is the ebuild format not allowing to keep the built against / all available JDK around without resorting to useflags or limit it to a single one in DEPEND. Also the binary JDKs ship with jvisualvm, therefore it's one of the run-java-tool tools and so the symlinking into icedteas JAVA_HOME needs to be well defined. Current approach: ----------------- Pros: * jvisualvm if icedtea is selected as vm behaves the same as for proprietary JDKs * no dep cycles between icedtea and visualvm. Cons: * there is one visualvm ebuild per JDK and version -> revision abuse, funky-slots * maintenance overhead * if JDK is not explicitly supported it wont work Alternative approach: --------------------- * allow any jdk >=1.6, detect active vm and if necessary do vm switching at runtime. * rename launcher to visualvm to not to collide with run-java-tool. * no symlinking into JDK_HOMEs to prevent cycles or broken symlinks. Pros: * less maintenance. * visualvm is a package in it's own right, and the proprietary JDKs just happen to bundle it. * things like icedtea-cacao-headless as other distributions do could be supported. Cons: * jvisualvm will report no such tool for icedtea if icedtea is selected. Users must use visualvm command instead. The alternative approach has it's own issues but would allow visualvm to be used with quite some more JDK packages than today while reducing maintenance burden at the same time.
with the latest bump visualvm now does not depend on any specific jdk, just >=virtual/jdk-1.7
