Re: Problem accessing jfx native libs under eclipse on windows
At least for the OpenJFX without media/webkit Cygwin is used only for
path manipulation (cygpath) so I don't think dropping it will boost
performance at all.
In fact, I just did a quick test and built OpenJFX without cygwin at all
(modifying build.gradle so it will not call cygpath).
Visual Studio is the only viable option for Windows development.
When I was actively developing native Windows code, I created my own VS
project which can build native dlls just fine without even calling
gradle and that was huge productivity boost.
Thanks,
Vadim
On 29.10.2014 18:05, Chris Bensen wrote:
+1 Visual Studio provides the best debugger and losing that would be very sad.
If we didn’t require Cygwin the build would also be faster!
Chris
On Oct 24, 2014, at 9:00 PM, Scott Palmer swpal...@gmail.com wrote:
Jettisoning the MS tools would be a bad idea. The Visual Studio compiler or the
Intel compiler are really the only reasonable options for building native code
on Windows. I'm not aware of any professional programmer that uses GCC on
Windows... Not because GCC is bad, the Windows ports just aren't capable of
compiling against a real Windows SDK. The MinGW tools come with their own
headers to try to work around this, but the last time I checked, it just didn't
work well enough.
That said,I think the right approach in the long term is to move the build to
use Gradle's support for C and C++. It supports the MS compiler as well as
MinGW on Windows and all the popular compilers on other platforms. If we
combined that with the ability to build just the 32bit JDK when running with
the MS compiler, it would offer a decent solution for those using free tools on
Windows.
Another goal should be to remove the requirement for Cygwin as it can cause its
own set of problems. I'm not sure what it is used for that can't be done with
Gradle and/or pure java libraries directly.
Scott
On Oct 24, 2014, at 2:05 PM, Richard Steiger rstei...@ensemblesoft.net wrote:
Stephen,
Sorry for the mis-communication: in my original message, I was able to do
incremental java compilation, but hadn't tried to do the full build, since
hadn't made changes to any of the native code. Your reply straighted me out,
that I need to be doing full builds to pick-up changes in either the cpp or
low-level java code. I haven't been able to get the native builds to work,
without it failing in either the cpp compiler or linker.
I still could use a hand to get working tooling.
Also, care to comment whether there's any plan to jetisson the MS tools in the
openjfx project, or at least align it with openjdk9's build system?
Thanks,
-rjs
On 10/24/2014 10:43 AM, Stephen F Northover wrote:
Hi Richard,
Your previous email indicated that you could build, but that you can't see the
shared libraries.
Please try adding this the VM Arguments of your Eclipse launch configuration:
-Djava.library.path=${workspace_loc:rt}/build/sdk/rt/bin
-Djavafx.verbose=true
Thanks,
Steve
On 2014-10-24, 1:31 PM, Richard Steiger wrote:
To recap a message I sent to the list on 9/12, I'm a newbie to JavaFX, and
hoping to be able to contribute, initially fixing bugs.
Stephen, I'm attempting to follow the instructions at:
https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE, and have found that
the Visual Studio tools it calls out don't include the amd64 tools, have
struggled to adapt win.gradle to VS 2011, and otherwise dulled my pick. Also,
when comparing the above instructions to openjdk9's build setup, I'm also
wondering whether someone's revised the openjfx win build to use gcc, MinGW,
Code::Blocks, clang++, or any other toolset besides the MS crud.
Rather than dragging y'all through the blow-by-blow challenges I've been
getting hit with, what I'm hoping is that one of you who's actively developing
on a 64-bit Windows 7+ environment is willing to lend a hand to get me set-up
with a working rig. Please reply to just me if you're willing to help, I think
I just need a few minutes here and there to pick the right tools, verify I'm
working against the correct repo, etc.
Thanks in advance,
-rjs
On 9/12/2014 2:40 PM, Stephen F Northover wrote:
Hi Richard,
Did you follow the instructions at this link:
https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE ?
You are picking up a set of shared libraries that do not match the java code
you are running in the IDE. You need to set java.library.path. It's on the
wiki and I meant to update it to be something sensible. My build puts the
dll's in an artifacts directory:
-Djava.library.path=${workspace_loc:rt}/../artifacts/sdk/rt/bin
You will need to edit this expression to pick up the dll's from the standard
build place (which I forget right now).
Steve
On 2014-09-12, 5:31 PM, Richard Steiger wrote:
I'm a newbie to JavaFX, and hoping to be able to contribute down the road once
I learn much more about it.
To that end, I've been trying to get 8u-dev eclipse
Re: Problem accessing jfx native libs under eclipse on windows
If cygpath isn't needed and that's all cygwin was used for, and you already
modified build.gradle to avoid the cygpath calls What's stopping you
for checking that in so the cygwin requirement for OpenJFX can be dropped?
The Gradle C/C++ support includes a method for creating a VS project from
the Gradle source (since Gradle 1.11, see
http://www.gradle.org/docs/1.11/release-notes#generate-visual-studio-configuration-for-a-native-binary-project).
So you should be able to get that productivity boost without having to roll
your own project files and maintain them.
Scott
On Wed, Oct 29, 2014 at 12:04 PM, Vadim Pakhnushev
vadim.pakhnus...@oracle.com wrote:
At least for the OpenJFX without media/webkit Cygwin is used only for path
manipulation (cygpath) so I don't think dropping it will boost performance
at all.
In fact, I just did a quick test and built OpenJFX without cygwin at all
(modifying build.gradle so it will not call cygpath).
Visual Studio is the only viable option for Windows development.
When I was actively developing native Windows code, I created my own VS
project which can build native dlls just fine without even calling gradle
and that was huge productivity boost.
Thanks,
Vadim
On 29.10.2014 18:05, Chris Bensen wrote:
+1 Visual Studio provides the best debugger and losing that would be very
sad.
If we didn’t require Cygwin the build would also be faster!
Chris
On Oct 24, 2014, at 9:00 PM, Scott Palmer swpal...@gmail.com wrote:
Jettisoning the MS tools would be a bad idea. The Visual Studio compiler
or the Intel compiler are really the only reasonable options for building
native code on Windows. I'm not aware of any professional programmer that
uses GCC on Windows... Not because GCC is bad, the Windows ports just
aren't capable of compiling against a real Windows SDK. The MinGW tools
come with their own headers to try to work around this, but the last time I
checked, it just didn't work well enough.
That said,I think the right approach in the long term is to move the
build to use Gradle's support for C and C++. It supports the MS compiler as
well as MinGW on Windows and all the popular compilers on other platforms.
If we combined that with the ability to build just the 32bit JDK when
running with the MS compiler, it would offer a decent solution for those
using free tools on Windows.
Another goal should be to remove the requirement for Cygwin as it can
cause its own set of problems. I'm not sure what it is used for that can't
be done with Gradle and/or pure java libraries directly.
Scott
On Oct 24, 2014, at 2:05 PM, Richard Steiger rstei...@ensemblesoft.net
wrote:
Stephen,
Sorry for the mis-communication: in my original message, I was able to
do incremental java compilation, but hadn't tried to do the full build,
since hadn't made changes to any of the native code. Your reply straighted
me out, that I need to be doing full builds to pick-up changes in either
the cpp or low-level java code. I haven't been able to get the native
builds to work, without it failing in either the cpp compiler or linker.
I still could use a hand to get working tooling.
Also, care to comment whether there's any plan to jetisson the MS tools
in the openjfx project, or at least align it with openjdk9's build system?
Thanks,
-rjs
On 10/24/2014 10:43 AM, Stephen F Northover wrote:
Hi Richard,
Your previous email indicated that you could build, but that you can't
see the shared libraries.
Please try adding this the VM Arguments of your Eclipse launch
configuration:
-Djava.library.path=${workspace_loc:rt}/build/sdk/rt/bin
-Djavafx.verbose=true
Thanks,
Steve
On 2014-10-24, 1:31 PM, Richard Steiger wrote:
To recap a message I sent to the list on 9/12, I'm a newbie to
JavaFX, and hoping to be able to contribute, initially fixing bugs.
Stephen, I'm attempting to follow the instructions at:
https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE, and have
found that the Visual Studio tools it calls out don't include the amd64
tools, have struggled to adapt win.gradle to VS 2011, and otherwise
dulled
my pick. Also, when comparing the above instructions to openjdk9's
build
setup, I'm also wondering whether someone's revised the openjfx win build
to use gcc, MinGW, Code::Blocks, clang++, or any other toolset besides
the
MS crud.
Rather than dragging y'all through the blow-by-blow challenges I've
been getting hit with, what I'm hoping is that one of you who's actively
developing on a 64-bit Windows 7+ environment is willing to lend a hand
to
get me set-up with a working rig. Please reply to just me if you're
willing
to help, I think I just need a few minutes here and there to pick the
right
tools, verify I'm working against the correct repo, etc.
Thanks in advance,
-rjs
On 9/12/2014 2:40 PM, Stephen F Northover wrote:
Hi Richard,
Did you follow the instructions at this link:
Re: Problem accessing jfx native libs under eclipse on windows
Hi Scott,
It would be fine if developers were able to build (at least everything
but native media and webkit) without needing Cygwin -- as long as still
builds *with* Cygwin. Our official build environment -- meaning the one
that we use for build our production builds -- uses Cygwin on Windows
platforms. We are not likely to change this.
So if someone has a robust patch that enables developers to build
without needing cygwin, meaning is doesn't impact anyone using Cygwin,
we could consider taking it.
As for upgrading gradle to a newer version, that is not something we
would do lightly. We are unlikely in the JDK 8u time frame to move past
gradle 1.8, but could consider it for JDK 9.
-- Kevin
Scott Palmer wrote:
If cygpath isn't needed and that's all cygwin was used for, and you already
modified build.gradle to avoid the cygpath calls What's stopping you
for checking that in so the cygwin requirement for OpenJFX can be dropped?
The Gradle C/C++ support includes a method for creating a VS project from
the Gradle source (since Gradle 1.11, see
http://www.gradle.org/docs/1.11/release-notes#generate-visual-studio-configuration-for-a-native-binary-project).
So you should be able to get that productivity boost without having to roll
your own project files and maintain them.
Scott
On Wed, Oct 29, 2014 at 12:04 PM, Vadim Pakhnushev
vadim.pakhnus...@oracle.com wrote:
At least for the OpenJFX without media/webkit Cygwin is used only for path
manipulation (cygpath) so I don't think dropping it will boost performance
at all.
In fact, I just did a quick test and built OpenJFX without cygwin at all
(modifying build.gradle so it will not call cygpath).
Visual Studio is the only viable option for Windows development.
When I was actively developing native Windows code, I created my own VS
project which can build native dlls just fine without even calling gradle
and that was huge productivity boost.
Thanks,
Vadim
On 29.10.2014 18:05, Chris Bensen wrote:
+1 Visual Studio provides the best debugger and losing that would be very
sad.
If we didn’t require Cygwin the build would also be faster!
Chris
On Oct 24, 2014, at 9:00 PM, Scott Palmer swpal...@gmail.com wrote:
Jettisoning the MS tools would be a bad idea. The Visual Studio compiler
or the Intel compiler are really the only reasonable options for building
native code on Windows. I'm not aware of any professional programmer that
uses GCC on Windows... Not because GCC is bad, the Windows ports just
aren't capable of compiling against a real Windows SDK. The MinGW tools
come with their own headers to try to work around this, but the last time I
checked, it just didn't work well enough.
That said,I think the right approach in the long term is to move the
build to use Gradle's support for C and C++. It supports the MS compiler as
well as MinGW on Windows and all the popular compilers on other platforms.
If we combined that with the ability to build just the 32bit JDK when
running with the MS compiler, it would offer a decent solution for those
using free tools on Windows.
Another goal should be to remove the requirement for Cygwin as it can
cause its own set of problems. I'm not sure what it is used for that can't
be done with Gradle and/or pure java libraries directly.
Scott
On Oct 24, 2014, at 2:05 PM, Richard Steiger rstei...@ensemblesoft.net
wrote:
Stephen,
Sorry for the mis-communication: in my original message, I was able to
do incremental java compilation, but hadn't tried to do the full build,
since hadn't made changes to any of the native code. Your reply straighted
me out, that I need to be doing full builds to pick-up changes in either
the cpp or low-level java code. I haven't been able to get the native
builds to work, without it failing in either the cpp compiler or linker.
I still could use a hand to get working tooling.
Also, care to comment whether there's any plan to jetisson the MS tools
in the openjfx project, or at least align it with openjdk9's build system?
Thanks,
-rjs
On 10/24/2014 10:43 AM, Stephen F Northover wrote:
Hi Richard,
Your previous email indicated that you could build, but that you can't
see the shared libraries.
Please try adding this the VM Arguments of your Eclipse launch
configuration:
-Djava.library.path=${workspace_loc:rt}/build/sdk/rt/bin
-Djavafx.verbose=true
Thanks,
Steve
On 2014-10-24, 1:31 PM, Richard Steiger wrote:
To recap a message I sent to the list on 9/12, I'm a newbie to
JavaFX, and hoping to be able to contribute, initially fixing bugs.
Stephen, I'm attempting to follow the instructions at:
https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE, and have
found that the Visual Studio tools it calls out don't include the amd64
tools, have struggled to adapt win.gradle to VS 2011, and otherwise dulled
my pick. Also, when comparing the above instructions to openjdk9's build
setup, I'm also wondering
Re: Problem accessing jfx native libs under eclipse on windows
Unfortunately, gradle detects Cygwin and modifies JAVA_HOME environment
variable preventing using it without cygpath later on.
https://issues.gradle.org/browse/GRADLE-2673
So this will break building from Cygwin.
Vadim
On 29.10.2014 20:59, Scott Palmer wrote:
If cygpath isn't needed and that's all cygwin was used for, and you
already modified build.gradle to avoid the cygpath calls What's
stopping you for checking that in so the cygwin requirement for
OpenJFX can be dropped?
The Gradle C/C++ support includes a method for creating a VS project
from the Gradle source (since Gradle 1.11, see
http://www.gradle.org/docs/1.11/release-notes#generate-visual-studio-configuration-for-a-native-binary-project).
So you should be able to get that productivity boost without having to
roll your own project files and maintain them.
Scott
On Wed, Oct 29, 2014 at 12:04 PM, Vadim Pakhnushev
vadim.pakhnus...@oracle.com mailto:vadim.pakhnus...@oracle.com wrote:
At least for the OpenJFX without media/webkit Cygwin is used only
for path manipulation (cygpath) so I don't think dropping it will
boost performance at all.
In fact, I just did a quick test and built OpenJFX without cygwin
at all (modifying build.gradle so it will not call cygpath).
Visual Studio is the only viable option for Windows development.
When I was actively developing native Windows code, I created my
own VS project which can build native dlls just fine without even
calling gradle and that was huge productivity boost.
Thanks,
Vadim
On 29.10.2014 18:05, Chris Bensen wrote:
+1 Visual Studio provides the best debugger and losing that
would be very sad.
If we didn’t require Cygwin the build would also be faster!
Chris
On Oct 24, 2014, at 9:00 PM, Scott Palmer swpal...@gmail.com
mailto:swpal...@gmail.com wrote:
Jettisoning the MS tools would be a bad idea. The Visual
Studio compiler or the Intel compiler are really the only
reasonable options for building native code on Windows.
I'm not aware of any professional programmer that uses GCC
on Windows... Not because GCC is bad, the Windows ports
just aren't capable of compiling against a real Windows
SDK. The MinGW tools come with their own headers to try to
work around this, but the last time I checked, it just
didn't work well enough.
That said,I think the right approach in the long term is
to move the build to use Gradle's support for C and C++.
It supports the MS compiler as well as MinGW on Windows
and all the popular compilers on other platforms. If we
combined that with the ability to build just the 32bit JDK
when running with the MS compiler, it would offer a decent
solution for those using free tools on Windows.
Another goal should be to remove the requirement for
Cygwin as it can cause its own set of problems. I'm not
sure what it is used for that can't be done with Gradle
and/or pure java libraries directly.
Scott
On Oct 24, 2014, at 2:05 PM, Richard Steiger
rstei...@ensemblesoft.net
mailto:rstei...@ensemblesoft.net wrote:
Stephen,
Sorry for the mis-communication: in my original
message, I was able to do incremental java
compilation, but hadn't tried to do the full build,
since hadn't made changes to any of the native code.
Your reply straighted me out, that I need to be doing
full builds to pick-up changes in either the cpp or
low-level java code. I haven't been able to get the
native builds to work, without it failing in either
the cpp compiler or linker.
I still could use a hand to get working tooling.
Also, care to comment whether there's any plan to
jetisson the MS tools in the openjfx project, or at
least align it with openjdk9's build system?
Thanks,
-rjs
On 10/24/2014 10:43 AM, Stephen F Northover wrote:
Hi Richard,
Your previous email indicated that you could
build, but that you can't see the shared libraries.
Please try adding this the VM Arguments of your
Eclipse launch configuration:
-Djava.library.path=${workspace_loc:rt}/build/sdk/rt/bin
-Djavafx.verbose=true
Thanks,
Steve
On 2014-10-24, 1:31 PM, Richard Steiger wrote:
To recap a message
Re: Problem accessing jfx native libs under eclipse on windows
I think the fix for this is as simple as:
diff -r 93f42b396c81 build.gradle
--- a/build.gradleWed Oct 29 09:25:31 2014 +0300
+++ b/build.gradleThu Oct 30 00:27:59 2014 +0300
@@ -113,10 +113,13 @@
if (path == null || .equals(path)) return path;
ByteArrayOutputStream out = new ByteArrayOutputStream();
logger.info(Converting path '$path' via cygpath)
-exec {
+def res = exec {
+ignoreExitValue = true
standardOutput = out
commandLine cmd, /c, cygpath, -m, path
}
+// if cygpath failed then we are running without cygwin?
+if (res.exitValue != 0) return path;
return out.toString().trim();
}
This will effectively bypass cygpath calls and will enable to build at
least OpenJFX without Cygwin while not breaking anything running from
Cygwin.
Vadim
On 29.10.2014 21:51, Vadim Pakhnushev wrote:
Unfortunately, gradle detects Cygwin and modifies JAVA_HOME
environment variable preventing using it without cygpath later on.
https://issues.gradle.org/browse/GRADLE-2673
So this will break building from Cygwin.
Vadim
On 29.10.2014 20:59, Scott Palmer wrote:
If cygpath isn't needed and that's all cygwin was used for, and you
already modified build.gradle to avoid the cygpath calls What's
stopping you for checking that in so the cygwin requirement for
OpenJFX can be dropped?
The Gradle C/C++ support includes a method for creating a VS project
from the Gradle source (since Gradle 1.11, see
http://www.gradle.org/docs/1.11/release-notes#generate-visual-studio-configuration-for-a-native-binary-project).
So you should be able to get that productivity boost without having
to roll your own project files and maintain them.
Scott
On Wed, Oct 29, 2014 at 12:04 PM, Vadim Pakhnushev
vadim.pakhnus...@oracle.com mailto:vadim.pakhnus...@oracle.com
wrote:
At least for the OpenJFX without media/webkit Cygwin is used only
for path manipulation (cygpath) so I don't think dropping it will
boost performance at all.
In fact, I just did a quick test and built OpenJFX without cygwin
at all (modifying build.gradle so it will not call cygpath).
Visual Studio is the only viable option for Windows development.
When I was actively developing native Windows code, I created my
own VS project which can build native dlls just fine without even
calling gradle and that was huge productivity boost.
Thanks,
Vadim
On 29.10.2014 18:05, Chris Bensen wrote:
+1 Visual Studio provides the best debugger and losing that
would be very sad.
If we didn’t require Cygwin the build would also be faster!
Chris
On Oct 24, 2014, at 9:00 PM, Scott Palmer swpal...@gmail.com
mailto:swpal...@gmail.com wrote:
Jettisoning the MS tools would be a bad idea. The Visual
Studio compiler or the Intel compiler are really the only
reasonable options for building native code on Windows.
I'm not aware of any professional programmer that uses GCC
on Windows... Not because GCC is bad, the Windows ports
just aren't capable of compiling against a real Windows
SDK. The MinGW tools come with their own headers to try to
work around this, but the last time I checked, it just
didn't work well enough.
That said,I think the right approach in the long term is
to move the build to use Gradle's support for C and C++.
It supports the MS compiler as well as MinGW on Windows
and all the popular compilers on other platforms. If we
combined that with the ability to build just the 32bit JDK
when running with the MS compiler, it would offer a decent
solution for those using free tools on Windows.
Another goal should be to remove the requirement for
Cygwin as it can cause its own set of problems. I'm not
sure what it is used for that can't be done with Gradle
and/or pure java libraries directly.
Scott
On Oct 24, 2014, at 2:05 PM, Richard Steiger
rstei...@ensemblesoft.net
mailto:rstei...@ensemblesoft.net wrote:
Stephen,
Sorry for the mis-communication: in my original
message, I was able to do incremental java
compilation, but hadn't tried to do the full build,
since hadn't made changes to any of the native code.
Your reply straighted me out, that I need to be doing
full builds to pick-up changes in either the cpp or
low-level java code. I haven't been able to get the
native builds to work, without it failing in either
the cpp compiler or linker.
I still could use a hand to get working tooling.
Also, care to comment
Re: Problem accessing jfx native libs under eclipse on windows
Hi Richard,
Your previous email indicated that you could build, but that you can't
see the shared libraries.
Please try adding this the VM Arguments of your Eclipse launch
configuration:
-Djava.library.path=${workspace_loc:rt}/build/sdk/rt/bin
-Djavafx.verbose=true
Thanks,
Steve
On 2014-10-24, 1:31 PM, Richard Steiger wrote:
To recap a message I sent to the list on 9/12, I'm a newbie to JavaFX,
and hoping to be able to contribute, initially fixing bugs.
Stephen, I'm attempting to follow the instructions at:
https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE, and have
found that the Visual Studio tools it calls out don't include the
amd64 tools, have struggled to adapt win.gradle to VS 2011, and
otherwise dulled my pick. Also, when comparing the above
instructions to openjdk9's build setup, I'm also wondering whether
someone's revised the openjfx win build to use gcc, MinGW,
Code::Blocks, clang++, or any other toolset besides the MS crud.
Rather than dragging y'all through the blow-by-blow challenges I've
been getting hit with, what I'm hoping is that one of you who's
actively developing on a 64-bit Windows 7+ environment is willing to
lend a hand to get me set-up with a working rig. Please reply to just
me if you're willing to help, I think I just need a few minutes here
and there to pick the right tools, verify I'm working against the
correct repo, etc.
Thanks in advance,
-rjs
On 9/12/2014 2:40 PM, Stephen F Northover wrote:
Hi Richard,
Did you follow the instructions at this link:
https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE ?
You are picking up a set of shared libraries that do not match the
java code you are running in the IDE. You need to set
java.library.path. It's on the wiki and I meant to update it to be
something sensible. My build puts the dll's in an artifacts directory:
-Djava.library.path=${workspace_loc:rt}/../artifacts/sdk/rt/bin
You will need to edit this expression to pick up the dll's from the
standard build place (which I forget right now).
Steve
On 2014-09-12, 5:31 PM, Richard Steiger wrote:
I'm a newbie to JavaFX, and hoping to be able to contribute down the
road once I learn much more about it.
To that end, I've been trying to get 8u-dev eclipse projects setup
on a Win7 box so I can start stepping through the code. The current
show-stopper is getting UnsatisfiedLinkErrors when the system is
trying to access dlls, such as glass.dll.
My rig:
* jdk1.8.0_05
* eclipse-SDK-N20140722-2000-win32-x86_64 (Mars stable build, has fix
for StackOverflow bug in eclipse j8 compiler)
* hg clone of 8u-dev as of 8/26
Setup:
* ran the gradle build (successfully)
* imported the eclipse projects in the repo, all cleanly compile (but
had to fix cross-project links and manually locate and attach 3p
libs)
* removed javafx.* and related JavaFX sources from JAVA_HOME/src
* moved jfxrt.jar to a cache directory
Failure situation:
* attempting to launch jfx apps under eclipse debugger
The following console output is typical of what I'm running into
(with -verbose:jni on the command line):
[Dynamic-linking native method java.lang.Object.registerNatives ...
JNI]
[Registering JNI native method java.lang.Object.hashCode]
[Registering JNI native method java.lang.Object.wait]
[Registering JNI native method java.lang.Object.notify]
[Registering JNI native method java.lang.Object.notifyAll]
[Registering JNI native method java.lang.Object.clone]
[Dynamic-linking native method java.lang.System.registerNatives ...
JNI]
[Registering JNI native method java.lang.System.currentTimeMillis]
[Registering JNI native method java.lang.System.nanoTime]
[Registering JNI native method java.lang.System.arraycopy]
[Dynamic-linking native method java.lang.Thread.registerNatives ...
JNI]
[Registering JNI native method java.lang.Thread.start0]
[Registering JNI native method java.lang.Thread.stop0]
[Registering JNI native method java.lang.Thread.isAlive]
[Registering JNI native method java.lang.Thread.suspend0]
[Registering JNI native method java.lang.Thread.resume0]
[Registering JNI native method java.lang.Thread.setPriority0]
[Registering JNI native method java.lang.Thread.yield]
[Registering JNI native method java.lang.Thread.sleep]
[Registering JNI native method java.lang.Thread.currentThread]
[Registering JNI native method java.lang.Thread.countStackFrames]
[Registering JNI native method java.lang.Thread.interrupt0]
[Registering JNI native method java.lang.Thread.isInterrupted]
[Registering JNI native method java.lang.Thread.holdsLock]
[Registering JNI native method java.lang.Thread.getThreads]
[Registering JNI native method java.lang.Thread.dumpThreads]
[Registering JNI native method java.lang.Thread.setNativeName]
[Dynamic-linking native method
java.security.AccessController.getStackAccessControlContext ... JNI]
[Dynamic-linking native method
java.security.AccessController.getInheritedAccessControlContext ...
JNI]
Re: Problem accessing jfx native libs under eclipse on windows
Stephen,
Sorry for the mis-communication: in my original message, I was able to
do incremental java compilation, but hadn't tried to do the full build,
since hadn't made changes to any of the native code. Your reply
straighted me out, that I need to be doing full builds to pick-up
changes in either the cpp or low-level java code. I haven't been able
to get the native builds to work, without it failing in either the cpp
compiler or linker.
I still could use a hand to get working tooling.
Also, care to comment whether there's any plan to jetisson the MS tools
in the openjfx project, or at least align it with openjdk9's build system?
Thanks,
-rjs
On 10/24/2014 10:43 AM, Stephen F Northover wrote:
Hi Richard,
Your previous email indicated that you could build, but that you can't
see the shared libraries.
Please try adding this the VM Arguments of your Eclipse launch
configuration:
-Djava.library.path=${workspace_loc:rt}/build/sdk/rt/bin
-Djavafx.verbose=true
Thanks,
Steve
On 2014-10-24, 1:31 PM, Richard Steiger wrote:
To recap a message I sent to the list on 9/12, I'm a newbie to
JavaFX, and hoping to be able to contribute, initially fixing bugs.
Stephen, I'm attempting to follow the instructions at:
https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE, and have
found that the Visual Studio tools it calls out don't include the
amd64 tools, have struggled to adapt win.gradle to VS 2011, and
otherwise dulled my pick. Also, when comparing the above
instructions to openjdk9's build setup, I'm also wondering whether
someone's revised the openjfx win build to use gcc, MinGW,
Code::Blocks, clang++, or any other toolset besides the MS crud.
Rather than dragging y'all through the blow-by-blow challenges I've
been getting hit with, what I'm hoping is that one of you who's
actively developing on a 64-bit Windows 7+ environment is willing to
lend a hand to get me set-up with a working rig. Please reply to just
me if you're willing to help, I think I just need a few minutes here
and there to pick the right tools, verify I'm working against the
correct repo, etc.
Thanks in advance,
-rjs
On 9/12/2014 2:40 PM, Stephen F Northover wrote:
Hi Richard,
Did you follow the instructions at this link:
https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE ?
You are picking up a set of shared libraries that do not match the
java code you are running in the IDE. You need to set
java.library.path. It's on the wiki and I meant to update it to be
something sensible. My build puts the dll's in an artifacts directory:
-Djava.library.path=${workspace_loc:rt}/../artifacts/sdk/rt/bin
You will need to edit this expression to pick up the dll's from the
standard build place (which I forget right now).
Steve
On 2014-09-12, 5:31 PM, Richard Steiger wrote:
I'm a newbie to JavaFX, and hoping to be able to contribute down
the road once I learn much more about it.
To that end, I've been trying to get 8u-dev eclipse projects setup
on a Win7 box so I can start stepping through the code. The current
show-stopper is getting UnsatisfiedLinkErrors when the system is
trying to access dlls, such as glass.dll.
My rig:
* jdk1.8.0_05
* eclipse-SDK-N20140722-2000-win32-x86_64 (Mars stable build, has fix
for StackOverflow bug in eclipse j8 compiler)
* hg clone of 8u-dev as of 8/26
Setup:
* ran the gradle build (successfully)
* imported the eclipse projects in the repo, all cleanly compile (but
had to fix cross-project links and manually locate and attach 3p
libs)
* removed javafx.* and related JavaFX sources from JAVA_HOME/src
* moved jfxrt.jar to a cache directory
Failure situation:
* attempting to launch jfx apps under eclipse debugger
The following console output is typical of what I'm running into
(with -verbose:jni on the command line):
[Dynamic-linking native method java.lang.Object.registerNatives ...
JNI]
[Registering JNI native method java.lang.Object.hashCode]
[Registering JNI native method java.lang.Object.wait]
[Registering JNI native method java.lang.Object.notify]
[Registering JNI native method java.lang.Object.notifyAll]
[Registering JNI native method java.lang.Object.clone]
[Dynamic-linking native method java.lang.System.registerNatives ...
JNI]
[Registering JNI native method java.lang.System.currentTimeMillis]
[Registering JNI native method java.lang.System.nanoTime]
[Registering JNI native method java.lang.System.arraycopy]
[Dynamic-linking native method java.lang.Thread.registerNatives ...
JNI]
[Registering JNI native method java.lang.Thread.start0]
[Registering JNI native method java.lang.Thread.stop0]
[Registering JNI native method java.lang.Thread.isAlive]
[Registering JNI native method java.lang.Thread.suspend0]
[Registering JNI native method java.lang.Thread.resume0]
[Registering JNI native method java.lang.Thread.setPriority0]
[Registering JNI native method java.lang.Thread.yield]
[Registering JNI native method
Re: Problem accessing jfx native libs under eclipse on windows
On 2014-10-24, 2:05 PM, Richard Steiger wrote:
Stephen,
Sorry for the mis-communication: in my original message, I was able to
do incremental java compilation, but hadn't tried to do the full
build, since hadn't made changes to any of the native code. Your reply
straighted me out, that I need to be doing full builds to pick-up
changes in either the cpp or low-level java code. I haven't been able
to get the native builds to work, without it failing in either the cpp
compiler or linker.
You'll need to follow the recipe here precisely:
https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX
Do try to substitute anything or you will fail.
I still could use a hand to get working tooling.
Also, care to comment whether there's any plan to jetisson the MS
tools in the openjfx project, or at least align it with openjdk9's
build system?
We'll be running the same compilers that the JDK runs. There is some
work afoot to upgrade but this might only be possible in 9, and not 8udev.
https://javafx-jira.kenai.com/browse/RT-38475
Thanks,
-rjs
On 10/24/2014 10:43 AM, Stephen F Northover wrote:
Hi Richard,
Your previous email indicated that you could build, but that you
can't see the shared libraries.
Please try adding this the VM Arguments of your Eclipse launch
configuration:
-Djava.library.path=${workspace_loc:rt}/build/sdk/rt/bin
-Djavafx.verbose=true
Thanks,
Steve
On 2014-10-24, 1:31 PM, Richard Steiger wrote:
To recap a message I sent to the list on 9/12, I'm a newbie to
JavaFX, and hoping to be able to contribute, initially fixing bugs.
Stephen, I'm attempting to follow the instructions at:
https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE, and have
found that the Visual Studio tools it calls out don't include the
amd64 tools, have struggled to adapt win.gradle to VS 2011, and
otherwise dulled my pick. Also, when comparing the above
instructions to openjdk9's build setup, I'm also wondering whether
someone's revised the openjfx win build to use gcc, MinGW,
Code::Blocks, clang++, or any other toolset besides the MS crud.
Rather than dragging y'all through the blow-by-blow challenges I've
been getting hit with, what I'm hoping is that one of you who's
actively developing on a 64-bit Windows 7+ environment is willing to
lend a hand to get me set-up with a working rig. Please reply to
just me if you're willing to help, I think I just need a few minutes
here and there to pick the right tools, verify I'm working against
the correct repo, etc.
Thanks in advance,
-rjs
On 9/12/2014 2:40 PM, Stephen F Northover wrote:
Hi Richard,
Did you follow the instructions at this link:
https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE ?
You are picking up a set of shared libraries that do not match the
java code you are running in the IDE. You need to set
java.library.path. It's on the wiki and I meant to update it to be
something sensible. My build puts the dll's in an artifacts
directory:
-Djava.library.path=${workspace_loc:rt}/../artifacts/sdk/rt/bin
You will need to edit this expression to pick up the dll's from the
standard build place (which I forget right now).
Steve
On 2014-09-12, 5:31 PM, Richard Steiger wrote:
I'm a newbie to JavaFX, and hoping to be able to contribute down
the road once I learn much more about it.
To that end, I've been trying to get 8u-dev eclipse projects setup
on a Win7 box so I can start stepping through the code. The
current show-stopper is getting UnsatisfiedLinkErrors when the
system is trying to access dlls, such as glass.dll.
My rig:
* jdk1.8.0_05
* eclipse-SDK-N20140722-2000-win32-x86_64 (Mars stable build, has
fix
for StackOverflow bug in eclipse j8 compiler)
* hg clone of 8u-dev as of 8/26
Setup:
* ran the gradle build (successfully)
* imported the eclipse projects in the repo, all cleanly compile
(but
had to fix cross-project links and manually locate and attach
3p libs)
* removed javafx.* and related JavaFX sources from JAVA_HOME/src
* moved jfxrt.jar to a cache directory
Failure situation:
* attempting to launch jfx apps under eclipse debugger
The following console output is typical of what I'm running into
(with -verbose:jni on the command line):
[Dynamic-linking native method java.lang.Object.registerNatives
... JNI]
[Registering JNI native method java.lang.Object.hashCode]
[Registering JNI native method java.lang.Object.wait]
[Registering JNI native method java.lang.Object.notify]
[Registering JNI native method java.lang.Object.notifyAll]
[Registering JNI native method java.lang.Object.clone]
[Dynamic-linking native method java.lang.System.registerNatives
... JNI]
[Registering JNI native method java.lang.System.currentTimeMillis]
[Registering JNI native method java.lang.System.nanoTime]
[Registering JNI native method java.lang.System.arraycopy]
[Dynamic-linking native method java.lang.Thread.registerNatives
... JNI]
[Registering JNI native
Re: Problem accessing jfx native libs under eclipse on windows
Jettisoning the MS tools would be a bad idea. The Visual Studio compiler or the
Intel compiler are really the only reasonable options for building native code
on Windows. I'm not aware of any professional programmer that uses GCC on
Windows... Not because GCC is bad, the Windows ports just aren't capable of
compiling against a real Windows SDK. The MinGW tools come with their own
headers to try to work around this, but the last time I checked, it just didn't
work well enough.
That said,I think the right approach in the long term is to move the build to
use Gradle's support for C and C++. It supports the MS compiler as well as
MinGW on Windows and all the popular compilers on other platforms. If we
combined that with the ability to build just the 32bit JDK when running with
the MS compiler, it would offer a decent solution for those using free tools on
Windows.
Another goal should be to remove the requirement for Cygwin as it can cause its
own set of problems. I'm not sure what it is used for that can't be done with
Gradle and/or pure java libraries directly.
Scott
On Oct 24, 2014, at 2:05 PM, Richard Steiger rstei...@ensemblesoft.net
wrote:
Stephen,
Sorry for the mis-communication: in my original message, I was able to do
incremental java compilation, but hadn't tried to do the full build, since
hadn't made changes to any of the native code. Your reply straighted me out,
that I need to be doing full builds to pick-up changes in either the cpp or
low-level java code. I haven't been able to get the native builds to work,
without it failing in either the cpp compiler or linker.
I still could use a hand to get working tooling.
Also, care to comment whether there's any plan to jetisson the MS tools in
the openjfx project, or at least align it with openjdk9's build system?
Thanks,
-rjs
On 10/24/2014 10:43 AM, Stephen F Northover wrote:
Hi Richard,
Your previous email indicated that you could build, but that you can't see
the shared libraries.
Please try adding this the VM Arguments of your Eclipse launch configuration:
-Djava.library.path=${workspace_loc:rt}/build/sdk/rt/bin
-Djavafx.verbose=true
Thanks,
Steve
On 2014-10-24, 1:31 PM, Richard Steiger wrote:
To recap a message I sent to the list on 9/12, I'm a newbie to JavaFX, and
hoping to be able to contribute, initially fixing bugs.
Stephen, I'm attempting to follow the instructions at:
https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE, and have found
that the Visual Studio tools it calls out don't include the amd64 tools,
have struggled to adapt win.gradle to VS 2011, and otherwise dulled my
pick. Also, when comparing the above instructions to openjdk9's build
setup, I'm also wondering whether someone's revised the openjfx win build
to use gcc, MinGW, Code::Blocks, clang++, or any other toolset besides the
MS crud.
Rather than dragging y'all through the blow-by-blow challenges I've been
getting hit with, what I'm hoping is that one of you who's actively
developing on a 64-bit Windows 7+ environment is willing to lend a hand to
get me set-up with a working rig. Please reply to just me if you're willing
to help, I think I just need a few minutes here and there to pick the right
tools, verify I'm working against the correct repo, etc.
Thanks in advance,
-rjs
On 9/12/2014 2:40 PM, Stephen F Northover wrote:
Hi Richard,
Did you follow the instructions at this link:
https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE ?
You are picking up a set of shared libraries that do not match the java
code you are running in the IDE. You need to set java.library.path. It's
on the wiki and I meant to update it to be something sensible. My build
puts the dll's in an artifacts directory:
-Djava.library.path=${workspace_loc:rt}/../artifacts/sdk/rt/bin
You will need to edit this expression to pick up the dll's from the
standard build place (which I forget right now).
Steve
On 2014-09-12, 5:31 PM, Richard Steiger wrote:
I'm a newbie to JavaFX, and hoping to be able to contribute down the road
once I learn much more about it.
To that end, I've been trying to get 8u-dev eclipse projects setup on a
Win7 box so I can start stepping through the code. The current
show-stopper is getting UnsatisfiedLinkErrors when the system is trying
to access dlls, such as glass.dll.
My rig:
* jdk1.8.0_05
* eclipse-SDK-N20140722-2000-win32-x86_64 (Mars stable build, has fix
for StackOverflow bug in eclipse j8 compiler)
* hg clone of 8u-dev as of 8/26
Setup:
* ran the gradle build (successfully)
* imported the eclipse projects in the repo, all cleanly compile (but
had to fix cross-project links and manually locate and attach 3p libs)
* removed javafx.* and related JavaFX sources from JAVA_HOME/src
* moved jfxrt.jar to a cache directory
Failure situation:
* attempting to launch jfx apps under
Problem accessing jfx native libs under eclipse on windows
I'm a newbie to JavaFX, and hoping to be able to contribute down the road once I learn much more about it. To that end, I've been trying to get 8u-dev eclipse projects setup on a Win7 box so I can start stepping through the code. The current show-stopper is getting UnsatisfiedLinkErrors when the system is trying to access dlls, such as glass.dll. My rig: * jdk1.8.0_05 * eclipse-SDK-N20140722-2000-win32-x86_64 (Mars stable build, has fix for StackOverflow bug in eclipse j8 compiler) * hg clone of 8u-dev as of 8/26 Setup: * ran the gradle build (successfully) * imported the eclipse projects in the repo, all cleanly compile (but had to fix cross-project links and manually locate and attach 3p libs) * removed javafx.* and related JavaFX sources from JAVA_HOME/src * moved jfxrt.jar to a cache directory Failure situation: * attempting to launch jfx apps under eclipse debugger The following console output is typical of what I'm running into (with -verbose:jni on the command line): [Dynamic-linking native method java.lang.Object.registerNatives ... JNI] [Registering JNI native method java.lang.Object.hashCode] [Registering JNI native method java.lang.Object.wait] [Registering JNI native method java.lang.Object.notify] [Registering JNI native method java.lang.Object.notifyAll] [Registering JNI native method java.lang.Object.clone] [Dynamic-linking native method java.lang.System.registerNatives ... JNI] [Registering JNI native method java.lang.System.currentTimeMillis] [Registering JNI native method java.lang.System.nanoTime] [Registering JNI native method java.lang.System.arraycopy] [Dynamic-linking native method java.lang.Thread.registerNatives ... JNI] [Registering JNI native method java.lang.Thread.start0] [Registering JNI native method java.lang.Thread.stop0] [Registering JNI native method java.lang.Thread.isAlive] [Registering JNI native method java.lang.Thread.suspend0] [Registering JNI native method java.lang.Thread.resume0] [Registering JNI native method java.lang.Thread.setPriority0] [Registering JNI native method java.lang.Thread.yield] [Registering JNI native method java.lang.Thread.sleep] [Registering JNI native method java.lang.Thread.currentThread] [Registering JNI native method java.lang.Thread.countStackFrames] [Registering JNI native method java.lang.Thread.interrupt0] [Registering JNI native method java.lang.Thread.isInterrupted] [Registering JNI native method java.lang.Thread.holdsLock] [Registering JNI native method java.lang.Thread.getThreads] [Registering JNI native method java.lang.Thread.dumpThreads] [Registering JNI native method java.lang.Thread.setNativeName] [Dynamic-linking native method java.security.AccessController.getStackAccessControlContext ... JNI] [Dynamic-linking native method java.security.AccessController.getInheritedAccessControlContext ... JNI] [Dynamic-linking native method java.lang.Class.registerNatives ... JNI] [Registering JNI native method java.lang.Class.getName0] [Registering JNI native method java.lang.Class.getSuperclass] [Registering JNI native method java.lang.Class.getInterfaces0] [Registering JNI native method java.lang.Class.getClassLoader0] [Registering JNI native method java.lang.Class.isInterface] [Registering JNI native method java.lang.Class.getSigners] [Registering JNI native method java.lang.Class.setSigners] [Registering JNI native method java.lang.Class.isArray] [Registering JNI native method java.lang.Class.isPrimitive] [Registering JNI native method java.lang.Class.getComponentType] [Registering JNI native method java.lang.Class.getModifiers] [Registering JNI native method java.lang.Class.getDeclaredFields0] [Registering JNI native method java.lang.Class.getDeclaredMethods0] [Registering JNI native method java.lang.Class.getDeclaredConstructors0] [Registering JNI native method java.lang.Class.getProtectionDomain0] [Registering JNI native method java.lang.Class.getDeclaredClasses0] [Registering JNI native method java.lang.Class.getDeclaringClass0] [Registering JNI native method java.lang.Class.getGenericSignature0] [Registering JNI native method java.lang.Class.getRawAnnotations] [Registering JNI native method java.lang.Class.getConstantPool] [Registering JNI native method java.lang.Class.desiredAssertionStatus0] [Registering JNI native method java.lang.Class.getEnclosingMethod0] [Registering JNI native method java.lang.Class.getRawTypeAnnotations] [Dynamic-linking native method java.lang.ClassLoader.registerNatives ... JNI] [Registering JNI native method java.lang.ClassLoader.retrieveDirectives] [Dynamic-linking native method java.security.AccessController.doPrivileged ... JNI] [Dynamic-linking native method java.lang.Class.getPrimitiveClass ... JNI] [Dynamic-linking native method java.lang.Float.floatToRawIntBits ... JNI] [Dynamic-linking native method java.lang.Double.doubleToRawLongBits ... JNI] [Dynamic-linking native method java.lang.Double.longBitsToDouble ... JNI] [Dynamic-linking native method
Re: Problem accessing jfx native libs under eclipse on windows
Hi Richard,
Did you follow the instructions at this link:
https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE ?
You are picking up a set of shared libraries that do not match the java
code you are running in the IDE. You need to set java.library.path.
It's on the wiki and I meant to update it to be something sensible. My
build puts the dll's in an artifacts directory:
-Djava.library.path=${workspace_loc:rt}/../artifacts/sdk/rt/bin
You will need to edit this expression to pick up the dll's from the
standard build place (which I forget right now).
Steve
On 2014-09-12, 5:31 PM, Richard Steiger wrote:
I'm a newbie to JavaFX, and hoping to be able to contribute down the
road once I learn much more about it.
To that end, I've been trying to get 8u-dev eclipse projects setup on
a Win7 box so I can start stepping through the code. The current
show-stopper is getting UnsatisfiedLinkErrors when the system is
trying to access dlls, such as glass.dll.
My rig:
* jdk1.8.0_05
* eclipse-SDK-N20140722-2000-win32-x86_64 (Mars stable build, has fix
for StackOverflow bug in eclipse j8 compiler)
* hg clone of 8u-dev as of 8/26
Setup:
* ran the gradle build (successfully)
* imported the eclipse projects in the repo, all cleanly compile (but
had to fix cross-project links and manually locate and attach 3p libs)
* removed javafx.* and related JavaFX sources from JAVA_HOME/src
* moved jfxrt.jar to a cache directory
Failure situation:
* attempting to launch jfx apps under eclipse debugger
The following console output is typical of what I'm running into (with
-verbose:jni on the command line):
[Dynamic-linking native method java.lang.Object.registerNatives ... JNI]
[Registering JNI native method java.lang.Object.hashCode]
[Registering JNI native method java.lang.Object.wait]
[Registering JNI native method java.lang.Object.notify]
[Registering JNI native method java.lang.Object.notifyAll]
[Registering JNI native method java.lang.Object.clone]
[Dynamic-linking native method java.lang.System.registerNatives ... JNI]
[Registering JNI native method java.lang.System.currentTimeMillis]
[Registering JNI native method java.lang.System.nanoTime]
[Registering JNI native method java.lang.System.arraycopy]
[Dynamic-linking native method java.lang.Thread.registerNatives ... JNI]
[Registering JNI native method java.lang.Thread.start0]
[Registering JNI native method java.lang.Thread.stop0]
[Registering JNI native method java.lang.Thread.isAlive]
[Registering JNI native method java.lang.Thread.suspend0]
[Registering JNI native method java.lang.Thread.resume0]
[Registering JNI native method java.lang.Thread.setPriority0]
[Registering JNI native method java.lang.Thread.yield]
[Registering JNI native method java.lang.Thread.sleep]
[Registering JNI native method java.lang.Thread.currentThread]
[Registering JNI native method java.lang.Thread.countStackFrames]
[Registering JNI native method java.lang.Thread.interrupt0]
[Registering JNI native method java.lang.Thread.isInterrupted]
[Registering JNI native method java.lang.Thread.holdsLock]
[Registering JNI native method java.lang.Thread.getThreads]
[Registering JNI native method java.lang.Thread.dumpThreads]
[Registering JNI native method java.lang.Thread.setNativeName]
[Dynamic-linking native method
java.security.AccessController.getStackAccessControlContext ... JNI]
[Dynamic-linking native method
java.security.AccessController.getInheritedAccessControlContext ... JNI]
[Dynamic-linking native method java.lang.Class.registerNatives ... JNI]
[Registering JNI native method java.lang.Class.getName0]
[Registering JNI native method java.lang.Class.getSuperclass]
[Registering JNI native method java.lang.Class.getInterfaces0]
[Registering JNI native method java.lang.Class.getClassLoader0]
[Registering JNI native method java.lang.Class.isInterface]
[Registering JNI native method java.lang.Class.getSigners]
[Registering JNI native method java.lang.Class.setSigners]
[Registering JNI native method java.lang.Class.isArray]
[Registering JNI native method java.lang.Class.isPrimitive]
[Registering JNI native method java.lang.Class.getComponentType]
[Registering JNI native method java.lang.Class.getModifiers]
[Registering JNI native method java.lang.Class.getDeclaredFields0]
[Registering JNI native method java.lang.Class.getDeclaredMethods0]
[Registering JNI native method java.lang.Class.getDeclaredConstructors0]
[Registering JNI native method java.lang.Class.getProtectionDomain0]
[Registering JNI native method java.lang.Class.getDeclaredClasses0]
[Registering JNI native method java.lang.Class.getDeclaringClass0]
[Registering JNI native method java.lang.Class.getGenericSignature0]
[Registering JNI native method java.lang.Class.getRawAnnotations]
[Registering JNI native method java.lang.Class.getConstantPool]
[Registering JNI native method java.lang.Class.desiredAssertionStatus0]
[Registering JNI native method java.lang.Class.getEnclosingMethod0]
[Registering JNI
Re: Problem accessing jfx native libs under eclipse on windows
Apologies to everyone, my Thunderbird seems to be spewing out messages while I'm composing them. I'll switch to writing in a text editor and mailing the finished draft to avoid continuing to spam y'all. -rjs
