Re: Talk about OPENJFX's future
Well a technical enforcement mechanism is impractical, it's true. What would be involved is a commercial license- an electronic thing like the agreement you clicked on when you downloaded the JDK from Oracle. For people using it commercially, you just make a payment through the usual payment processors. It's more or less an honor thing, right, but we're an honorable lot, LOL. I buy my IDE. I buy other tools. That's all so I can use JavaFX. It makes no economic sense to think this manna is always going to just fall from heaven. Let's just all pony up and put our own futures on a financially secure footing. For us, it creates a huge amount of FUD watching this technology stagger around from Sun to Oracle to somewhere else because , financially, it is not perceived to pay for its own development effort If you need an enforcement mechanism then you could require that your license GUID / license acknowledgment appear in your application along with other such legal announcements. So that would be a public-shame-based enforcement mechanism. We have corporations, schools, research institutes, ISVs who would not miss 50 bucks a year and it would mean everything to JavaFX. Disregarding what each of us may think what OTHER people might think, does anyone seriously personally object to some lightweight scheme like this? I mean you personally- are you offended and likely to look for an alternative on account of it? Serious question, not rhetoric (email nukes nuances LOL). I would feel good about it. I would be more involved, feel like I have an ownership stake and if the resultant cash flow means we can hire (back) some talent and ease the burden on what devs are left, then we all benefit from fewer bugs and more features, which is what we all want and where real money ultimately comes from, right? Suggested donations have a less than 1% "compliance" rate. On Friday, September 21, 2018 at 12:13 PM, Scott Palmer wrote: I would focus on bug-free functionality and *performance* over new features. Layout and CSS issues still seem to have a significant drag on JavaFX rendering. Much of the new features I want are somewhat motivated by performance anyway. E.g. getting native window handles… to handle performance issues with 3D and video overlays. I think #2, while cheap, will severely harm JavaFX adoption just from the added nuisance alone. Is there a precedent where this has worked out? Regards, Scott On Sep 21, 2018, at 12:04 PM, jav...@use.startmail.com wrote: Two items for us 1) focus on bug-free functionality over new features. 2) require a U.S. $50.00 a year fee per corporate entity for commercial application usage. This is very reasonable and would finally secure JavaFX's future as a development platform. I feel without 2) above we will find ourselves wandering around cyberspace hoping for a benefactor or the charity of volunteers and their spare time. hth. On Friday, September 21, 2018 at 5:52 AM, John-Val Rose wrote: That video is typical marketing “smoke and mirrors”. With no access to the code of either app, it is simply unfair and disingenuous to claim a performance advantage. I am certain I could post an almost identical comparison video where the results would be the complete opposite. Yeah, good programmers can write slow code (especially if you have a motive)... On 21 Sep 2018, at 19:29, Johan Vos wrote: We can't defeat QT in performance, but we can defeat it at applicability and just don't get too far behind QT in performance. (bad example https://www.youtube.com/watch?v=Kh6K-yEp_JY) That video demonstrates the creator has absolutely no development skills in Java, or he intentionally misleads the viewer. I leave it to the reader to judge what would be worst. I am not going to make performance statements without numbers, but my first observations using JavaFX 11 with the Bellsoft Liberica VM are very encouraging (see https://gluonhq.com/javafx-11-early-access-on-embedded/) - Johan
Re: Talk about OPENJFX's future
Two items for us 1) focus on bug-free functionality over new features. 2) require a U.S. $50.00 a year fee per corporate entity for commercial application usage. This is very reasonable and would finally secure JavaFX's future as a development platform. I feel without 2) above we will find ourselves wandering around cyberspace hoping for a benefactor or the charity of volunteers and their spare time. hth. On Friday, September 21, 2018 at 5:52 AM, John-Val Rose wrote: That video is typical marketing “smoke and mirrors”. With no access to the code of either app, it is simply unfair and disingenuous to claim a performance advantage. I am certain I could post an almost identical comparison video where the results would be the complete opposite. Yeah, good programmers can write slow code (especially if you have a motive)... On 21 Sep 2018, at 19:29, Johan Vos wrote: We can't defeat QT in performance, but we can defeat it at applicability and just don't get too far behind QT in performance. (bad example https://www.youtube.com/watch?v=Kh6K-yEp_JY) That video demonstrates the creator has absolutely no development skills in Java, or he intentionally misleads the viewer. I leave it to the reader to judge what would be worst. I am not going to make performance statements without numbers, but my first observations using JavaFX 11 with the Bellsoft Liberica VM are very encouraging (see https://gluonhq.com/javafx-11-early-access-on-embedded/) - Johan
Re: JavaFX 11 is released
We will review your report and have assigned it an internal review ID : 9057296. hth... On Tuesday, September 18, 2018 at 3:24 PM, Kevin Rushforth wrote: I really meant that when you file a bug at https://bugreport.java.com/ you can paste it inline there, along with your description of the bug. If you have already filed a bug, send me the ID and I can copy the info into that bug. Thanks. -- Kevin On 9/18/2018 11:26 AM, jav...@use.startmail.com wrote: Thanks Kevin. I will paste it all in this email.
Re: JavaFX 11 is released
Thanks Kevin.
I will paste it all in this email. I have essentially three versions.
Two are so compressed it's hard for people to get what the issue is.
Since in those programs the proof only takes the form of the value of a
class variable, and that proof is demonstrated only by
System.out.printlns of that variable's value, it's understandable that
the significance of what's being output could easily be missed or
misinterpreted/ dismissed etc.
The other one is a proper demo application which throws a
ConcurrentModificationException which can't be so easily misunderstood
or dismissed, but it has multiple *very small , very well documented*
classes. You can't read the documentation and not get at what's being
shown (and still call yourself a developer LOL...), but you have to
read the javadoc.
Note: don't shoot from the hip based on a cursory examination of the
output or stack trace (like I did LOL). I have probably already
considered your alternate explanation, things from overridden methods
to the confusion about how and why ConcurrentModificationExceptions
are thrown to the (non) presence of multiple class loaders etc etc. It
took me real time to even entertain the idea that this was not a subtle
programming mistake but instead a bug in JavaFX. I can't avoid writing
these so that you have to read the javadoc - you just have to read the
javadoc.
My experience tells me the brief versions were not easy to understand
so I'll post the bigger version here. All but one or two of these
classes should be easy, one-glance classes for most everyone here and
the others are also very easy, with brief methods and anyway
thoroughly javadoced.:
OK:
1) A Receiver receives a mouse event.
***
package javaApplicationThreadCuriosityComplex;
import javafx.scene.input.MouseEvent;
public interface Receiver
{
void receiveEvent(MouseEvent event);
}
**
A do-nothing receiver receives the mouse event and does nothing
**
package javaApplicationThreadCuriosityComplex;
import javafx.scene.input.MouseEvent;
/**
* A {@link Receiver} implementation which literally does nothing
except receive the {@link MouseEvent} in {@link
#receiveEvent(MouseEvent)}, as defined in {@link Receiver}.
* Exists in order that we can create many instances of a {@link
Receiver} implementation, where the mere existence and not the
functionality of the implementation is of any consequence to the
program.
* See {@link PaneEventHandlerExceptionThrower} for details.
*
* To satisfy yourself that these objects are being invoked,
uncomment-out the line in {@link #receiveEvent(MouseEvent)}, which will
print "Hello" to standard output.
*/
public class DoNothingReceiver implements Receiver
{
@Override
public void receiveEvent(MouseEvent event)
{
//System.out.println("Hello");
}
}
A rectangle drawing Receiver implementation. Very simple class; long
only because it's written to be transparent in its behavior.
If the received mouse event is a certain type (arbitrarily selected for
ease of use in the application - mouse pressed on the primary button)
then it just removes the sole Rectangle from the application's sole
Pane, if such a Rectangle is there.
In any case, it next immediately creates a new Rectangle, sizes it,
changes its color, positions it and adds it to the same Pane.
The effect is the Rectangle either appears for the first time, or
appears to change color.
That's it.
package javaApplicationThreadCuriosityComplex;
import javafx.scene.input.MouseEvent;
import javafx.scene.layout.Pane;
import javafx.scene.paint.Color;
import javafx.scene.shape.Rectangle;
import java.util.List;
/**
*
* This object receives {@link MouseEvent}s from the {@link
javafx.event.EventHandler}.
* If the event is the primary button of the mouse being pressed, this
object removes the member {@link RectangleDrawingReceiver#rectangle}
from the list of the {@link Pane}'s children if that {@link Rectangle}
is present in that list.
* It then assigns a new instance of a {@link Rectangle} to the member
{@link RectangleDrawingReceiver#rectangle}.
* Finally it adds that member to the list of the {@link Pane}'s
children.
* */
public class RectangleDrawingReceiver implements Receiver
{
/**
* The {@link Rectangle} which will appear after the Mouse is pressed
for the first time and be replaced on subsequent MOUSE_PRESSED events.
*/
private Rectangle rectangle;
/**
* boolean value which is reversed each time the primamry
Re: JavaFX 11 is released
I don't see a way to attach java classes at the bug report form located here: https://bugreport.java.com/bugreport/start_form.do Is there some way to do this? Thank you. On Tuesday, September 18, 2018 at 9:02 AM, Kevin Rushforth wrote: I am pleased to announce the final release of JavaFX 11 as well as the launch of a new OpenJFX community site at: http://openjfx.io/ The GA version of JavaFX 11 is now live and can be downloaded by going to the openjfx.io site or by accessing javafx modules from maven central at openjfx:javafx-COMPONENT:11 (where COMPONENT is one of base, graphics, controls, and so forth). This is the first standalone release of JavaFX 11. It runs with JDK 11, which is available as a release candidate now and will be shipped as a GA version next week, or on JDK 10 (OpenJDK build only). A big thank you to all who have contributed to OpenJFX make this release possible! I especially thank Johan Vos, both for taking on the role as Co-Lead of the OpenJFX Project and for the work that Gluon as done to build and host the JavaFX 11 release. I look forward to working with you all on JavaFX 12 and beyond. -- Kevin
Re: JavaFX Application Thread is recursively re-entrant into Eventhandler handle() method under some circumstances
wo classes. Here is the JavaFX
Application class:
***
package bareBonesJavaFXBugExample;
import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.control.Label;
import javafx.scene.input.MouseEvent;
import javafx.scene.layout.Pane;
import javafx.stage.Stage;
/**
* An {@link Application} with one {@link Pane} containing one
{@link
Label}. The {@link Label} has a single {@link
javafx.event.EventHandler}, {@link LabelEventHandler} which
processes
all {@link MouseEvent}s the {@link Label} receives.
*
* To trigger the bug, run the application, then spend a second
mouse
over the little label in the upper left hand corner of the scrren.
You
will see output to standard I/O. Then, click the label, which will
then
disppear. Check the I/O for Strings ending in debugCounter is 1.
* What that String means and how it proves that the JavaFX
Application
Thread has become reentrant is explained in the javadoc of {@link
LabelEventHandler}.
*/
public class JavaFXAnomalyBareBonesApplication extends Application
{
public void start(Stage primaryStage)
{
Pane mainPane = new Pane();
mainPane.setMinHeight(800);
mainPane.setMinWidth(800);
Label label = new Label(" this is quite a bug ");
LabelEventHandler labelEventHandler = new
LabelEventHandler(mainPane, label);
label.addEventHandler(MouseEvent.ANY, labelEventHandler);
mainPane.getChildren().add(label);
Scene scene = new Scene(mainPane);
primaryStage.setScene(scene);
primaryStage.show();
}
/**
* The entry point of application.
*
* @param args
* the input arguments
*/
public static void main(String[] args)
{
launch(args);
}
}
***
and here is its only dependency, the EventListener class. I included
enough javadoc to have the program makes sense. :
***
package bareBonesJavaFXBugExample;
import javafx.event.Event;
import javafx.event.EventHandler;
import javafx.scene.control.Label;
import javafx.scene.input.MouseEvent;
import javafx.scene.layout.Pane;
import java.util.Collection;
import java.util.ConcurrentModificationException;
/**
* An {@link EventHandler} implementation for {@link MouseEvent}s.
This implementation's {@link EventHandler#handle(Event)}
shows
the relevant debug information to standard output before and after
removing the member {@link #label} from the {@link #pane}.
*
* discussion
*
* Users should first satisfy themselves that the value of {@link
LabelEventHandler#debugCounter} can only be non-zero, in fact 1
(one) in
the method {@link LabelEventHandler#showDebugInformation(String)} if
the
method {@link LabelEventHandler#handle(MouseEvent)} has been
re-entered
recursively, that is, before a previous invocation of {@link
LabelEventHandler#handle(MouseEvent)} has returned.
*
* Proof: 1) debugCounter starts at value 0
(zero).
2) debugCounter is only incremented once, by 1
(one), and that is after the first call to {@link
LabelEventHandler#showDebugInformation(String)} has returned.
3)
debugCounter is only decremented once, by 1 (one) and
that
is before the last call to {@link
LabelEventHandler#showDebugInformation(String)}. 4) however,
because
* debugCounter is a class variable ( it's static), if
handle() is recurvsively re-entered then it's value can be 1 (one)
when
the re-entrant Thread executes {@link
LabelEventHandler#showDebugInformation(String)}
*
* End proof.
*
*
*
* The output of this method to standard I/O is volumnious but
searching
the output for the exact String "debugCounter is 1" will immediately
show the {@link LabelEventHandler#handle(MouseEvent)} method to have
been recursively entered.
* Some other possibilities other than the JavaFX Application Thread
recursing into {@code handle()} need to be addressed. One is
the
fact that the compiler is free to reorder statements if it can
* prove that such a reordering would have no effect on the
program's
correctness.
*
* So somehow the compiler is reordering the increment/decrement of
{@code debugCounter} and the calls to {@code
showDebugInformation}.
But this would alter the correctness of the program, so
this
cannot be the case, or the compiler is making an error.
*
*
* Another is the fact that I/O is not instantaneous and can appear
to
standard output later than it actually was executed. This
is
something often seen in debug stack traces, where the output is
broken
up or interleaved by the output of the stack trace even though the
two
sets of statments, i/o and stack trace i/o, were strictly ordered in
execution. But this can't account for the value of {@code
debugCounter}, so it can't
* be the reas
Re: JavaFX Application Thread is recursively re-entrant into Eventhandler handle() method under some circumstances
.com wrote:
Hi All,
I spent some time refactoring the program which displays this bug.
It's
now small enough to share the source in an email, but it is very
very
dense and the proof of bug, one specific line to standard I/O,
requires
the source code to be read and understood in order to see the bug.
As I
said previously, more comprehensible and user-friendly versions of
this
program are available at . The javadoc is more copious, the bug is
manifested as an exception and the side effect of the bug are more
consequential.
This brief version cnosists of just two classes. Here is the JavaFX
Application class:
***
package bareBonesJavaFXBugExample;
import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.control.Label;
import javafx.scene.input.MouseEvent;
import javafx.scene.layout.Pane;
import javafx.stage.Stage;
/**
* An {@link Application} with one {@link Pane} containing one
{@link
Label}. The {@link Label} has a single {@link
javafx.event.EventHandler}, {@link LabelEventHandler} which
processes
all {@link MouseEvent}s the {@link Label} receives.
*
* To trigger the bug, run the application, then spend a second
mouse
over the little label in the upper left hand corner of the scrren.
You
will see output to standard I/O. Then, click the label, which will
then
disppear. Check the I/O for Strings ending in debugCounter is 1.
* What that String means and how it proves that the JavaFX
Application
Thread has become reentrant is explained in the javadoc of {@link
LabelEventHandler}.
*/
public class JavaFXAnomalyBareBonesApplication extends Application
{
public void start(Stage primaryStage)
{
Pane mainPane = new Pane();
mainPane.setMinHeight(800);
mainPane.setMinWidth(800);
Label label = new Label(" this is quite a bug ");
LabelEventHandler labelEventHandler = new
LabelEventHandler(mainPane, label);
label.addEventHandler(MouseEvent.ANY, labelEventHandler);
mainPane.getChildren().add(label);
Scene scene = new Scene(mainPane);
primaryStage.setScene(scene);
primaryStage.show();
}
/**
* The entry point of application.
*
* @param args
* the input arguments
*/
public static void main(String[] args)
{
launch(args);
}
}
***
and here is its only dependency, the EventListener class. I included
enough javadoc to have the program makes sense. :
***
package bareBonesJavaFXBugExample;
import javafx.event.Event;
import javafx.event.EventHandler;
import javafx.scene.control.Label;
import javafx.scene.input.MouseEvent;
import javafx.scene.layout.Pane;
import java.util.Collection;
import java.util.ConcurrentModificationException;
/**
* An {@link EventHandler} implementation for {@link MouseEvent}s.
This implementation's {@link EventHandler#handle(Event)}
shows
the relevant debug information to standard output before and after
removing the member {@link #label} from the {@link #pane}.
*
* discussion
*
* Users should first satisfy themselves that the value of {@link
LabelEventHandler#debugCounter} can only be non-zero, in fact 1
(one) in
the method {@link LabelEventHandler#showDebugInformation(String)} if
the
method {@link LabelEventHandler#handle(MouseEvent)} has been
re-entered
recursively, that is, before a previous invocation of {@link
LabelEventHandler#handle(MouseEvent)} has returned.
*
* Proof: 1) debugCounter starts at value 0
(zero).
2) debugCounter is only incremented once, by 1
(one), and that is after the first call to {@link
LabelEventHandler#showDebugInformation(String)} has returned.
3)
debugCounter is only decremented once, by 1 (one) and
that
is before the last call to {@link
LabelEventHandler#showDebugInformation(String)}. 4) however,
because
* debugCounter is a class variable ( it's static), if
handle() is recurvsively re-entered then it's value can be 1 (one)
when
the re-entrant Thread executes {@link
LabelEventHandler#showDebugInformation(String)}
*
* End proof.
*
*
*
* The output of this method to standard I/O is volumnious but
searching
the output for the exact String "debugCounter is 1" will immediately
show the {@link LabelEventHandler#handle(MouseEvent)} method to have
been recursively entered.
* Some other possibilities other than the JavaFX Application Thread
recursing into {@code handle()} need to be addressed. One is
the
fact that the compiler is free to reorder statements if it can
* prove that such a reordering would have no effect on the
program's
correctness.
*
* So somehow the compiler is reordering the increment/decrement of
{@code debugCounter} and the calls to {@code
showDebugInfor
Re: JavaFX Application Thread is recursively re-entrant into Eventhandler handle() method under some circumstances
Hi All,
I spent some time refactoring the program which displays this bug. It's
now small enough to share the source in an email, but it is very very
dense and the proof of bug, one specific line to standard I/O,
requires the source code to be read and understood in order to see the
bug. As I said previously, more comprehensible and user-friendly
versions of this program are available at . The javadoc is more
copious, the bug is manifested as an exception and the side effect of
the bug are more consequential.
This brief version cnosists of just two classes. Here is the JavaFX
Application class:
***
package bareBonesJavaFXBugExample;
import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.control.Label;
import javafx.scene.input.MouseEvent;
import javafx.scene.layout.Pane;
import javafx.stage.Stage;
/**
* An {@link Application} with one {@link Pane} containing one {@link
Label}. The {@link Label} has a single {@link
javafx.event.EventHandler}, {@link LabelEventHandler} which processes
all {@link MouseEvent}s the {@link Label} receives.
*
* To trigger the bug, run the application, then spend a second mouse
over the little label in the upper left hand corner of the scrren. You
will see output to standard I/O. Then, click the label, which will then
disppear. Check the I/O for Strings ending in debugCounter is 1.
* What that String means and how it proves that the JavaFX Application
Thread has become reentrant is explained in the javadoc of {@link
LabelEventHandler}.
*/
public class JavaFXAnomalyBareBonesApplication extends Application
{
public void start(Stage primaryStage)
{
Pane mainPane = new Pane();
mainPane.setMinHeight(800);
mainPane.setMinWidth(800);
Label label = new Label(" this is quite a bug ");
LabelEventHandler labelEventHandler = new
LabelEventHandler(mainPane, label);
label.addEventHandler(MouseEvent.ANY, labelEventHandler);
mainPane.getChildren().add(label);
Scene scene = new Scene(mainPane);
primaryStage.setScene(scene);
primaryStage.show();
}
/**
* The entry point of application.
*
* @param args
* the input arguments
*/
public static void main(String[] args)
{
launch(args);
}
}
***
and here is its only dependency, the EventListener class. I included
enough javadoc to have the program makes sense. :
***
package bareBonesJavaFXBugExample;
import javafx.event.Event;
import javafx.event.EventHandler;
import javafx.scene.control.Label;
import javafx.scene.input.MouseEvent;
import javafx.scene.layout.Pane;
import java.util.Collection;
import java.util.ConcurrentModificationException;
/**
* An {@link EventHandler} implementation for {@link MouseEvent}s.
This implementation's {@link EventHandler#handle(Event)} shows
the relevant debug information to standard output before and after
removing the member {@link #label} from the {@link #pane}.
*
* discussion
*
* Users should first satisfy themselves that the value of {@link
LabelEventHandler#debugCounter} can only be non-zero, in fact 1 (one)
in the method {@link LabelEventHandler#showDebugInformation(String)} if
the method {@link LabelEventHandler#handle(MouseEvent)} has been
re-entered recursively, that is, before a previous invocation of {@link
LabelEventHandler#handle(MouseEvent)} has returned.
*
* Proof: 1) debugCounter starts at value 0
(zero). 2) debugCounter is only incremented once,
by 1 (one), and that is after the first call to {@link
LabelEventHandler#showDebugInformation(String)} has returned. 3)
debugCounter is only decremented once, by 1 (one) and that
is before the last call to {@link
LabelEventHandler#showDebugInformation(String)}. 4) however,
because
* debugCounter is a class variable ( it's static), if
handle() is recurvsively re-entered then it's value can be 1 (one) when
the re-entrant Thread executes {@link
LabelEventHandler#showDebugInformation(String)}
*
* End proof.
*
*
*
* The output of this method to standard I/O is volumnious but
searching the output for the exact String "debugCounter is 1" will
immediately show the {@link LabelEventHandler#handle(MouseEvent)}
method to have been recursively entered.
* Some other possibilities other than the JavaFX Application Thread
recursing into {@code handle()} need to be addressed. One is
the fact that the compiler is free to reorder statements if it can
* prove that such a reordering would have no effect on the program's
correctness.
*
* So somehow the compiler is reordering the increment/decrement of
{@code debugCounter} and the calls to {@code showDebugInformatio
Re: JavaFX Application Thread is recursively re-entrant into Eventhandler handle() method under some circumstances
Here is the link to the demonstration applications for this issue. I noticed one small javadoc error which references a class whose name was changed in a refactoring, but it should not really confuse anyone. You have to read the readme.txt . https://uploadfiles.io/ejt5h HTH On Friday, September 7, 2018 at 8:37 PM, jav...@use.startmail.com wrote: Hi, I have a couple of very small apps (3 small classes in one case and 5 in another) which demonstrate that, under some circumstances, the JavaFX Application Thread will recursively re-enter EventHandler#handle(). So this means that it is already in handle (and calls therefrom) and will, in some situations not complete that processing (thus exiting handle) before it reappears in the same instance of EventHandler's handle method again. So this is true recursion. I actually don't know if this is expected behavior or not. No one I've talked to expected it; the general understanding is the JavaFX Application Thread (processing) is specifically single-threaded and also that it will defintily complete one invocation of handle() before beginning another one. I have to say that there is NO other Thread in play here, at least no other Thread my applications create (what's going on QuantumToolKit may be a different story.) The material upshot of this is it can lead to apparent program incorrectness if the dev believes that it's not the case, and 100% of devs I've talked to think it's not possible. I am happy to post or attach the classes or modules as requested but first I wanted to check to see if in fact this is already known to be true and is in fact expected behavior, in which case it's a non-issue and just a subtlety people are not aware of. Thank you so much !
JavaFX Application Thread is recursively re-entrant into Eventhandler handle() method under some circumstances
Hi, I have a couple of very small apps (3 small classes in one case and 5 in another) which demonstrate that, under some circumstances, the JavaFX Application Thread will recursively re-enter EventHandler#handle(). So this means that it is already in handle (and calls therefrom) and will, in some situations not complete that processing (thus exiting handle) before it reappears in the same instance of EventHandler's handle method again. So this is true recursion. I actually don't know if this is expected behavior or not. No one I've talked to expected it; the general understanding is the JavaFX Application Thread (processing) is specifically single-threaded and also that it will defintily complete one invocation of handle() before beginning another one. I have to say that there is NO other Thread in play here, at least no other Thread my applications create (what's going on QuantumToolKit may be a different story.) The material upshot of this is it can lead to apparent program incorrectness if the dev believes that it's not the case, and 100% of devs I've talked to think it's not possible. I am happy to post or attach the classes or modules as requested but first I wanted to check to see if in fact this is already known to be true and is in fact expected behavior, in which case it's a non-issue and just a subtlety people are not aware of. Thank you so much !
Re: Windows Build setupTools
I did not try Tom's build instructions however I can contribute that having Cygwin on Windows 7 and following the build instructions as posted on the JavaFX build instructions page is not suffcient to result in a successful build. The exact error messages I was receiving I posted earlier . On Thursday, December 21, 2017 3:08 AM, Michael Ennen <mike.en...@gmail.com> wrote: Thanks for the tip, Tom. I understand that Cygwin is a dependency of building on Windows but didn't know that the properties are only configured on a cygwin shell. I have a pseudo-goal of removing the Cygwin dependency from building OpenJFX on Windows and I wonder why Cygwin is necessary for setupTools to work? I see other obvious places in the build files that would only work on Cygwin, but am unclear as to why the properties would not be set in cmd.exe or Powershell. Thanks again for the clarification. On Thu, Dec 21, 2017 at 1:04 AM, Tom Schindl <tom.schi...@bestsolution.at> wrote: Hi Michael, I did not had to setup any special variables and documented my steps at https://github.com/BestSolution-at/openjfx-build. I had trouble myself initially but the reason was that I ran the "gradle sdk" command from within a MSDOS-Shell but you really need to run it within cygwin. Tom On 21.12.17 06:40, Michael Ennen wrote: Some people were reporting that Windows builds are difficult to setup. I think this is due to the fact that the call to setupTools in buildSrc/win.gradle is in fact not working correctly. Invoking buildSrc/genVSproperties.bat directly prints the correct properties. However adding some debugging to setupTools it is clear that something is very wrong with it. This is the result: WINDOWS_VS_DEVENVDIR= WINDOWS_VS_DEVENVCMD=/VCExpress.exe WINDOWS_VS_VCINSTALLDIR= WINDOWS_VS_VSINSTALLDIR= WINDOWS_VS_MSVCDIR= WINDOWS_VS_INCLUDE= WINDOWS_VS_LIB= WINDOWS_VS_LIBPATH= WINDOWS_VS_PATH=; WINDOWS_VS_VER=120 WINDOWS_SDK_DIR= WINDOWS_SDK_VERSION= This is the reason people are needing to hard-code values for the properties below the call to setupTools. I am trying to debug what is actually wrong with setupTools but so far not making much progress. I tried this on my local Windows 10 machine and Appveyor VMs and the result is the same. I also read at least two mails in this list about needing to hard-code the properties, I am assuming it is for the same reason. I will try and figure out the reason but wanted to at least make this issue more concrete. -- Michael Ennen
Re: Text classes
Created a github page with a wiki anyone interested is invited to join: https://github.com/javafx-iness/master/wiki I am interested to be able to do hit testing on Text for the purpose of writing a rich text editor, among other things. On Saturday, December 16, 2017 5:47 AM, Abossolo Foh Guy <guy.abossolo@scientificware.com> wrote: Hello, * Does it means you're interested to port swing/text package to JavaFX ? If the case, I will integrate your community to participate. * This debate is a true problematic, ** First, "Do it yourself" ! I recently posted a message about MathML support in JavaFX. MathML display is broken since 2015. This is the same response : if that's a priority for you, you can do it by yourself : "If you are interested in seeing that this bug get fixed sooner, then I might suggest that you consider contributing a fix for this bug youself." ** Secondly, how to participate in this project ? Ok, but my experience was not the best in hacking OpenJDK by myself. Without several supplications and an active sponsoring of an Oracle Engineer my patch would have never be pushed in the OpenJDK. My reponse to Kevin message : "I already contributed to openjdk specific bugs for the same reasons you give me. An issue in the swing/text package. My patch was posted in 2012 and accepted in 2017 for JDK9. It hasn't been a great experience for me. I'm working on Math notation support in swing/text package. And the day that I also try to work with JavaFx ... the MathML support is broken ! I'm really interested in seeing this bug fixed. That's why, I first contacted F. Wang from Igalia who worked on MathML integration in WebKit because I thought that it was a WebKit issue. But he answered me that it's probably a bug in OpenJFX because in others WebKit based applications, all works fine. He suggested me to post a bug report. Thus I made a look to the bug database and discovered that it's an old issue. This issue doesn't disappear with the new WebKit version in JavaFX. And now, I'm trying to contact Murali to know what I can expect in the future releases. I would be happy and proud to fix this issue but there is no documentation about WebKit integration in OpenJFX. I hope Murali will add a comment about he plans to look at this." ** Finaly, I don't know ... Murali added his comment in the bug report last week : MathML support is not a priority. What I 'll have to do now ? No response ! I hope not offense anybody with my bad english. I'm a pretty constructive person. Best regards.
Re: Text classes
Sorry about all the typos previously. Question- why not use the code in awt ? I am not totally up on what's going on with the platforms' native rendering engines ( meaning, I have no idea whatsoever) or how they have changed, but golly it sure does still work pretty well. At least it seems to me looking at awt that a smallish number of things are 1) well defined by the native platofrm and 2) would more or less translate directly to an Java API and 3) from those small number of building blocks, (Font and Glyph metrics and this kind of thing) text line layout algorithms can be written by ordinary civilians along with all the other stuff that goes into a text editor. And yes, everything does look easy when someone else is going to do it.
Re: Text classes
No Oracle plans !!! My one sentence rant: Interactive infographics are a cool way to represent complex information and actgually represent a genuinely new way to communicate information which in some cases is also the best way or all possible ways, but there are at least two other ways that are also the best way under some circumstances- mathematics and the printed word. You can't possibly think you're going to release a GUI toolkit that doesn't fully support the written word. The vast bulk of civilization goes forward on the written word. I would gladly do it or join an effort but I can't get JavFX to build and after a real, full week or trying, gave up for-ev-vah and moved on to other stuff. I am going to leverage Swing for my Fontly needs and am brushing of my C++ in case it JavaFX never does it and Oracle (foolishly!!!) deprecates Swing at which point it's abandon Java for me. (Really, it's not seen as practical to use the existing implementation under the hood in FX ? Not even as a jumping off point? ) At the end of my WeekFromHellTryingToBuildJavaFX I had a couple of what I considered to be insights, based on my limited knowledge of JavaFX , which I'm going to pretend I don't realize are likely of sub-zero interest to readers of this forum and consequently share with you. One was- Yeah large, possibly huge, text documents are not the best fit for the particular scene graph implementation that is JavaFX. In short, JavaFX is *almost* a physics engine in the sense that a change in the size of THAT Node a way over yonder could crerdibly cause a repositioning of any or all Nodes in the scene graph as a result of resizing and the reactions of layout managers to that resizing. What that means for Big Text documents with LOts Of Text Nodes is a change in any of the CSS property values (or mutation of the words themselves) could kick off quite a process or recalculating where the CPU sucking methods that show up in my profiler, mostly reclaculating Rectangular bounds, are going to bring your program down. I can get about 20k nodes to step lively in a program but 200k Nodes makes the scene never render at all, much less be usable. That's the scene graph. But documents have more than 200k words in them, If a change in font or style delineates the boundaries of a (causes the creation of a new) Text Node (it is) then it's just wy too easy to generate waaay too many Nodes and, looking intothe future of Text where whole chunks of it will be created by computers (AI) but consumed by humans (analysis, digestion) TooManyNodes is only going to get worse. So there's that. Another was: We devs have made quite a little problem for ourselves with respect to being able to communicate to others of our kind the necessary and siffcient conditions a machine must be in in order to build a pierce of software. We really have no way to put an alien computer into a build-ready state or even communicate the conditions it needs to be in in real actionable detail. Talk about versions of this and defining system variables to be that are at best partial, ad-hoc efforts doomed to fail for a large number of people and ultimately backed by ignorance about the ACTUAL state of our own machines and chock-o-block woth unwarranted assumptions about the state of the would-be builder's machine. Variable are defined randomly in build scripts and those variables are often literally stitched together over widely separated statements from variables' values assumed to be present on the machine and assumed to hold certain values. Build scripts are necessarily dependent on assumptions about the specific internal state of third party software they have no control over and that state is often temporary, en passant, shortly to become literally unavailable to future devs. Organizations can mothball the required versions of software, create identical machines and have build vetrans available to troubleshoot the build but even those savants have no way of communicating to others what the magic is in their witches brew and they themselves are not aware of everything that goes into a successful build. It's as I said, a wicked problem. On Tuesday, December 5, 2017 3:41 PM, Phil Race <philip.r...@oracle.com> wrote: This is a gap it would be nice to fill. Since it is not a small effort to do right there'd be a design side as well as implementation so it can't be just 'slid in'. And I don't think just moving internal APIs to public is the way to approach it. There are no current plans to allocate Oracle resources to do that work. But this is an open source project, so if someone on this list is willing to design & contribute it - and of course fix the issues and long term maintain it - then that would be great. -phil. On 11/25/2017 03:40 PM, jav...@use.startmail.com wrote: Hi, This is a question about the future of Text un
feedback on item
Any feedback on this item? I had the same issue. I haven't gotten any response. They must already be aware of it but they're not tipping their hand about what if anything they plan to do about it or what release improvements might appear in. For an easy 1000 yd. overview of what's missing, compare the class Font found in javafx to the class Font found in java.awt . java.awt's Font class, it's methods and the classes it references will lead you straight into what the difference between the two libraries are and what capabilities are absent in javafx.
Text classes
Hi, This is a question about the future of Text under Javafx. Very briefly, Swing provided access to everything a dev could need in order to write a rich text editor from scratch. LineBreakMeasurers and HitTesting and everything. In JavaFX these things are not directly available to the dev and anyway, to the extent that they are, they cannot be used to write a rich text editor.. There are many classes needed involving the measuring of glyphs and text lines etc etc etc which would be needed for anyone who wanted to write their own rich text editor. They exist, but are under sun.com and given the modularization of Java 9 are truly inaccessible to developers. I am aware of the existing Javafx controls. I am also aware of the efforts available at GitHub and elsewhere to create a rich text editor and all of them without exception are handicapped by this same lack of API. I am also aware of HTMLEditor in JavaFX but that 1) commits the dev to WebRenderer and 2) still doesn't provide access to the needed classes and methods. It's not sufficient to suppose that HTML 5 or whatever follows is the answer to all text layout challenges. Formerly, Swing had all these missing features available as API and many good text editors were created using those APIs. For the sake of future planning, we really need to know- is there any recognition within Oracle that this is something which has to be addressed? Is it on any hypothetical roadmap? Or is HTMLEditor as much as JavaFX is going to provide ? Thank you.
Re: Error on build
Tuesday, October 3, 2017 9:43 AM, Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>
>> The Wiki is out of date. VS 2017 Professional is now required
to build
>> OpenJFX. A fix was just pushed [1] to allow a different build
of VS 2017
>> than the hard-coded one.
>>
>> Also, I am still able to build with VS 2010 and VS 2013, which
should
>> work as long as you don't build media or webkit (they aren't
built by
>> default).
>>
>> -- Kevin
>>
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8187366
>>
>>
>>
>>
>> Chris Newland wrote:
>>
>>
>>>
>>> Hi,
>>>
>>>
>>> I'm also trying to build OpenJFX on Windows 10 so I can add a
>>> Windows
>>> build to my community OpenJFX build server at
>>> https://chriswhocodes.com
>>> and am hitting the same problems as you.
>>>
>>> Setting WINSDK_DIR on the command line using 'set' or 'export'
>>> doesn't work and neither does setting via the Windows
environment
>>> manager UI.
>>>
>>>
>>> Hardcoding got me past this one:
>>>
>>>
>>> def WINDOWS_SDK_DIR="..." above the check.
>>>
>>> Next error I'm hitting is NativeCompileTask.compile()
>>>
>>>
>>> This is with Windows 10, VS10 Express, WinSDK 7.1, and DirectX
June
>>> 2010.
>>>
>>>
>>> buildSrc/win.gradle has hardcoded paths to VS2017 Professional
so I'm
>>> guessing the devs who wrote this build script have got it
working on a
>>> more modern build environment than the one described in the
docs.
>>>
>>> Will post here if I can get it to build.
>>>
>>>
>>> Cheers,
>>>
>>>
>>> Chris
>>>
>>>
>>> On Tue, October 3, 2017 02:14, jav...@use.startmail.com wrote:
>>>
>>>
>>>
>>>>
>>>> Hi again !
>>>>
>>>>
>>>>
>>>> Well I was able to track down the source of the error I am
>>>> receiving from the gradle build. Unfortunately, the error
persists,
>>>> which is a bit of a mystery. Maybe a gradle maven can
enlighten me
>>>> here.
>>>>
>>>> For some reason, this line on line 90-91 of win.gradle is
throwing
>>>> the exception, although I can prove it ought not to: if
>>>> (WINDOWS_SDK_DIR ==
>>>> null || WINDOWS_SDK_DIR == "") { throw new
GradleException("FAIL:
>>>> WINSDK_DIR not defined");
>>>> I cannot get past this, the exception is triggered, and yet
the
>>>> assignment of a value to property WINDOWS_SDK_DIR is quite
clear here
>>>> (line
>>>> of 69 win.gradle): defineProperty("WINDOWS_SDK_DIR",
properties,
>>>> System.getenv().get("WINSDK_DIR"))
>>>> and that system variable is, in fact, set as proved by (my)
running
>>>> this simple program I wrote (which exists in the same
directory as
>>>> win.gradle to exclude any conceivable path issues) and
getting the
>>>> proper outputpublic class WinSDK { public WinSDK() { } public
static
>>>> void main(String[] args) { String sdk =
>>>> (String)System.getenv().get("WINSDK_DIR");
>>>> System.out.println("sdk = " + sdk);
>>>> }
>>>> }
>>>> Output as expected- the proper path to Microsoft SDK and
anyways
>>>> certainly not the empty string or null.
>>>>
>>>>
>>>>
>>>> Sorry to ask such a basic question but is anyone on this list
>>>> actually able to clone then compile OpenFX from source using
the
>>>> procedure outlined on the below mentioned page using any of
the
>>>> gradle scripts, (in my instance gradle.win) ?
>>>>
>>>> Seems like first -step level stuff that is done regularly by
>>>> everyone on the list interested in improving or exploring
OpenFX but
>>>> maybe I am wrong about this? Many thanks in advance.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Thursday, September 28, 2017 6:59 PM,
>>>> javafx@use.startmail.comwrote:
>>>>
>>>>
>>>>
>>>>> Hi All,
>>>>> New member to this group. I am encountering a little trouble
when
>>>>> I
>>>>> try to build OpenJFX. I am following the i
Re: Error on build
> Setting WINSDK_DIR on the command line using 'set' or 'export'
>>> doesn't work and neither does setting via the Windows
environment
>>> manager UI.
>>>
>>>
>>> Hardcoding got me past this one:
>>>
>>>
>>> def WINDOWS_SDK_DIR="..." above the check.
>>>
>>> Next error I'm hitting is NativeCompileTask.compile()
>>>
>>>
>>> This is with Windows 10, VS10 Express, WinSDK 7.1, and DirectX
June
>>> 2010.
>>>
>>>
>>> buildSrc/win.gradle has hardcoded paths to VS2017 Professional
so I'm
>>> guessing the devs who wrote this build script have got it
working on a
>>> more modern build environment than the one described in the
docs.
>>>
>>> Will post here if I can get it to build.
>>>
>>>
>>> Cheers,
>>>
>>>
>>> Chris
>>>
>>>
>>> On Tue, October 3, 2017 02:14, jav...@use.startmail.com wrote:
>>>
>>>
>>>
>>>>
>>>> Hi again !
>>>>
>>>>
>>>>
>>>> Well I was able to track down the source of the error I am
>>>> receiving from the gradle build. Unfortunately, the error
persists,
>>>> which is a bit of a mystery. Maybe a gradle maven can enlighten
me
>>>> here.
>>>>
>>>> For some reason, this line on line 90-91 of win.gradle is
throwing
>>>> the exception, although I can prove it ought not to: if
>>>> (WINDOWS_SDK_DIR ==
>>>> null || WINDOWS_SDK_DIR == "") { throw new
GradleException("FAIL:
>>>> WINSDK_DIR not defined");
>>>> I cannot get past this, the exception is triggered, and yet the
>>>> assignment of a value to property WINDOWS_SDK_DIR is quite
clear here
>>>> (line
>>>> of 69 win.gradle): defineProperty("WINDOWS_SDK_DIR",
properties,
>>>> System.getenv().get("WINSDK_DIR"))
>>>> and that system variable is, in fact, set as proved by (my)
running
>>>> this simple program I wrote (which exists in the same directory
as
>>>> win.gradle to exclude any conceivable path issues) and getting
the
>>>> proper outputpublic class WinSDK { public WinSDK() { } public
static
>>>> void main(String[] args) { String sdk =
>>>> (String)System.getenv().get("WINSDK_DIR");
>>>> System.out.println("sdk = " + sdk);
>>>> }
>>>> }
>>>> Output as expected- the proper path to Microsoft SDK and
anyways
>>>> certainly not the empty string or null.
>>>>
>>>>
>>>>
>>>> Sorry to ask such a basic question but is anyone on this list
>>>> actually able to clone then compile OpenFX from source using
the
>>>> procedure outlined on the below mentioned page using any of the
>>>> gradle scripts, (in my instance gradle.win) ?
>>>>
>>>> Seems like first -step level stuff that is done regularly by
>>>> everyone on the list interested in improving or exploring
OpenFX but
>>>> maybe I am wrong about this? Many thanks in advance.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Thursday, September 28, 2017 6:59 PM,
>>>> javafx@use.startmail.comwrote:
>>>>
>>>>
>>>>
>>>>> Hi All,
>>>>> New member to this group. I am encountering a little trouble
when
>>>>> I
>>>>> try to build OpenJFX. I am following the instructions here:
(using
>>>>> Cygwin
>>>>> on Win 7):
>>>>> https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX
>>>>>
>>>>>
>>>>>
>>>>> When I run gradle after cloning the OpenJFX repository, I get
a
>>>>> "build
>>>>> failed with exception" . I include the output from the entire
run
>>>>> just in case it's significant:
>>>>>
>>>>>
>>>>>
>>>>> $ gradle
>>>>> WARNING: An illegal reflective access operation has occurred
>>>>> WARNING: Illegal reflective access by
>>>>> org.gradle.internal.reflect.JavaMethod
>>>>> (file:/C:/gradle/lib/gradle-base-services-3.1.jar) to method
>>>>> java.lang.ClassLoader.getPackages() WARNING: Please consider
>>>>> reporting this to the maintainers of
>>>>
Re: Error on build
Kevin,
Hey hi, nice to meet you.
Even given the exclusion of media and web, I don't think anyone is
going to build it with VS 2010 EE edition, at least as the Gradle
script is now. I am *pretty sure* I am following instructions to the
letter, Is dotted Tees crossed.
The thing is I had zero trouble building the project named JDK 9 on the
same page. So there's some irony for you.
By the time all is said and done, with all the Gradle files and
hardcoded String variables they contain and library versions and tool
versions on the dependency chains from 3rd party suppliers and all the
errata and bugs those tools bring to the mix etc etc etc builds are
basically becoming something akin to magical incantations understood
only by the Shamans who author them. For the rest of us, you say the
words, you push ENTER and hope the demon is summoned, and if not,
well... not LOL .
It's a real-world problem clearly costing we devs both lost
contributions and slowed progress and it's not clear what to do about
it.
Cheers !
On Tuesday, October 3, 2017 9:43 AM, Kevin Rushforth
<kevin.rushfo...@oracle.com> wrote:
The Wiki is out of date. VS 2017 Professional is now required to
build OpenJFX. A fix was just pushed [1] to allow a different build
of VS 2017 than the hard-coded one.
Also, I am still able to build with VS 2010 and VS 2013, which should
work as long as you don't build media or webkit (they aren't built by
default).
-- Kevin
[1] https://bugs.openjdk.java.net/browse/JDK-8187366
Chris Newland wrote:
Hi,
I'm also trying to build OpenJFX on Windows 10 so I can add a
Windows
build to my community OpenJFX build server at
https://chriswhocodes.com
and am hitting the same problems as you.
Setting WINSDK_DIR on the command line using 'set' or 'export'
doesn't
work and neither does setting via the Windows environment manager
UI.
Hardcoding got me past this one:
def WINDOWS_SDK_DIR="..." above the check.
Next error I'm hitting is NativeCompileTask.compile()
This is with Windows 10, VS10 Express, WinSDK 7.1, and DirectX June
2010.
buildSrc/win.gradle has hardcoded paths to VS2017 Professional so
I'm
guessing the devs who wrote this build script have got it working on
a
more modern build environment than the one described in the docs.
Will post here if I can get it to build.
Cheers,
Chris
On Tue, October 3, 2017 02:14, jav...@use.startmail.com wrote:
Hi again !
Well I was able to track down the source of the error I am
receiving
from the gradle build. Unfortunately, the error persists, which is
a bit of
a mystery. Maybe a gradle maven can enlighten me here.
For some reason, this line on line 90-91 of win.gradle is throwing
the
exception, although I can prove it ought not to:
if (WINDOWS_SDK_DIR == null || WINDOWS_SDK_DIR == "") { throw new
GradleException("FAIL: WINSDK_DIR not defined");
I cannot get past this, the exception is triggered, and yet the
assignment of a value to property WINDOWS_SDK_DIR is quite clear
here (line
of 69 win.gradle): defineProperty("WINDOWS_SDK_DIR", properties,
System.getenv().get("WINSDK_DIR"))
and that system variable is, in fact, set as proved by (my) running
this
simple program I wrote (which exists in the same directory as
win.gradle
to exclude any conceivable path issues) and getting the proper
outputpublic class WinSDK { public WinSDK() { }
public static void main(String[] args) { String sdk =
(String)System.getenv().get("WINSDK_DIR");
System.out.println("sdk = " + sdk);
}
}
Output as expected- the proper path to Microsoft SDK and anyways
certainly not the empty string or null.
Sorry to ask such a basic question but is anyone on this list
actually
able to clone then compile OpenFX from source using the procedure
outlined
on the below mentioned page using any of the gradle scripts, (in my
instance gradle.win) ?
Seems like first -step level stuff that is done regularly by
everyone
on the list interested in improving or exploring OpenFX but maybe I
am
wrong about this?
Many thanks in advance.
On Thursday, September 28, 2017 6:59 PM, javafx@use.startmail.comwrote:
Hi All,
New member to this group. I am encountering a little trouble when
I
try to build OpenJFX. I am following the instructions here: (using
Cygwin
on Win 7):
https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX
When I run gradle after cloning the OpenJFX repository, I get a
"build
failed with exception" . I include the output from the entire run
just in
case it's significant:
$ gradle
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by
org.gradle.internal.reflect.JavaMethod
(file:/C:/gradle/lib/gradle-base-services-3.1.jar) to method
java.lang.ClassLoader.getPackages() WARNING: Please consider
reporting
this to the maintainers of org.gradle.internal.reflect.JavaMethod
WARNING: Use --
Re: Error on build
VS 2017 Professional is now required to build OpenJFX.
Ahh I see. I am sure it needs every bit of power offered by the
professional version of Microsoft's excellent dev environment but
unfortunately it cuts me out of building or testing since I don't have
that subscription and it's really rather pricey.
Cheers!
On Tuesday, October 3, 2017 9:43 AM, Kevin Rushforth
<kevin.rushfo...@oracle.com> wrote:
The Wiki is out of date. VS 2017 Professional is now required to
build OpenJFX. A fix was just pushed [1] to allow a different build
of VS 2017 than the hard-coded one.
Also, I am still able to build with VS 2010 and VS 2013, which should
work as long as you don't build media or webkit (they aren't built by
default).
-- Kevin
[1] https://bugs.openjdk.java.net/browse/JDK-8187366
Chris Newland wrote:
Hi,
I'm also trying to build OpenJFX on Windows 10 so I can add a
Windows
build to my community OpenJFX build server at
https://chriswhocodes.com
and am hitting the same problems as you.
Setting WINSDK_DIR on the command line using 'set' or 'export'
doesn't
work and neither does setting via the Windows environment manager
UI.
Hardcoding got me past this one:
def WINDOWS_SDK_DIR="..." above the check.
Next error I'm hitting is NativeCompileTask.compile()
This is with Windows 10, VS10 Express, WinSDK 7.1, and DirectX June
2010.
buildSrc/win.gradle has hardcoded paths to VS2017 Professional so
I'm
guessing the devs who wrote this build script have got it working on
a
more modern build environment than the one described in the docs.
Will post here if I can get it to build.
Cheers,
Chris
On Tue, October 3, 2017 02:14, jav...@use.startmail.com wrote:
Hi again !
Well I was able to track down the source of the error I am
receiving
from the gradle build. Unfortunately, the error persists, which is
a bit of
a mystery. Maybe a gradle maven can enlighten me here.
For some reason, this line on line 90-91 of win.gradle is throwing
the
exception, although I can prove it ought not to:
if (WINDOWS_SDK_DIR == null || WINDOWS_SDK_DIR == "") { throw new
GradleException("FAIL: WINSDK_DIR not defined");
I cannot get past this, the exception is triggered, and yet the
assignment of a value to property WINDOWS_SDK_DIR is quite clear
here (line
of 69 win.gradle): defineProperty("WINDOWS_SDK_DIR", properties,
System.getenv().get("WINSDK_DIR"))
and that system variable is, in fact, set as proved by (my) running
this
simple program I wrote (which exists in the same directory as
win.gradle
to exclude any conceivable path issues) and getting the proper
outputpublic class WinSDK { public WinSDK() { }
public static void main(String[] args) { String sdk =
(String)System.getenv().get("WINSDK_DIR");
System.out.println("sdk = " + sdk);
}
}
Output as expected- the proper path to Microsoft SDK and anyways
certainly not the empty string or null.
Sorry to ask such a basic question but is anyone on this list
actually
able to clone then compile OpenFX from source using the procedure
outlined
on the below mentioned page using any of the gradle scripts, (in my
instance gradle.win) ?
Seems like first -step level stuff that is done regularly by
everyone
on the list interested in improving or exploring OpenFX but maybe I
am
wrong about this?
Many thanks in advance.
On Thursday, September 28, 2017 6:59 PM, javafx@use.startmail.comwrote:
Hi All,
New member to this group. I am encountering a little trouble when
I
try to build OpenJFX. I am following the instructions here: (using
Cygwin
on Win 7):
https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX
When I run gradle after cloning the OpenJFX repository, I get a
"build
failed with exception" . I include the output from the entire run
just in
case it's significant:
$ gradle
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by
org.gradle.internal.reflect.JavaMethod
(file:/C:/gradle/lib/gradle-base-services-3.1.jar) to method
java.lang.ClassLoader.getPackages() WARNING: Please consider
reporting
this to the maintainers of org.gradle.internal.reflect.JavaMethod
WARNING: Use --illegal-access=warn to enable warnings of further
illegal reflective access operations WARNING: All illegal access
operations will be denied in a future release
:buildSrc:generateGrammarSource UP-TO-DATE
:buildSrc:compileJava UP-TO-DATE
:buildSrc:compileGroovy UP-TO-DATE
:buildSrc:processResources UP-TO-DATE
:buildSrc:classes UP-TO-DATE
:buildSrc:jar UP-TO-DATE
:buildSrc:assemble UP-TO-DATE
:buildSrc:compileTestJava UP-TO-DATE
:buildSrc:compileTestGroovy UP-TO-DATE
:buildSrc:processTestResources UP-TO-DATE
:buildSrc:testClasses UP-TO-DATE
:buildSrc:test UP-TO-DATE
:buildSrc:check UP-TO-DATE
:buildSrc:build UP-TO-DATE
FAILURE: Build failed with an exception.
* Where:
Script 'C:\cygwin64\home\mdbg\rt\buildSrc\win.gradle' line:
Re: Error on build
Hi Chris,
I am on Windows 7 and WinSDK 7.0A and DirectX June 10, 2010; not sure
if any of that makes a difference here or not.
I cloned a couple weeks ago and in my win.gradle on line 68 it has a
hard coded absolute path thus:
defineProperty("WINDOWS_VS_VSINSTALLDIR", properties, "c:/Program Files
(x86)/Microsoft Visual Studio 12.0");
which contradicts (?) the directive on the website to use Visual Studio
10.0 (the website says Express Edition will do, so that is what I am
using also). It is also different than what you say you have, which is
VS2017 if I understood you correctly. I am not sure what to make of
that.
I changed that hard coded path above from "12.0" to read "10.0" then
double checked to make sure that was a legit path on my machine, but
it didn't get me past my error.
Here is a question maybe you know the answer to .
I am assuming that merely editing win.gradle then immediately invoking
gradle in cygwin will cause the new edits I made to win.gradle to be
processed appropriately by gradle.
Is that correct?
This is opposed to editing win.gradle, but then somehow compiling that
gradle source, as I would have to do with a java source file, in order
to see the changes at runtime.
(Now you know how little I know about gradle.)
Cheers
Charles
On Tuesday, October 3, 2017 3:36 AM, Chris Newland
wrote:
Hi,
I'm also trying to build OpenJFX on Windows 10 so I can add a Windows
build to my community OpenJFX build server at
https://chriswhocodes.com
and am hitting the same problems as you.
Setting WINSDK_DIR on the command line using 'set' or 'export'
doesn't
work and neither does setting via the Windows environment manager UI.
Hardcoding got me past this one:
def WINDOWS_SDK_DIR="..." above the check.
Next error I'm hitting is NativeCompileTask.compile()
This is with Windows 10, VS10 Express, WinSDK 7.1, and DirectX June
2010.
buildSrc/win.gradle has hardcoded paths to VS2017 Professional so I'm
guessing the devs who wrote this build script have got it working on
a
more modern build environment than the one described in the docs.
Will post here if I can get it to build.
Cheers,
Chris
On Tue, October 3, 2017 02:14, jav...@use.startmail.com wrote:
Hi again !
Well I was able to track down the source of the error I am receiving
from the gradle build. Unfortunately, the error persists, which is a
bit of
a mystery. Maybe a gradle maven can enlighten me here.
For some reason, this line on line 90-91 of win.gradle is throwing
the
exception, although I can prove it ought not to:
if (WINDOWS_SDK_DIR == null || WINDOWS_SDK_DIR == "") { throw new
GradleException("FAIL: WINSDK_DIR not defined");
I cannot get past this, the exception is triggered, and yet the
assignment of a value to property WINDOWS_SDK_DIR is quite clear
here (line
of 69 win.gradle): defineProperty("WINDOWS_SDK_DIR", properties,
System.getenv().get("WINSDK_DIR"))
and that system variable is, in fact, set as proved by (my) running
this
simple program I wrote (which exists in the same directory as
win.gradle
to exclude any conceivable path issues) and getting the proper
outputpublic class WinSDK { public WinSDK() { }
public static void main(String[] args) { String sdk =
(String)System.getenv().get("WINSDK_DIR");
System.out.println("sdk = " + sdk);
}
}
Output as expected- the proper path to Microsoft SDK and anyways
certainly not the empty string or null.
Sorry to ask such a basic question but is anyone on this list
actually
able to clone then compile OpenFX from source using the procedure
outlined
on the below mentioned page using any of the gradle scripts, (in my
instance gradle.win) ?
Seems like first -step level stuff that is done regularly by
everyone
on the list interested in improving or exploring OpenFX but maybe I
am
wrong about this?
Many thanks in advance.
On Thursday, September 28, 2017 6:59 PM, jav...@use.startmail.com
wrote:
Hi All,
New member to this group. I am encountering a little trouble when
I
try to build OpenJFX. I am following the instructions here: (using
Cygwin
on Win 7):
https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX
When I run gradle after cloning the OpenJFX repository, I get a
"build
failed with exception" . I include the output from the entire run
just in
case it's significant:
$ gradle
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by
org.gradle.internal.reflect.JavaMethod
(file:/C:/gradle/lib/gradle-base-services-3.1.jar) to method
java.lang.ClassLoader.getPackages() WARNING: Please consider
reporting
this to the maintainers of org.gradle.internal.reflect.JavaMethod
WARNING: Use --illegal-access=warn to enable warnings of further
illegal reflective access operations WARNING: All illegal access
operations will be denied in a future release
:buildSrc:generateGrammarSource UP-TO-DATE
:buildSrc:compileJava UP-TO-DATE
Re: Error on build
Hi again !
Well I was able to track down the source of the error I am receiving
from the gradle build. Unfortunately, the error persists, which is a
bit of a mystery. Maybe a gradle maven can enlighten me here.
For some reason, this line on line 90-91 of win.gradle is throwing the
exception, although I can prove it ought not to:
if (WINDOWS_SDK_DIR == null || WINDOWS_SDK_DIR == "") {
throw new GradleException("FAIL: WINSDK_DIR not defined");
I cannot get past this, the exception is triggered, and yet the
assignment of a value to property WINDOWS_SDK_DIR is quite clear here
(line of 69 win.gradle):
defineProperty("WINDOWS_SDK_DIR", properties, System.getenv().get("WINSDK_DIR"))
and that system variable is, in fact, set as proved by (my) running
this simple program I wrote (which exists in the same directory as
win.gradle to exclude any conceivable path issues) and getting the
proper outputpublic class WinSDK {
public WinSDK() {
}
public static void main(String[] args) {
String sdk = (String)System.getenv().get("WINSDK_DIR");
System.out.println("sdk = " + sdk);
}
}
Output as expected- the proper path to Microsoft SDK and anyways
certainly not the empty string or null.
Sorry to ask such a basic question but is anyone on this list actually
able to clone then compile OpenFX from source using the procedure
outlined on the below mentioned page using any of the gradle scripts,
(in my instance gradle.win) ?
Seems like first -step level stuff that is done regularly by everyone
on the list interested in improving or exploring OpenFX but maybe I am
wrong about this?
Many thanks in advance.
On Thursday, September 28, 2017 6:59 PM, jav...@use.startmail.com
wrote:
Hi All,
New member to this group. I am encountering a little trouble when I
try to build OpenJFX. I am following the instructions here: (using
Cygwin on Win 7):
https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX
When I run gradle after cloning the OpenJFX repository, I get a
"build
failed with exception" . I include the output from the entire run
just
in case it's significant:
$ gradle
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by
org.gradle.internal.reflect.JavaMethod
(file:/C:/gradle/lib/gradle-base-services-3.1.jar) to method
java.lang.ClassLoader.getPackages()
WARNING: Please consider reporting this to the maintainers of
org.gradle.internal.reflect.JavaMethod
WARNING: Use --illegal-access=warn to enable warnings of further
illegal reflective access operations
WARNING: All illegal access operations will be denied in a future
release
:buildSrc:generateGrammarSource UP-TO-DATE
:buildSrc:compileJava UP-TO-DATE
:buildSrc:compileGroovy UP-TO-DATE
:buildSrc:processResources UP-TO-DATE
:buildSrc:classes UP-TO-DATE
:buildSrc:jar UP-TO-DATE
:buildSrc:assemble UP-TO-DATE
:buildSrc:compileTestJava UP-TO-DATE
:buildSrc:compileTestGroovy UP-TO-DATE
:buildSrc:processTestResources UP-TO-DATE
:buildSrc:testClasses UP-TO-DATE
:buildSrc:test UP-TO-DATE
:buildSrc:check UP-TO-DATE
:buildSrc:build UP-TO-DATE
FAILURE: Build failed with an exception.
* Where:
Script 'C:\cygwin64\home\mdbg\rt\buildSrc\win.gradle' line: 91
* What went wrong:
A problem occurred evaluating script.
FAIL: WINSDK_DIR not defined
* Try:
Run with --stacktrace option to get the stack trace. Run with --info
or
--debug option to get more log output.
BUILD FAILED
Total time: 1.376 secs
I should add that even though the tutorial doesn't mention to do it,
I
cd-ed into the folder named rt, which was created by Mercurial when I
cloned OpenJFX, I called gradle from there. Calling it from the
directory containing rt resulted in nothing happening , which makes
sense afaik.
the variable WINSDK is not one I am familiar with- it's not any
environment or system variable on my machine and the tutorial doesn't
say anything about it. I hesitate to start arbitrarily hacking build
files based on error messages. It seems as though it ought to just
work
and perhaps this is a bug I should report or is it something else ?
Thank you!
Error on build
Hi All, New member to this group. I am encountering a little trouble when I try to build OpenJFX. I am following the instructions here: (using Cygwin on Win 7): https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX When I run gradle after cloning the OpenJFX repository, I get a "build failed with exception" . I include the output from the entire run just in case it's significant: $ gradle WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by org.gradle.internal.reflect.JavaMethod (file:/C:/gradle/lib/gradle-base-services-3.1.jar) to method java.lang.ClassLoader.getPackages() WARNING: Please consider reporting this to the maintainers of org.gradle.internal.reflect.JavaMethod WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release :buildSrc:generateGrammarSource UP-TO-DATE :buildSrc:compileJava UP-TO-DATE :buildSrc:compileGroovy UP-TO-DATE :buildSrc:processResources UP-TO-DATE :buildSrc:classes UP-TO-DATE :buildSrc:jar UP-TO-DATE :buildSrc:assemble UP-TO-DATE :buildSrc:compileTestJava UP-TO-DATE :buildSrc:compileTestGroovy UP-TO-DATE :buildSrc:processTestResources UP-TO-DATE :buildSrc:testClasses UP-TO-DATE :buildSrc:test UP-TO-DATE :buildSrc:check UP-TO-DATE :buildSrc:build UP-TO-DATE FAILURE: Build failed with an exception. * Where: Script 'C:\cygwin64\home\mdbg\rt\buildSrc\win.gradle' line: 91 * What went wrong: A problem occurred evaluating script. FAIL: WINSDK_DIR not defined * Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. BUILD FAILED Total time: 1.376 secs I should add that even though the tutorial doesn't mention to do it, I cd-ed into the folder named rt, which was created by Mercurial when I cloned OpenJFX, I called gradle from there. Calling it from the directory containing rt resulted in nothing happening , which makes sense afaik. the variable WINSDK is not one I am familiar with- it's not any environment or system variable on my machine and the tutorial doesn't say anything about it. I hesitate to start arbitrarily hacking build files based on error messages. It seems as though it ought to just work and perhaps this is a bug I should report or is it something else ? Thank you!
