Hi Fred,
Looks okay to me too. But I wouldn't be surprised if there is some test
somewhere that checks for things when PrintJVMWarnings is set :)
David
On 7/10/2014 12:32 AM, Frederic Parain wrote:
Thank you very much for catching the JVM_O_DELETE issue.
I moved the O_DELETE support into the ZipFile.c file
(code was the same for all non-Windows platforms) and
cleaned up the original code in HotSpot.
The new webrevs:
http://cr.openjdk.java.net/~fparain/8057777/jdk_v03/
http://cr.openjdk.java.net/~fparain/8057777/hotspot_v03/
Regards,
Fred
On 10/03/2014 06:07 PM, Xueming Shen wrote:
On 10/3/14 8:19 AM, Alan Bateman wrote:
On 30/09/2014 07:40, Hideric Parain wrote:
Hi all,
Please review changes for bug JDK-8057777 "Cleanup of old
and unused VM interfaces"
CR:
https://bugs.openjdk.java.net/browse/JDK-8057777
This is basically a big cleanup of VM interfaces that are
not used anymore by the JDK but have been kept in our code
base for historical reasons (HotSpot Express for instance).
These changesets remove these interfaces from both the
JDK and the HotSpot side, and also perform some cleanup
on code that directly referenced the removed interfaces.
These changes do not modify the behavior of the Java
classes impacted by the cleanup.
VM interfaces removal has been approved by CCC and
a Release Note has been prepared that explicitly list
all the removed interfaces.
Testing: JPRT hotspot + core, vm.quick.testlist, jdk_core
Webrevs:
http://cr.openjdk.java.net/~fparain/8057777/
cc'ing core-libs-dev as part of this is clean-up in the library code
too.
I think we should deprecate java.lang.Compiler and the
Runtime.traceXXX methods. They've been non-functional for a long time
and having them in the API is a bit mis-leading to anyone reading the
javadoc. I realize you are focused on the removing the old JVM_*
functions so we can follow-up on that via other issues of course.
Can ClassLoader#resolveClass0 can be removed completely? The null
check can be done in ClassLoader#resolveClass.
In the mapfile for libjava then the comment at line 281 says
"ZipFile.c needs this one". As getLastErrorString is now exported for
use by libzip then the comment should probably be updated.
Otherwise this clean-up looks good to me and the jdk_core group of
tests is the right group to exercise this area.
-Alan
Hi,
ZipFile.c expects the JVM_Open() to handle the JVM_O_DELETE, with
explicit unlink on linux/solaris for example.
I would assume the open from the c library does not handle it and we
need to do it explicitly by ZipFile.c now?
-Sherman
