Re: "Internal review ID : 9062887" (Re: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script

[Anthony Vanelverdinghe]

On 22/01/2020 18:52, Rony G. Flatscher wrote:

Hi Anthony,

On 22.01.2020 17:07, Anthony Vanelverdinghe wrote:
Your issue has been converted into a JDK issue, with your testcase 
attached [1].


Thank you *very* much for this information!

Normally you should’ve received an e-mail at the time of this 
conversion,


Just searched all my e-mail folders and could not find it (looking for 
"FXMLLoader" in the subject of e-mails as the bug title contains that 
word) but could not find a matching e-mail for whatever reasons.


but you can check this yourself by using the internal review ID as in 
[2]. If you’d like to contribute a fix, see [3].


Kind regards, Anthony

[1] https://bugs.openjdk.java.net/browse/JDK-8234959 
<https://bugs.openjdk.java.net/browse/JDK-8234959>


[2] https://bugs.openjdk.java.net/browse/JI-9062887 
<https://bugs.openjdk.java.net/browse/JI-9062887>


[3] https://github.com/openjdk/jfx <https://github.com/openjdk/jfx>

Thank you also for these links (and I learned something new on how to 
check for it using the internal review id with your [2], thanks a lot 
for this hint as well)!


Will go back and study all the necessary procedures (forgot a lot 
since reading them the last time) and will try to contribute the fix 
in the proper way but it may take me a little while (currently quite 
busy around here).


---

Maybe one more question: there would be an optimization possible by 
compiling scripts for script engines that have the 
javax.script.Compilable interface implemented and use the compiled 
version to execute/evaluate the scripts (may be helpful for event 
handler code e.g. for onMouseMove event handlers). Can the fix include 
such an optimization or should there be a separate discussion/RFE for 
it beforehand? (Adding this would be trivial in the context of the 
fix, however the bug description would not hint at such an optimization.)


In my opinion, this should be filed as a separate issue, since it's 
unrelated to the current issue and is an enhancement, rather than a bug.


---rony



Kind regards, Anthony

RE: "Internal review ID : 9062887" (Re: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script

[Anthony Vanelverdinghe]

Hi Rony

Your issue has been converted into a JDK issue, with your testcase attached 
[1]. Normally you should’ve received an e-mail at the time of this conversion, 
but you can check this yourself by using the internal review ID as in [2]. If 
you’d like to contribute a fix, see [3].

Kind regards, Anthony

[1] https://bugs.openjdk.java.net/browse/JDK-8234959
[2] https://bugs.openjdk.java.net/browse/JI-9062887
[3] https://github.com/openjdk/jfx


From: Rony G. Flatscher
Sent: Wednesday, 22 January 2020 14:44
To: openjfx-dev@openjdk.java.net
Subject: Re: "Internal review ID : 9062887" (Re: FXMLLoader: not supplying 
filename to script engine, not supplying event object as argument to script

Last November I submitted an appropriate bug report and mailed the testcase on 
November 27th per
Oracle's request without hearing anything to this date.

Therefore I was wondering how long such an assessment usually takes place and 
what to do? (Maybe it
"fell off the desk" due to the end-of-year stress and Christmas vacation?) Any 
advice?

---rony


On 21.11.2019 15:39, Rony G. Flatscher wrote:
> As the zip-archive attachment got stripped, for a brief time the zip-archive 
> can be fetched from
> .
>
> ---rony
>
> On 21.11.2019 15:29, Rony G. Flatscher wrote:
>> On 15.11.2019 16:08, Rony G. Flatscher wrote:
>>> On 14.11.2019 22:57, Kevin Rushforth wrote:
 On 11/14/2019 10:12 AM, Rony G. Flatscher wrote:
> On 14.11.2019 16:34, Rony G. Flatscher wrote:
>> On 13.11.2019 19:50, Kevin Rushforth wrote:
>>> On 11/13/2019 9:42 AM, Rony G. Flatscher wrote:
> ... cut ...
 To reproduce the testcase one would need ooRexx and the Java bridge 
 BSF4ooRexx (all
 opensource) for
 which I could come up with a zip-archive (assuming binaries within 
 should be 64-bit) and a
 script to
 set up the environment either for Windows, Linux or MacOS, whatever 
 you advise. Would that be
 o.k.?
>>> We prefer not to rely on third-party libraries for test cases. In any 
>>> case we would not be able to
>>> use that for a regression test / unit test.
> If test units really seem to be important in this particular case, one 
> possibility would be to
> create a minimalistic ScriptEngine implementation in pure Java just for 
> the sole purpose to allow
> the creation of a test unit that is able to assert that FXMLLoader puts 
> the ScriptEngine.ARGV and
> ScriptEngine.FILENAME entries into the ENGINE_SCOPE Bindings. E.g. having 
> the ScriptEngine's eval()
> methods return the ScriptContext at invocation time in order to allow 
> inspection of the Bindings.
> This way it would become also possible to write in addition test units 
> that also check whether all
> FXML elements that carry a fx:id are really placed into the GLOBAL_SCOPE 
> Bindings.
 Something like that seems reasonable, and would avoid a dependence on 
 Nashorn, which in addition
 to having all the problems you mentioned, is deprecated for removal.

> However,
 Did you have something more to add?
>>> No, sorry for that. Rewrote my e-mail and had sent it too early by mistake 
>>> and without noticing.
>>>
>>> Will study all the procedures and create a testcase to be submitted at 
>>> 
>>> as per your advice (and will report back under this thread once submitted). 
>>> The testcase would use
>>> an artificial ScriptEngine implementation that could be used for testunit 
>>> testing as well. This
>>> might take a while due to other obligations that I will have to meet during 
>>> the next few days.
>>>
>>> ---rony
>> O.K., so came up with a test case that contains an artificial script engine 
>> implementation for
>> logging the eval() invocations together with the scripts to execute and the 
>> ScriptContext
>> ENGINE_SCOPE and GLOBAL_SCOPE Bindings at the time of the invocation. (It is 
>> meant to be also usable
>> for creating script engine related test units for Java script hosts.)
>>
>> Packaged the source and binaries of that script engine as jar file that one 
>> merely needs to put on
>> the CLASSPATH or add as a module.
>>
>> An updated FXMLLoader patch suggesting a fix is included as well. This 
>> version appends the line
>> number to the file name if the script to be evaluated is embedded in the 
>> fxml-file, such that in
>> case of an error it becomes possible to quickly find it in larger fxml files.
>>
>> With the zip-archive done I went to the Oracle Java Bug Database and just 
>> entered a bug report at
>>  got the internal "ID 
>> : 9062887".
>>
>> As it was not possible to attach/upload the zip-archive at this point, I 
>> will attach the zip-archive
>> (co

Re: error in tutorial

[Anthony Vanelverdinghe]

Hi

Some observations:
This is the mentioned e-mail: 
http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-September/022497.html
The lib folder contains a src.zip file, both in JDK 13.0.1 and in JavaFX 
SDK 13.0.1, so this is consistent.

For NetBeans and IntelliJ IDEA (I didn't check Eclipse):
- neither supports jmod files in libraries (see [1])
- both support selecting individual jar files, after which things work 
as expected
- neither constructs an optimal modulepath, even if the application is 
modular


So I believe that this is mostly just a documentation issue: rather than 
saying "add the lib folder of the SDK" it should say "add all jar files 
in the lib folder of the SDK". Additionally, IDEs should be improved to 
support jmod files in libraries, and to construct optimal modulepaths 
for modular applications.


Kind regards,
Anthony

[1] https://youtrack.jetbrains.com/issue/IDEA-171448

On 28/12/2019 20:11, Ty Young wrote:






On 12/28/19 4:53 AM, Johan Vos wrote:

Hi Ty,

Since I have absolutely no idea what you are talking about, I have a 
few questions:


1. "... push changes to the repo..."? -> It would help giving a bit 
context instead of talking about "the repo". Since this is the 
openjfx-dev list, chances are high you're talking about the JavaFX 
repository at https://github.com/openjdk/jfx. In that case, please 
read the README and CONTRIBUTING files there for advice on how to 
propose/make changes (note that this will probably take longer than 1 
minute, as we have strong quality checks in place). If you talk about 
a different "repo", please follow the explicit or implicit rules on 
that repo(sitory). For example, if you talk about 
https://github.com/openjfx/openjfx-docs , please create an issue and 
file a PR, and work with the community to get it accepted. (note that 
in this case, this should not be discussed on the openjfx-dev list 
(note the *dev*)).



This is not an issue of documentation. IDEs can and do provide the 
ability to designate an entire folder as a location of project 
libraries. You can specify a directory manually via command line in 
which contains Java 9 modules. To continue to entertain the idea that 
this is an issue of documentation is simply crazy. It's an easily 
fixable technical error.





2. You refer to informal or formal talks you had, but it is totally 
unclear to me who you talked to about what. Frankly, we spent lots of 
time moving all code and as much as possible the documentation to 
github, so we can easily track discussions. (for JavaFX bugs, we use 
JBS, so that can be discussed there) If someone said "it’s the way 
we’ve always done it”" please refer to the issue where your request 
has been made and subsequently rejected, so I can have a look at the 
context,



It was an email a very long time ago on this list. Too lazy to dig it 
up, but I'm pretty sure it was from Kevin Rushforth. Again, very long 
time ago at this point.





3. Can you write a few words about what the word "Community" means to 
you? Many people in the JavaFX Ecosystem spent tons of spare time in 
making the JavaFX "Community" a friendly place. I'm interested in 
your opinion about that word. To give a few options, does it mean
A: I insult people and companies, use words like "smoking shrooms" 
and "stubborn" and I expect everything I think about to be fixed 
magically (since I suppose the volunteers have no life apart from 
doing what I want them to do)



"community" is a funny word to describe JavaFX given it is 100% owned 
by Oracle and which no one(AFAIK) can contribute to without signing 
away their rights to their own code.



If this was a feature request I'd understand this nonsense but that's 
not at all what this is. This is a self created, self perpetuated, and 
needlessly self harming *technical* error defended using the worst 
possible defense against very real issues(the creation of this thread 
is proof). Source files(or zips containing such) are not libraries(AKA 
"libs") and it causes IDE issues(among other things). The fix is 
*really* simple.



and the whole (in essence) "everyone who works on JavaFX is a someone 
doing it in their free time is BS. Oracle developers are payed to work 
on JavaFX and are the ones who originally made JavaFX(AFAIK) and 
(presumably) the Gradle script. If someone with basically no knowledge 
of Gradle such as myself can scan through a file or use ctrl + f and 
read variable names then I'd hope someone with actual experience could 
do better. Maybe I'm wrong and am the one in actuality that is smoking 
shrooms.



B: I friendly discuss issues and opportunities with fellow community 
members, where I respect other opinions, keep discussions polite and 
technical.



That's funny because I seem to remember during a JDK(or maybe it was 
exclusively JavaFX?) event that a presenter made a rather rude joke 
about my multi-threading issue I brought up on this list a long time 
ago. I don't remember specifically who made 

JDK-8180368 javapackager and Maven Toolchains

[Anthony Vanelverdinghe]

Hi

This issue [1] was given lower priority because "reproducing the bug 
requires intentionally setting JAVA_HOME to old JDK and using files from 
new one".
However, I just want to point out that this is not some artificial 
construction: Maven Toolchains [2] allow to build projects with a JDK 
which is different than the one Maven itself is running on. In my case, 
this issue was triggered by running Maven on JDK 8, while building with 
a JDK 9 toolchain.


[1] https://bugs.openjdk.java.net/browse/JDK-8180368
[2] 
http://maven.apache.org/plugins/maven-toolchains-plugin/toolchains/jdk.html


Kind regards,
Anthony

Re: Planning for JavaFX.next

[Anthony Vanelverdinghe]

Hi Jonathan

Personally, I'd love to see
* some particular media enhancements, namely audio device enumeration 
and selection [1] and support for keyboard "multimedia keys" [2]
* TabPane improvements to be on a par with browsers (support for 
reordering/dragging [3], having a close button on all tabs, allow to 
"middle-click close" non-active tabs, etc.)


[1] https://bugs.openjdk.java.net/browse/JDK-8091008
[2] https://bugs.openjdk.java.net/browse/JDK-8090319
[3] https://bugs.openjdk.java.net/browse/JDK-8092098

Kind regards
Anthony

On 8/12/2016 0:45, Jonathan Giles wrote:

Hi folks,

Development on JDK 9 is slowly starting to ramp down, and we are 
starting to turn our attention to the goals for JavaFX in JDK 10 and 
beyond. We are starting to compile our list of what we think is 
important, but we really want to hear from the community about what 
their highest priorities are to them. As always, it's important to 
keep in mind what JavaFX is (e.g. it isn't aiming to be a 
high-performance game engine), but even still there are bound to be a 
number of places where people might want to weigh in, for example:


 * New layout containers (e.g. Flexbox)
 * Public APIs for UI control behaviors
 * Marlin renderer enabled by default
 * Support for CSS animations
 * CSS performance improvements
 * TableView improvements (cell spanning, row / column freezing, etc)
 * TableView performance
 * Focus traversal API
 * WebGL support in WebView
 * Improved image I/O support
 * A JavaFX equivalent of the AWT Desktop APIs
 * Multi-res image API
 * NIO-backed writable images

If there are other areas of interest that aren't listed here, please 
start discussing them and we can work together to determine 
priorities. If all you want to do is add a +1 for one of more of the 
items above, even that will be very useful.


Thanks,
-- Jonathan

Re: JavaFX WebView TLS/SSL Certificate Revocation Check

[Anthony Vanelverdinghe]

Hi Michael

I just tested this and everything works as expected, i.e.:
- JavaFX' WebView uses OCSP when the 3 related properties are set (using 
WireShark to verify)

- https://revoked.grc.com fails when using OCSP, and succeeds when not
- https://www.coinbase.com succeeds either way

So apparently this is something specific about your environment and/or 
application (my environment is Java 8u66 on Windows 10, and the test 
case I used is below). Therefore, I think it would be best if you'd file 
an issue at http://bugs.java.com with a minimal test case & detailed 
information about your environment. This will help the OpenJFX team to 
reproduce your issue, and help you to follow up on it.


Kind regards, Anthony

PS: the test case I ran (imports omitted for brevity):

public class TestOcsp extends Application {

@Override
public void start(Stage primaryStage) {
Security.setProperty("ocsp.enable", "true");
System.setProperty("com.sun.net.ssl.checkRevocation", "true");
System.setProperty("com.sun.security.enableCRLDP", "true");

WebView view = new WebView();
primaryStage.setScene(new Scene(view, 800, 600));
primaryStage.show();

Platform.runLater(() -> {
WebEngine engine = view.getEngine();
Worker loadWorker = engine.getLoadWorker();
loadWorker.stateProperty().addListener((property, oldState, 
newState) -> System.out.println(oldState + " -> " + newState));

//engine.load("https://revoked.grc.com/";);
engine.load("https://www.coinbase.com/";);
});
}

}


On 5/01/2016 1:03, mike.ennen at gmail.com (Michael Ennen) wrote:

Kevin,

After some further exploration I see that indeed certificate revocation
does seem to be enabled through:

Security.setProperty("ocsp.enable", "true");
System.setProperty("com.sun.security.enableCRLDP", "true");
System.setProperty("com.sun.net.ssl.checkRevocation", "true");

However, this only seems to active CRL (as WireShark and oscp debug
properties both show no OSCP related activity) and furthermore, and more
importantly, this will cause JavaFX WebView to throw an SSL handshake
failed message (which, by the way, could certainly be more informative and
better implemented by passing along the exception cause Throwable instance)
for apparent false-positives. That is, just try connected to, for example,
https://www.coinbase.com/ with the 3 properties above enabled (it fails).

Thanks,

On Mon, Jan 4, 2016 at 3:23 PM, Kevin Rushforth 
wrote:


Try the following:

System.setProperty("com.sun.net.ssl.checkRevocation", "true");

-- Kevin


Michael Ennen wrote:


Hello,

I will keep this short and brief. If one attempts to use the WebView
control to load the following page:

https://revoked.grc.com/

The page is loaded, SSL handshake completes successfully, and it is
displayed and no exceptions are thrown
(e.g. webView.getEngine().getLoadWorker().getException() is null) and the
WorkerState goes to Worker.State.SUCCEEDED.

However, the certificate of this page is indeed revoked.

I understand that the WebView uses HttpsUrlConnection under the covers,
and
so I did some googling about OSCP/CRL (which are certificate revocation
protocols, for lack of a better term). It seems that OSCP can be enabled
via:

Security.setProperty("ocsp.enable", "true");

and, as a fallback, CRL can be enabled via:

System.setProperty("com.sun.security.enableCRLDP", "true");

However, neither of these make any difference in regards to the successful
outcome posted above.

One really disgusting workaround to this problem would be to write a
TrustManager (which is extremely difficult in my estimation, and prone to
error) that checks for certificate revocation (by using, for example,
the sun.security.provider.certpath.OSCPChecker class) but since there is
no
way to hook into the validation check of an existing TrustManager, all of
the existing functionality would have to be duplicated.

Considering the WebView can be used essentially as a browser (especially
given the fact that it is based on WebKit) I think this is quite a serious
issue (and indeed is a serious issue for my particular application).

Has anyone run into this problem and come up with a solution? Is this a
known bug? Is there anything I can do to fix it?

Thanks very much,

Re: Where to sign up for bug tracker

[Anthony Vanelverdinghe]

Hi Rahman

You can follow your bug by using the following URL:
https://bugs.openjdk.java.net/browse/JI-9027150
The JI (Java Incidents) project is not publicly visible, so this will give
you the OpenJDK Log In page for now. However, as soon as a JDK issue is
created for your report, this same URL will redirect you to the appropriate
JDK issue.
For more information, please refer to this page:
https://wiki.openjdk.java.net/display/general/JBS+Overview

Kind regards,
Anthony

2015-12-04 10:58 GMT+01:00 Rahman USTA :

> Hey Kevin;
>
> I filed the bug, where will I follow the review process ? JI-9027150
>
> Thanks.
>
> 2015-12-03 16:09 GMT+02:00 Rahman USTA :
>
> > Thank you Kevin, it is a bit tiresome but ok, I filed the bug.
> >
> > 2015-12-03 15:54 GMT+02:00 Kevin Rushforth :
> >
> >> See the OpenJFX Wiki [1] for information about reporting a bug.
> >> Application developers should file a bug at bugs.java.com [2].
> >>
> >> -- Kevin
> >>
> >> [1]
> https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report
> >> [2] http://bugs.java.com/
> >>
> >>
> >>
> >> Rahman USTA wrote:
> >>
> >>> Hi;
> >>>
> >>> I want to file a bug on https://id.openjdk.java.net/console/login ,
> but
> >>> how
> >>> wifll I create an account for bug tracker ?
> >>>
> >>> Thanks.
> >>>
> >>>
> >>>
> >>
> >
> >
> > --
> > Rahman USTA
> > Istanbul JUG
> > https://github.com/rahmanusta 
> >
>
>
>
> --
> Rahman USTA
> Istanbul JUG
> https://github.com/rahmanusta 
>