Re: JavaFX features in JDK 9
coughwrite once, run anywhere/cough Sent from my iPhone On 29 Jun 2015, at 21:45, Michał Zegan webczat_...@poczta.onet.pl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Does it mean platform support for linux won't be implemented now, or at all? I usually use windows, but still depend on that support because I sometimes use linux, so I am interested about that. W dniu 2015-06-29 o 22:40, Kevin Rushforth pisze: There is public API in 8u40 to support accessibility. Applications using standard JavaFX controls can, for example, use the accessibleText property to define the text that the screen reader will speak or the accessibleHelp property to provide a more detailed description. These properties have reasonable defaults, but can be overridden by applications. Additionally, if you use the labelFor property to point to a Control that the Label is associated with, the accessibility framework will use that when the screen reader is active. Custom controls can override the queryAccessibleAttribute, executeAccessibleAction, and notifyAccessibleAttributeChanged methods. As for platform support, we currently support Windows and Mac platforms. We have no plan to make FX accessible on Linux . -- Kevin Michał Zegan wrote: I saw it, and it seems promising, but: first, there is probably, or I heard it wrong? no public api for making accessibility related stuff... Also, I believe there is no linux accessibility bridge as opposed to windows and mac. And I do not know if I am wrong, or when this is going to be implemented. W dniu 2015-06-29 o 20:30, Kevin Rushforth pisze: JavaFX accessibility is already implemented and was delivered in JDK 8u40. -- Kevin Michał Zegan wrote: What about accessibility work? Work on it has been started, but not sure if it is still targetted for 9. W dniu 2015-06-27 o 20:16, Mike pisze: a lot of FULL blown Webrtc support and building something in Javafx (like Scene Builder) that Proves Webrtc support would be awesome. Ditto to Webgl support. On Sat, Jun 27, 2015 at 8:07 AM, Kevin Rushforth kevin.rushfo...@oracle.com wrote: Hi Felix, Sorry for the delay. Most of us were still pretty focused on 8u60, but we are turning our attention to JDK 9 now. The focus for JDK 9 is Jigsaw. The currently planned big features (JEPs) for FX in JDK 9 are these: JEP 253: Prepare JavaFX UI Controls CSS APIs for Modularization JEP 257: Update JavaFX/Media to Newer Version of GStreamer Related to Jigasw, we intend to look into new API for heavily used internal methods / classes since they will no longer be accessible otherwise. We also plan to update WebKit at least one more time, and will likely do a few RFEs such as better Hi-DPI support (with API control) on Mac, Windows, Linux. We don't currently plan any other big features for 9, but will consider additional RFEs if they are important to enough developers and if they fit into the time frame. -- Kevin Felix Bembrick wrote: Anyone got anything or is there a link somewhere that talks about these? On 15 June 2015 at 22:00, Felix Bembrick felix.bembr...@gmail.com wrote: I realise we are a long way off JDK 9 still and with crucial features such as Jigsaw still a little up in the air but is it possible someone could itemise the most likely new features, enhancements and bug fixes that we will see in JavaFX when JDK 9 is released? Of course it's purely speculation at this point but it would assist me greatly to have some of idea of where JavaFX is heading and which areas are seen as most important. Thanks, Felix -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJVka5MAAoJEHb1CzgxXKwYbKwP/RFa3NjMnXWFc6o5EzIFYlh3 5ExLUgu+IVWr1fewrf+KTcR9WmyXWN2ju8zkRb7nhjSiA+5XAf3vbvUBGTaaa1A4 92Fd0W2Mfj8M9F3Px5QP1TMS1BO7GrO12zsB+obmBvWA/xWy0GEoctja8ohT5aNf hs7foi4pZRK6abMvxd94WdSNh/KhzqNvllD3tIkqlasTOOH1i7bEreQ9sxN6+DRF JB87JSRuml7rYEgsOSx5Z2EE7YdgqYjdfHSAIwBvqkRDQZuOp8RrWzU6wFyyzhlm RtuAQJWj1I2DNbZE9iCNJzYqajnp0OellbxGr9SrJaVPpqNjjbw6zoGZ3bhgCAow BAZUlllG9UVoKcl1bHDvmB01RG2JP7RtBByS0cbqGQM0/YqtknbNWpl2r5kTVyH1 EZnfkXmXYi/lqgyRBf1/WqlJnuT10ra7oAQytUajZ3cQJNbRwuFycV0yvbGo11xS eaQO2ECgYyubLE8vsnw1L+2U4wLAMXY9Q3Ob1kLq12UEYB8WMoLZ+IAixUUJ6abB reI+epG/Bh27R0fHChkHEgY65TIMRt8RtOXxzs+Nf0VVAC4Lj9378Y8ZEr14RbcZ mO+5TvyqfDhyIP4WevGDF2/tQTvlsAzl7UuiTtD3pWZ+CpN2WeNimBHPN2ZI6lii Mfj0LIA1IawOjtYjlnHz =lXSV -END PGP SIGNATURE-
Re: JavaFX features in JDK 9
Maybe it should its aspirations a little higher, especially with the advent of unity, webgl or even scenegraph impls such as jmonkeyengine that do. Sent from my iPhone On 30 Jun 2015, at 09:42, Felix Bembrick felix.bembr...@gmail.com wrote: coughJavaFX has *never* claimed to be write once, run anyway/cough On 30 Jun 2015, at 18:13, Mike mikeg...@gmail.com wrote: coughwrite once, run anywhere/cough This about sums it up! On Tue, Jun 30, 2015 at 12:12 AM, Jack Moxley j...@moxley.co.uk wrote: coughwrite once, run anywhere/cough Sent from my iPhone On 29 Jun 2015, at 21:45, Michał Zegan webczat_...@poczta.onet.pl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Does it mean platform support for linux won't be implemented now, or at all? I usually use windows, but still depend on that support because I sometimes use linux, so I am interested about that. W dniu 2015-06-29 o 22:40, Kevin Rushforth pisze: There is public API in 8u40 to support accessibility. Applications using standard JavaFX controls can, for example, use the accessibleText property to define the text that the screen reader will speak or the accessibleHelp property to provide a more detailed description. These properties have reasonable defaults, but can be overridden by applications. Additionally, if you use the labelFor property to point to a Control that the Label is associated with, the accessibility framework will use that when the screen reader is active. Custom controls can override the queryAccessibleAttribute, executeAccessibleAction, and notifyAccessibleAttributeChanged methods. As for platform support, we currently support Windows and Mac platforms. We have no plan to make FX accessible on Linux . -- Kevin Michał Zegan wrote: I saw it, and it seems promising, but: first, there is probably, or I heard it wrong? no public api for making accessibility related stuff... Also, I believe there is no linux accessibility bridge as opposed to windows and mac. And I do not know if I am wrong, or when this is going to be implemented. W dniu 2015-06-29 o 20:30, Kevin Rushforth pisze: JavaFX accessibility is already implemented and was delivered in JDK 8u40. -- Kevin Michał Zegan wrote: What about accessibility work? Work on it has been started, but not sure if it is still targetted for 9. W dniu 2015-06-27 o 20:16, Mike pisze: a lot of FULL blown Webrtc support and building something in Javafx (like Scene Builder) that Proves Webrtc support would be awesome. Ditto to Webgl support. On Sat, Jun 27, 2015 at 8:07 AM, Kevin Rushforth kevin.rushfo...@oracle.com wrote: Hi Felix, Sorry for the delay. Most of us were still pretty focused on 8u60, but we are turning our attention to JDK 9 now. The focus for JDK 9 is Jigsaw. The currently planned big features (JEPs) for FX in JDK 9 are these: JEP 253: Prepare JavaFX UI Controls CSS APIs for Modularization JEP 257: Update JavaFX/Media to Newer Version of GStreamer Related to Jigasw, we intend to look into new API for heavily used internal methods / classes since they will no longer be accessible otherwise. We also plan to update WebKit at least one more time, and will likely do a few RFEs such as better Hi-DPI support (with API control) on Mac, Windows, Linux. We don't currently plan any other big features for 9, but will consider additional RFEs if they are important to enough developers and if they fit into the time frame. -- Kevin Felix Bembrick wrote: Anyone got anything or is there a link somewhere that talks about these? On 15 June 2015 at 22:00, Felix Bembrick felix.bembr...@gmail.com wrote: I realise we are a long way off JDK 9 still and with crucial features such as Jigsaw still a little up in the air but is it possible someone could itemise the most likely new features, enhancements and bug fixes that we will see in JavaFX when JDK 9 is released? Of course it's purely speculation at this point but it would assist me greatly to have some of idea of where JavaFX is heading and which areas are seen as most important. Thanks, Felix -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJVka5MAAoJEHb1CzgxXKwYbKwP/RFa3NjMnXWFc6o5EzIFYlh3 5ExLUgu+IVWr1fewrf+KTcR9WmyXWN2ju8zkRb7nhjSiA+5XAf3vbvUBGTaaa1A4 92Fd0W2Mfj8M9F3Px5QP1TMS1BO7GrO12zsB+obmBvWA/xWy0GEoctja8ohT5aNf hs7foi4pZRK6abMvxd94WdSNh/KhzqNvllD3tIkqlasTOOH1i7bEreQ9sxN6+DRF JB87JSRuml7rYEgsOSx5Z2EE7YdgqYjdfHSAIwBvqkRDQZuOp8RrWzU6wFyyzhlm RtuAQJWj1I2DNbZE9iCNJzYqajnp0OellbxGr9SrJaVPpqNjjbw6zoGZ3bhgCAow BAZUlllG9UVoKcl1bHDvmB01RG2JP7RtBByS0cbqGQM0/YqtknbNWpl2r5kTVyH1 EZnfkXmXYi/lqgyRBf1/WqlJnuT10ra7oAQytUajZ3cQJNbRwuFycV0yvbGo11xS eaQO2ECgYyubLE8vsnw1L+2U4wLAMXY9Q3Ob1kLq12UEYB8WMoLZ+IAixUUJ6abB reI+epG/Bh27R0fHChkHEgY65TIMRt8RtOXxzs+Nf0VVAC4Lj9378Y8ZEr14RbcZ mO+5TvyqfDhyIP4WevGDF2/tQTvlsAzl7UuiTtD3pWZ+CpN2WeNimBHPN2ZI6lii
Re: JavaFX features in JDK 9
That should of read 'set its aspirations higher' Sent from my iPhone On 30 Jun 2015, at 12:13, Jack Moxley j...@moxley.co.uk wrote: Maybe it should its aspirations a little higher, especially with the advent of unity, webgl or even scenegraph impls such as jmonkeyengine that do. Sent from my iPhone On 30 Jun 2015, at 09:42, Felix Bembrick felix.bembr...@gmail.com wrote: coughJavaFX has *never* claimed to be write once, run anyway/cough On 30 Jun 2015, at 18:13, Mike mikeg...@gmail.com wrote: coughwrite once, run anywhere/cough This about sums it up! On Tue, Jun 30, 2015 at 12:12 AM, Jack Moxley j...@moxley.co.uk wrote: coughwrite once, run anywhere/cough Sent from my iPhone On 29 Jun 2015, at 21:45, Michał Zegan webczat_...@poczta.onet.pl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Does it mean platform support for linux won't be implemented now, or at all? I usually use windows, but still depend on that support because I sometimes use linux, so I am interested about that. W dniu 2015-06-29 o 22:40, Kevin Rushforth pisze: There is public API in 8u40 to support accessibility. Applications using standard JavaFX controls can, for example, use the accessibleText property to define the text that the screen reader will speak or the accessibleHelp property to provide a more detailed description. These properties have reasonable defaults, but can be overridden by applications. Additionally, if you use the labelFor property to point to a Control that the Label is associated with, the accessibility framework will use that when the screen reader is active. Custom controls can override the queryAccessibleAttribute, executeAccessibleAction, and notifyAccessibleAttributeChanged methods. As for platform support, we currently support Windows and Mac platforms. We have no plan to make FX accessible on Linux . -- Kevin Michał Zegan wrote: I saw it, and it seems promising, but: first, there is probably, or I heard it wrong? no public api for making accessibility related stuff... Also, I believe there is no linux accessibility bridge as opposed to windows and mac. And I do not know if I am wrong, or when this is going to be implemented. W dniu 2015-06-29 o 20:30, Kevin Rushforth pisze: JavaFX accessibility is already implemented and was delivered in JDK 8u40. -- Kevin Michał Zegan wrote: What about accessibility work? Work on it has been started, but not sure if it is still targetted for 9. W dniu 2015-06-27 o 20:16, Mike pisze: a lot of FULL blown Webrtc support and building something in Javafx (like Scene Builder) that Proves Webrtc support would be awesome. Ditto to Webgl support. On Sat, Jun 27, 2015 at 8:07 AM, Kevin Rushforth kevin.rushfo...@oracle.com wrote: Hi Felix, Sorry for the delay. Most of us were still pretty focused on 8u60, but we are turning our attention to JDK 9 now. The focus for JDK 9 is Jigsaw. The currently planned big features (JEPs) for FX in JDK 9 are these: JEP 253: Prepare JavaFX UI Controls CSS APIs for Modularization JEP 257: Update JavaFX/Media to Newer Version of GStreamer Related to Jigasw, we intend to look into new API for heavily used internal methods / classes since they will no longer be accessible otherwise. We also plan to update WebKit at least one more time, and will likely do a few RFEs such as better Hi-DPI support (with API control) on Mac, Windows, Linux. We don't currently plan any other big features for 9, but will consider additional RFEs if they are important to enough developers and if they fit into the time frame. -- Kevin Felix Bembrick wrote: Anyone got anything or is there a link somewhere that talks about these? On 15 June 2015 at 22:00, Felix Bembrick felix.bembr...@gmail.com wrote: I realise we are a long way off JDK 9 still and with crucial features such as Jigsaw still a little up in the air but is it possible someone could itemise the most likely new features, enhancements and bug fixes that we will see in JavaFX when JDK 9 is released? Of course it's purely speculation at this point but it would assist me greatly to have some of idea of where JavaFX is heading and which areas are seen as most important. Thanks, Felix -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJVka5MAAoJEHb1CzgxXKwYbKwP/RFa3NjMnXWFc6o5EzIFYlh3 5ExLUgu+IVWr1fewrf+KTcR9WmyXWN2ju8zkRb7nhjSiA+5XAf3vbvUBGTaaa1A4 92Fd0W2Mfj8M9F3Px5QP1TMS1BO7GrO12zsB+obmBvWA/xWy0GEoctja8ohT5aNf hs7foi4pZRK6abMvxd94WdSNh/KhzqNvllD3tIkqlasTOOH1i7bEreQ9sxN6+DRF JB87JSRuml7rYEgsOSx5Z2EE7YdgqYjdfHSAIwBvqkRDQZuOp8RrWzU6wFyyzhlm RtuAQJWj1I2DNbZE9iCNJzYqajnp0OellbxGr9SrJaVPpqNjjbw6zoGZ3bhgCAow BAZUlllG9UVoKcl1bHDvmB01RG2JP7RtBByS0cbqGQM0/YqtknbNWpl2r5kTVyH1 EZnfkXmXYi/lqgyRBf1/WqlJnuT10ra7oAQytUajZ3cQJNbRwuFycV0yvbGo11xS eaQO2ECgYyubLE8vsnw1L+2U4wLAMXY9Q3Ob1kLq12UEYB8WMoLZ+IAixUUJ6abB
Re: JavaFX features in JDK 9
I suppose i should stop shouting from the sidelines, roll up my sleeves and get my hands dirty, what can i do as a lowly developer to help? Sent from my iPhone On 30 Jun 2015, at 12:16, Felix Bembrick felix.bembr...@gmail.com wrote: Well, we are all at the whim of Oracle executives decisions with the added help of third parties such as Gluon and RoboVM. The future of JavaFX really is in *our* hands. On 30 Jun 2015, at 21:13, Jack Moxley j...@moxley.co.uk wrote: Maybe it should its aspirations a little higher, especially with the advent of unity, webgl or even scenegraph impls such as jmonkeyengine that do. Sent from my iPhone On 30 Jun 2015, at 09:42, Felix Bembrick felix.bembr...@gmail.com wrote: coughJavaFX has *never* claimed to be write once, run anyway/cough On 30 Jun 2015, at 18:13, Mike mikeg...@gmail.com wrote: coughwrite once, run anywhere/cough This about sums it up! On Tue, Jun 30, 2015 at 12:12 AM, Jack Moxley j...@moxley.co.uk wrote: coughwrite once, run anywhere/cough Sent from my iPhone On 29 Jun 2015, at 21:45, Michał Zegan webczat_...@poczta.onet.pl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Does it mean platform support for linux won't be implemented now, or at all? I usually use windows, but still depend on that support because I sometimes use linux, so I am interested about that. W dniu 2015-06-29 o 22:40, Kevin Rushforth pisze: There is public API in 8u40 to support accessibility. Applications using standard JavaFX controls can, for example, use the accessibleText property to define the text that the screen reader will speak or the accessibleHelp property to provide a more detailed description. These properties have reasonable defaults, but can be overridden by applications. Additionally, if you use the labelFor property to point to a Control that the Label is associated with, the accessibility framework will use that when the screen reader is active. Custom controls can override the queryAccessibleAttribute, executeAccessibleAction, and notifyAccessibleAttributeChanged methods. As for platform support, we currently support Windows and Mac platforms. We have no plan to make FX accessible on Linux . -- Kevin Michał Zegan wrote: I saw it, and it seems promising, but: first, there is probably, or I heard it wrong? no public api for making accessibility related stuff... Also, I believe there is no linux accessibility bridge as opposed to windows and mac. And I do not know if I am wrong, or when this is going to be implemented. W dniu 2015-06-29 o 20:30, Kevin Rushforth pisze: JavaFX accessibility is already implemented and was delivered in JDK 8u40. -- Kevin Michał Zegan wrote: What about accessibility work? Work on it has been started, but not sure if it is still targetted for 9. W dniu 2015-06-27 o 20:16, Mike pisze: a lot of FULL blown Webrtc support and building something in Javafx (like Scene Builder) that Proves Webrtc support would be awesome. Ditto to Webgl support. On Sat, Jun 27, 2015 at 8:07 AM, Kevin Rushforth kevin.rushfo...@oracle.com wrote: Hi Felix, Sorry for the delay. Most of us were still pretty focused on 8u60, but we are turning our attention to JDK 9 now. The focus for JDK 9 is Jigsaw. The currently planned big features (JEPs) for FX in JDK 9 are these: JEP 253: Prepare JavaFX UI Controls CSS APIs for Modularization JEP 257: Update JavaFX/Media to Newer Version of GStreamer Related to Jigasw, we intend to look into new API for heavily used internal methods / classes since they will no longer be accessible otherwise. We also plan to update WebKit at least one more time, and will likely do a few RFEs such as better Hi-DPI support (with API control) on Mac, Windows, Linux. We don't currently plan any other big features for 9, but will consider additional RFEs if they are important to enough developers and if they fit into the time frame. -- Kevin Felix Bembrick wrote: Anyone got anything or is there a link somewhere that talks about these? On 15 June 2015 at 22:00, Felix Bembrick felix.bembr...@gmail.com wrote: I realise we are a long way off JDK 9 still and with crucial features such as Jigsaw still a little up in the air but is it possible someone could itemise the most likely new features, enhancements and bug fixes that we will see in JavaFX when JDK 9 is released? Of course it's purely speculation at this point but it would assist me greatly to have some of idea of where JavaFX is heading and which areas are seen as most important. Thanks, Felix -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJVka5MAAoJEHb1CzgxXKwYbKwP/RFa3NjMnXWFc6o5EzIFYlh3 5ExLUgu+IVWr1fewrf+KTcR9WmyXWN2ju8zkRb7nhjSiA+5XAf3vbvUBGTaaa1A4 92Fd0W2Mfj8M9F3Px5QP1TMS1BO7GrO12zsB+obmBvWA/xWy0GEoctja8ohT5aNf hs7foi4pZRK6abMvxd94WdSNh
Camera look at in 3d
One of the things sorely missed is a simple way of getting the camera to rotate so it looks at a specified point in 3d space. I am racking my head trying to work out how to do this, does anyone have any ideas/pointers in how to achieve this? Any help much appreciated. Kind regards, Jack
Re: Glass Robot and getSCreenCapture
It should be throwing an exception or returning null, returning a real value is a code smell. Sent from my iPhone On 23 Mar 2014, at 07:55, Daniel Blaukopf daniel.blauk...@oracle.com wrote: We should be consistent about what we return, although I agree that that the actual value doesn’t seem to matter. 0 for imaginary pixels seems reasonable. On Mar 21, 2014, at 7:05 PM, Anthony Petrov anthony.pet...@oracle.com wrote: Hi David, I don't think we're making any assumptions. We feed the coordinates to a native API and rely on the OS to do the right thing. In other words, our assumption is that if the box lays (partially or fully) outside of the screen area, then the behavior is undefined. Note that the Screen API in Glass allows its clients to check what coordinates are valid (i.e. belong to a real screen). So whatever your return for pixels outside of screen bounds should be fine. 0x0 or 0xff00 - both look good. However, I agree that a stricter specification and a check might be the best solution. -- best regards, Anthony On 3/21/2014 8:53 PM, David Hill wrote: I have been working on a problem with Robot.getScreenCapture() on a 565 ARM device, and while doing so, encountered a couple of questions which I will bring up: Pixxls getScreenCapture(int x, int y, int width, int height, boolean isHiDPI) I don't seem any real documentation that says how x,y + width,height should be treated when compared to the reality of the Screen. What values of x,y + width,height are reasonable ? I can picture any number of scenarios with them that would result in a box that does not fit within the Screen dimensions. The only implementing code I have seen checks to that the width height are = 1. Can I/Should I handle -x values ? What if the requested bounds exceed the screen ? If we are making assumptions that the requested box is inside the screen then why don't we document that fact and add a check in the Robot class (instead of relying on the native impls). If we are assuming the requested box does not have to lie within the screen bounds - what should the returned values be for the pixels outside the screen ? Pixel Black ? (Currently I think Lens would return 0x instead of 0xff00) My recommendation would be modify the JavaDoc contract to specify that the x,y and x+width, y+height must be within the screen bounds, with an IllegalArgumentException if out of bounds. This would be checked in Robot, prior to calling the native impls. This code is internal API, so I expect the real impact would be on SQE.
RE: Constructor annotation
I would prefer @FXMLConstructor and for the names of the parameters to be
automagicaly detected and linked, and then an optional @FXMLArgument to allow
us to specify if the actual name deviates from the name of the parameter.
I understand this can be an issue, as parameter names are not retained, but
we can fetch either from the debugging symbols, or at compile time. _
From: Claus Luethje [mailto:claus.luet...@osys.ch]
To: Eva Krejcirova [mailto:eva.krejcir...@oracle.com],
openjfx-dev@openjdk.java.net [mailto:openjfx-dev@openjdk.java.net]
Sent: Wed, 16 Oct 2013 11:26:12 +
Subject: RE: Constructor annotation
Hi
I'd prefer the second option, because the correlation of the order of
arguments in the annotation and in the constructors parameters is irritating
and error prone.
The way it is structured in option two is seen elsewhere also. So, nothing
new to learn/absorb.
@FXMLArgument is a useful name to describe what's going on.
My 2 cents...
Regards
Claus
-Original Message-
From: openjfx-dev-boun...@openjdk.java.net
[mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Eva Krejcirova
Sent: Mittwoch, 16. Oktober 2013 11:22
To: openjfx-dev@openjdk.java.net
Subject: Constructor annotation
Hi All,
when we retired builders, we caused a problem for FXML which doesn't have a
way to create classes without default constructors. Back then we decided to use
an annotation for this but never actually got to implement it and we need to
fix this for FX8. I am in the process of adding this functionality to
FXMLLoader but we need to decide how the annotation will look like and I could
use some help with this.
We cannot use already existing ConstructorProperties for this, because it's
java.beans package and we don't want to create to dependency on this package in
JavaFX, so we need to introduce a new annotation.
We have two options:
1. Annotate the whole constructor:
e.g.
@ConstructorArguments({a, b, list})
public ImmutableClass(int a, int b, Integer... list)
2. Annotate the arguments:
e.g.
public ImmutableClass(@FXMLArgument(a) int a, @FXMLArgument(b)int b,
@FXMLArgument(list)Integer... list)
Which option do you like more and how should the annotation be named?
Thanks,
Eva
