This is just normal way of thinking. :)
Thanks,
Serguei
On 9/16/16 07:37, Daniel D. Daugherty wrote:
Going down the JNI rabbit hole is my fault. When I mumbled on
2016-09-02 about
how this bug might be fixed, I was too focused on the fact that the
JNI layer
didn't do what we want and I talked
Hi Dan,
Thanks, but your comments were very helpful.
Harold
On 9/16/2016 10:37 AM, Daniel D. Daugherty wrote:
Going down the JNI rabbit hole is my fault. When I mumbled on
2016-09-02 about
how this bug might be fixed, I was too focused on the fact that the
JNI layer
didn't do what we want an
The xml/xsl source files used to generate sources for trace in hotspot
have hard coded relative paths in them that make assumptions on where
the oracle closed files are located. The source files should not make
these kind of assumptions since that makes it difficult to change the
repository lay
Going down the JNI rabbit hole is my fault. When I mumbled on 2016-09-02
about
how this bug might be fixed, I was too focused on the fact that the JNI
layer
didn't do what we want and I talked about how to fix it using JNI functions.
Harold, my apologies for wasting your time.
Dan
On 9/16/16
Hi Serguei,
Thanks for the suggestion! That provides a much cleaner implementation.
Harold
On 9/15/2016 11:28 PM, serguei.spit...@oracle.com wrote:
On 9/15/16 19:13, David Holmes wrote:
On 16/09/2016 8:52 AM, serguei.spit...@oracle.com wrote:
Hi Harold,
I did not got deep into the fix yet
Dmitry, here is how I see this situation: When we ran
sun/tools/jps/TestJpsJar.java alone in the clean folder, it builds
testlibrary classes implicitly and put it under the same folder with
test class, i.e. to JTwork/classes/sun/tools/jps folder and test works fine.
But sun/tools/jinfo/BasicJInf
I tried to do some experiments from my side to check if this issue could be
hit, but I could not successfully do anything. As per the discussion in this
thread, I will close the bug as 'not an issue'. Thanks all for the inputs.
-Sharath Ballal
-Original Message-
From: Dmitry Samerso
