Hi Brad,
I use the DevStudio IDE [1] (which builds on top of NetBeans) as my default IDE
and I use the project files for JVM development. I'm not sure exactly what your
question is, but at least to me it is convenient to have the project already
there, configured and ready to go every time I
Jesper,
This is not a review comment, but could you tell us how these netbeans
projects are supposed to be used? To do my JDK debugging, I usually
create an exploded JDK build using the normal make files, then in
Netbeans created a new platform that pointed at the build/*/jdk
directory,
Hello,
This review should be sent to the beans-dev mailing list. The build-dev
mailing list is for issues concerning building OpenJDK.
(I can't forward since I'm not a member of the beans-dev list)
/Erik
On 2016-06-29 20:04, Lukáš Kvídera wrote:
I think I have found a solution for a bug
I think I have found a solution for a bug JDK-8071693.
The problem is the Introspector does scan only in super classes and does not
know about default methods.
I just added condition method.isDefault() and manual testing proves my idea
does work. I did NOT run junit tests.
Can you please
Erik:
In JDK-8160285 I tried to fix the bootcycle build on 32bit windows
when only the server jvm is being built. It appears I only verified
the fix on a release build. In my JPRT job I forgot to enable only the
server jvm so it ran with client.
We are now faced with more similar failures
In JDK-8160285 I tried to fix the bootcycle build on 32bit windows when
only the server jvm is being built. It appears I only verified the fix
on a release build. In my JPRT job I forgot to enable only the server
jvm so it ran with client.
We are now faced with more similar failures in the
I suspect it's another instance of
https://bugs.openjdk.java.net/browse/JDK-8158629
/Erik
On 2016-06-29 16:55, Jim Laskey (Oracle) wrote:
After a clean got
dtrace: failed to compile script
After a clean got
dtrace: failed to compile script
/Projects/jdk9-dev/build/macosx-x86_64-normal-server-fastdebug/hotspot/variant-server/support/dtrace/hotspot_jni.h.d:
line 1: empty D program translation unit
second time worked fine.
Sundar, Erik:
Looks good
Yes, nashorn will not get any native tests.
-Sundar
On 6/29/2016 4:25 PM, Erik Joelsson wrote:
Looks ok to me.
Thank you for the reviews.
It's unlikely that nashorn will ever get native tests so just removing
this functionality is a good solution. If we expected
Hello,
A while ago, in JDK-8155689, a workaround was put in place because a
temporary broken Jib configuration file. The Jib configuration has since
been fixed and the workaround can now safely be removed.
Bug: https://bugs.openjdk.java.net/browse/JDK-8160490
Patch:
diff -r 20f1ee2fe834
Looks good
Yes, nashorn will not get any native tests.
-Sundar
On 6/29/2016 4:25 PM, Erik Joelsson wrote:
> Looks ok to me.
>
> It's unlikely that nashorn will ever get native tests so just removing
> this functionality is a good solution. If we expected nashorn to need
> native tests anytime
Looks ok to me.
It's unlikely that nashorn will ever get native tests so just removing
this functionality is a good solution. If we expected nashorn to need
native tests anytime soon, it would likely be better to just create a
placeholder directory in the test image instead.
/Erik
On
12 matches
Mail list logo
