Because they are internal APIs: they are subject to change in a undocumented or unsupported way and they are bound to a specific JRE/JDK (Sun in your case), limiting portability of your programs. Try to avoid uses of such APIs, always prefer a public documented and specified class.
Just an idea: NIO buffers are placed outside the JVM. EDIT: As per 2016 it’s worth considering @Lari Hotari comment [ Why does the Sun JVM continue to consume ever more RSS memory even when the heap, etc sizes are stable? ] because back to 2009, RHEL4 had glibc < 2.10 (~2.3) Regards.
Why don’t they write a new VM for a new language? That one is easy: writing a good VM is hard writing a fast VM is hard making a VM run under multiple architectures is hard existing libraries work with existing VMs existing tools (debuggers, profilers, compilers, …) work with existing VMs getting people to … Read more
Here you can find all sorts of old download links. JDK, JRE, and even different libraries! http://www.oracle.com/technetwork/java/archive-139210.html
As you will find repeated ad infinitum when learning about signal handling in Java, you are encouraged to avoid writing Java code that depends directly on signals. The general best practice is to allow the JVM to exit normally on ctrl+c and other signals by registering a shutdown hook instead. Handling signals directly makes your … Read more
Thanks for the suggestions. I finally found a solution to this problem after reading this. It turns out that these dependencies were coming from a dependency to ZooKeeper. I modified my pom.xml as following and it solved the problem: <dependency> <groupId>org.apache.zookeeper</groupId> <artifactId>zookeeper</artifactId> <version>3.3.2</version> <exclusions> <exclusion> <groupId>com.sun.jmx</groupId> <artifactId>jmxri</artifactId> </exclusion> <exclusion> <groupId>com.sun.jdmk</groupId> <artifactId>jmxtools</artifactId> </exclusion> <exclusion> <groupId>javax.jms</groupId> <artifactId>jms</artifactId> … Read more
The only difference between com.sun.jersey and org.glassfish.jersey is that the package name was changed because Jersey team is now part of another organization (Glassfish). Versions below 2 use package com.sun.jersey, versions above 2 use org.glassfish.jersey. And yes, there are some differences between 1.x and 2.x.