From poweruserm at live.com.au Mon Oct 1 08:33:42 2018 From: poweruserm at live.com.au (A Z) Date: Mon, 1 Oct 2018 08:33:42 +0000 Subject: Question about Java 12. Message-ID: -It is my understanding that this is not a technical or dev email list, at least so far. Is it possible that JEP 306 https://bugs.openjdk.java.net/browse/JDK-8175916 , or similar, such as JEP 306 but with an alternate mode, either for variables AND objects, or to the compiler or VM, is a target possibility for Java 12? From dalibor.topic at oracle.com Mon Oct 1 09:08:17 2018 From: dalibor.topic at oracle.com (dalibor topic) Date: Mon, 1 Oct 2018 11:08:17 +0200 Subject: Question about Java 12. In-Reply-To: References: Message-ID: <5cd4f637-d539-f0fc-bb22-ea8be5aea669@oracle.com> Hi, JEP 306 is in Candidate status. It hasn't been proposed to be targeted for any particular JDK release yet. cheers, dalibor topic On 01.10.2018 10:33, A Z wrote: > -It is my understanding that this is not a technical > or dev email list, at least so far. > > Is it possible that JEP 306 > > https://bugs.openjdk.java.net/browse/JDK-8175916 > > , or similar, such as JEP 306 but with an alternate mode, > either for variables AND objects, or to the compiler or VM, > is a target possibility for Java 12? > -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From peterhull90 at gmail.com Tue Oct 9 09:00:03 2018 From: peterhull90 at gmail.com (Peter Hull) Date: Tue, 9 Oct 2018 10:00:03 +0100 Subject: Graphics2D.drawPolyline performance on JDK 8 vs. JDK 11 (repost) In-Reply-To: References: Message-ID: I've recently started using Java 11 and noticed that drawPolyline is much slower on my PC than it was on Java 8. Example, simplified code: @Override protected void paintComponent(Graphics g) { super.paintComponent(g); Graphics2D graphics = (Graphics2D) g; long starttime = System.nanoTime(); graphics.drawPolyline(xs, ys, xs.length); long endtime = System.nanoTime(); Logger.getLogger(this.getClass().getName()).log(Level.INFO, "Paint Time: {0}s", (double)(endtime-starttime) / 1.0e9); } where xs[] and ys[] are large (65536 points) integer arrays. On OpenJDK8_x64_Win_jdk8u172-b11 I get a paint time of 0.025s and on openjdk-11+28_windows-x64 it is 25s, i.e. factor of 1000. This may be related to JEP263 (HiDPI) I've got a recent Core i7 processor with Intel graphics, running Windows 10. Is this a bug do you think and if so, where to report it? Thanks, Peter From dalibor.topic at oracle.com Tue Oct 9 10:10:17 2018 From: dalibor.topic at oracle.com (dalibor topic) Date: Tue, 9 Oct 2018 12:10:17 +0200 Subject: Graphics2D.drawPolyline performance on JDK 8 vs. JDK 11 (repost) In-Reply-To: References: Message-ID: <05b8f337-efb2-1a96-11ea-3dfc2ef6a9a0@oracle.com> On 09.10.2018 11:00, Peter Hull wrote: > I've recently started using Java 11 and noticed that drawPolyline is > much slower on my PC than it was on Java 8. > Example, simplified code: > @Override > protected void paintComponent(Graphics g) { > super.paintComponent(g); > Graphics2D graphics = (Graphics2D) g; > long starttime = System.nanoTime(); > graphics.drawPolyline(xs, ys, xs.length); > long endtime = System.nanoTime(); > Logger.getLogger(this.getClass().getName()).log(Level.INFO, > "Paint Time: {0}s", (double)(endtime-starttime) / 1.0e9); > } > where xs[] and ys[] are large (65536 points) integer arrays. On > OpenJDK8_x64_Win_jdk8u172-b11 I get a paint time of 0.025s and on > openjdk-11+28_windows-x64 it is 25s, i.e. factor of 1000. > This may be related to JEP263 (HiDPI) > > I've got a recent Core i7 processor with Intel graphics, running Windows 10. > > Is this a bug do you think and if so, where to report it? Hi, please file an issue on bugs.java.com. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From kevin.rushforth at oracle.com Tue Oct 9 11:09:52 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 9 Oct 2018 04:09:52 -0700 Subject: Graphics2D.drawPolyline performance on JDK 8 vs. JDK 11 (repost) In-Reply-To: References: Message-ID: I suggest posting this on the 2d-dev at openjdk.java.net mailing list. -- Kevin On 10/9/2018 2:00 AM, Peter Hull wrote: > I've recently started using Java 11 and noticed that drawPolyline is > much slower on my PC than it was on Java 8. > Example, simplified code: > @Override > protected void paintComponent(Graphics g) { > super.paintComponent(g); > Graphics2D graphics = (Graphics2D) g; > long starttime = System.nanoTime(); > graphics.drawPolyline(xs, ys, xs.length); > long endtime = System.nanoTime(); > Logger.getLogger(this.getClass().getName()).log(Level.INFO, > "Paint Time: {0}s", (double)(endtime-starttime) / 1.0e9); > } > where xs[] and ys[] are large (65536 points) integer arrays. On > OpenJDK8_x64_Win_jdk8u172-b11 I get a paint time of 0.025s and on > openjdk-11+28_windows-x64 it is 25s, i.e. factor of 1000. > This may be related to JEP263 (HiDPI) > > I've got a recent Core i7 processor with Intel graphics, running Windows 10. > > Is this a bug do you think and if so, where to report it? > > Thanks, > Peter From peterhull90 at gmail.com Tue Oct 9 11:11:51 2018 From: peterhull90 at gmail.com (Peter Hull) Date: Tue, 9 Oct 2018 12:11:51 +0100 Subject: Graphics2D.drawPolyline performance on JDK 8 vs. JDK 11 (repost) In-Reply-To: References: Message-ID: Thanks Kevin and Dalibor. I've filed a Java bug (first time for everything!) and will post to 2d-dev also. Pete On Tue, 9 Oct 2018 at 12:09 Kevin Rushforth wrote: > I suggest posting this on the 2d-dev at openjdk.java.net mailing list. > > -- Kevin > > On 10/9/2018 2:00 AM, Peter Hull wrote: > > I've recently started using Java 11 and noticed that drawPolyline is > > much slower on my PC than it was on Java 8. > > Example, simplified code: > > @Override > > protected void paintComponent(Graphics g) { > > super.paintComponent(g); > > Graphics2D graphics = (Graphics2D) g; > > long starttime = System.nanoTime(); > > graphics.drawPolyline(xs, ys, xs.length); > > long endtime = System.nanoTime(); > > Logger.getLogger(this.getClass().getName()).log(Level.INFO, > > "Paint Time: {0}s", (double)(endtime-starttime) / 1.0e9); > > } > > where xs[] and ys[] are large (65536 points) integer arrays. On > > OpenJDK8_x64_Win_jdk8u172-b11 I get a paint time of 0.025s and on > > openjdk-11+28_windows-x64 it is 25s, i.e. factor of 1000. > > This may be related to JEP263 (HiDPI) > > > > I've got a recent Core i7 processor with Intel graphics, running Windows > 10. > > > > Is this a bug do you think and if so, where to report it? > > > > Thanks, > > Peter > > From poweruserm at live.com.au Wed Oct 10 01:28:56 2018 From: poweruserm at live.com.au (A Z) Date: Wed, 10 Oct 2018 01:28:56 +0000 Subject: Question about Java 12. In-Reply-To: References: Message-ID: -It is my understanding that this is not a technical or dev email list, at least so far. Is it possible that JEP 306 https://bugs.openjdk.java.net/browse/JDK-8175916 , or similar, such as JEP 306 but with an alternate mode, either for variables AND objects, or to the compiler or VM, is a target possibility for Java 12? From dalibor.topic at oracle.com Thu Oct 11 12:05:59 2018 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 11 Oct 2018 14:05:59 +0200 Subject: Question about Java 12. In-Reply-To: References: Message-ID: On 10.10.2018 03:28, A Z wrote: > -It is my understanding that this is not a technical > or dev email list, at least so far. > > Is it possible that JEP 306 > > https://bugs.openjdk.java.net/browse/JDK-8175916 > > , or similar, such as JEP 306 but with an alternate mode, > either for variables AND objects, or to the compiler or VM, > is a target possibility for Java 12? Not at this time, since it hasn't been proposed to be targeted yet. Per http://openjdk.java.net/projects/jdk/12/ such a proposal would need to successfully happen in the next two months in case of Java 12. Fwiw, there is no indication at this time that anyone is proposing to target this JEP for any specific release yet. Sending an email every couple of days to ask about it is just wasting everyone's time. Please stop contributing negatively. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From arjan.tijms at gmail.com Thu Oct 11 13:18:54 2018 From: arjan.tijms at gmail.com (arjan tijms) Date: Thu, 11 Oct 2018 14:18:54 +0100 Subject: More precise annotation targets Message-ID: Hi, I wonder if the following would make sense to consider for a Java language enhancement: Annotations can currently be targeted to TYPE, FIELD, METHOD, TYPE_PARAMETER etc. For lots of cases this is fine, but in other case you need a bit more detail. For instance, consider an @ActionEvent annotation that targets METHOD, but actually can only be applied on methods with a specific signature such as void method(Action); and void method(); You might want to have correct placement of the annotation expressed in a little more exact way, like e.g. @Target(METHOD) @TargetMethods( {ActionInterface.class, ActionInterface2.class}) @Retention(RUNTIME) public @interface ActionEvent {} With ActionInterface.class and ActionInterface2.class both functional classes. Alternatively: @Target(METHOD) @TargetMethods( { @MethodSignature( return=Void.class, arguments=Action.class), @MethodSignature( return=Void.class)} } @Retention(RUNTIME) public @interface ActionEvent {} The syntax used is just illustrative of the idea. Thoughts? Kind regards, Arjan From brian.goetz at oracle.com Thu Oct 11 13:27:47 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 11 Oct 2018 09:27:47 -0400 Subject: More precise annotation targets In-Reply-To: References: Message-ID: <41def6de-d583-ff70-0776-be3f23099bb5@oracle.com> You can accomplish this today with an annotation processor. Make your own @TargetMethods meta-annotations, and then have an AP that enforces that the constraints of the meta-annotations are respected.? You don't need a language change. On 10/11/2018 9:18 AM, arjan tijms wrote: > Hi, > > I wonder if the following would make sense to consider for a Java language > enhancement: > > Annotations can currently be targeted > to TYPE, FIELD, METHOD, TYPE_PARAMETER etc. > > For lots of cases this is fine, but in other case you need a bit more > detail. For instance, consider an @ActionEvent annotation that targets > METHOD, but actually can only be applied on methods with a specific > signature such as void method(Action); and void method(); > > You might want to have correct placement of the annotation expressed in a > little more exact way, like e.g. > > @Target(METHOD) > @TargetMethods( {ActionInterface.class, ActionInterface2.class}) > @Retention(RUNTIME) > public @interface ActionEvent {} > > > With ActionInterface.class and ActionInterface2.class both functional > classes. > > Alternatively: > > @Target(METHOD) > @TargetMethods( { > @MethodSignature( > return=Void.class, arguments=Action.class), > @MethodSignature( > return=Void.class)} > } > @Retention(RUNTIME) > public @interface ActionEvent {} > > The syntax used is just illustrative of the idea. > > Thoughts? > > Kind regards, > Arjan From arjan.tijms at gmail.com Thu Oct 11 13:40:39 2018 From: arjan.tijms at gmail.com (arjan tijms) Date: Thu, 11 Oct 2018 14:40:39 +0100 Subject: More precise annotation targets In-Reply-To: <41def6de-d583-ff70-0776-be3f23099bb5@oracle.com> References: <41def6de-d583-ff70-0776-be3f23099bb5@oracle.com> Message-ID: Hi Brian, You're right. It can be done today that way. Do you think though it would be an option to consider for a language change, given that when being a language feature it would have much better support from IDEs and other tools? Kind regards, Arjan Tijms On Thu, Oct 11, 2018 at 2:27 PM Brian Goetz wrote: > You can accomplish this today with an annotation processor. Make your > own @TargetMethods meta-annotations, and then have an AP that enforces > that the constraints of the meta-annotations are respected. You don't > need a language change. > > > > > > On 10/11/2018 9:18 AM, arjan tijms wrote: > > Hi, > > > > I wonder if the following would make sense to consider for a Java > language > > enhancement: > > > > Annotations can currently be targeted > > to TYPE, FIELD, METHOD, TYPE_PARAMETER etc. > > > > For lots of cases this is fine, but in other case you need a bit more > > detail. For instance, consider an @ActionEvent annotation that targets > > METHOD, but actually can only be applied on methods with a specific > > signature such as void method(Action); and void method(); > > > > You might want to have correct placement of the annotation expressed in a > > little more exact way, like e.g. > > > > @Target(METHOD) > > @TargetMethods( {ActionInterface.class, ActionInterface2.class}) > > @Retention(RUNTIME) > > public @interface ActionEvent {} > > > > > > With ActionInterface.class and ActionInterface2.class both functional > > classes. > > > > Alternatively: > > > > @Target(METHOD) > > @TargetMethods( { > > @MethodSignature( > > return=Void.class, arguments=Action.class), > > @MethodSignature( > > return=Void.class)} > > } > > @Retention(RUNTIME) > > public @interface ActionEvent {} > > > > The syntax used is just illustrative of the idea. > > > > Thoughts? > > > > Kind regards, > > Arjan > > From brian.goetz at oracle.com Thu Oct 11 16:01:15 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 11 Oct 2018 12:01:15 -0400 Subject: More precise annotation targets In-Reply-To: References: <41def6de-d583-ff70-0776-be3f23099bb5@oracle.com> Message-ID: <780acbd2-1a35-2c37-14bb-9210d291a962@oracle.com> No.? This is quite rightly the domain of extralinguistic tools, not the language. Think about it this way: this feature would be interesting to very few people, and it would affect those few people in only a small way.? The bar is just way higher than that. This is a project-specific concern, not a world-wide concern. On 10/11/2018 9:40 AM, arjan tijms wrote: > Hi Brian, > > You're right. It can be done today that way. > > Do you think though it would be an option to consider for a language > change, given that when being a language feature it would have much > better support from IDEs and other tools? > > Kind?regards, > Arjan Tijms > > > > > > On Thu, Oct 11, 2018 at 2:27 PM Brian Goetz > wrote: > > You can accomplish this today with an annotation processor. Make your > own @TargetMethods meta-annotations, and then have an AP that > enforces > that the constraints of the meta-annotations are respected. You don't > need a language change. > > > > > > On 10/11/2018 9:18 AM, arjan tijms wrote: > > Hi, > > > > I wonder if the following would make sense to consider for a > Java language > > enhancement: > > > > Annotations can currently be targeted > > to TYPE, FIELD, METHOD, TYPE_PARAMETER etc. > > > > For lots of cases this is fine, but in other case you need a bit > more > > detail. For instance, consider an @ActionEvent annotation that > targets > > METHOD, but actually can only be applied on methods with a specific > > signature such as void method(Action); and void method(); > > > > You might want to have correct placement of the annotation > expressed in a > > little more exact way, like e.g. > > > > @Target(METHOD) > > @TargetMethods( {ActionInterface.class, ActionInterface2.class}) > > @Retention(RUNTIME) > > public @interface ActionEvent {} > > > > > > With ActionInterface.class and ActionInterface2.class both > functional > > classes. > > > > Alternatively: > > > > @Target(METHOD) > > @TargetMethods( { > >? ? ? @MethodSignature( > >? ? ? ? ? return=Void.class, arguments=Action.class), > >? ? ? ?@MethodSignature( > >? ? ? ? ? return=Void.class)} > > } > > @Retention(RUNTIME) > > public @interface ActionEvent {} > > > > The syntax used is just illustrative of the idea. > > > > Thoughts? > > > > Kind regards, > > Arjan > From Ryan.LaMothe at pnnl.gov Thu Oct 11 20:32:32 2018 From: Ryan.LaMothe at pnnl.gov (LaMothe, Ryan R) Date: Thu, 11 Oct 2018 20:32:32 +0000 Subject: More precise annotation targets In-Reply-To: References: Message-ID: While I agree with Brian's comments later in this thread on the below question, I'd like to expand on the question just a little: We've always wished we could annotate for loops, while loops, etc. so that we can handle them with custom back-end code/processing (e.g. parallelism, GPU, cluster queue, etc.). Has that already been attempted/proposed or is that something we would need to propose new? ____________________________________________ Ryan LaMothe? -----Original Message----- From: discuss [mailto:discuss-bounces at openjdk.java.net] On Behalf Of arjan tijms Sent: Thursday, October 11, 2018 6:19 AM To: discuss Subject: More precise annotation targets Hi, I wonder if the following would make sense to consider for a Java language enhancement: Annotations can currently be targeted to TYPE, FIELD, METHOD, TYPE_PARAMETER etc. For lots of cases this is fine, but in other case you need a bit more detail. For instance, consider an @ActionEvent annotation that targets METHOD, but actually can only be applied on methods with a specific signature such as void method(Action); and void method(); You might want to have correct placement of the annotation expressed in a little more exact way, like e.g. @Target(METHOD) @TargetMethods( {ActionInterface.class, ActionInterface2.class}) @Retention(RUNTIME) public @interface ActionEvent {} With ActionInterface.class and ActionInterface2.class both functional classes. Alternatively: @Target(METHOD) @TargetMethods( { @MethodSignature( return=Void.class, arguments=Action.class), @MethodSignature( return=Void.class)} } @Retention(RUNTIME) public @interface ActionEvent {} The syntax used is just illustrative of the idea. Thoughts? Kind regards, Arjan From brian.goetz at oracle.com Thu Oct 11 21:00:19 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 11 Oct 2018 17:00:19 -0400 Subject: More precise annotation targets In-Reply-To: References: Message-ID: That's a completely separate feature from what Arjan was proposing. Annotations on statements is something that was considered in the original design of annotations, but if you think about it for a bit, you'll see where it runs off the road.? Where most of the pain in this is: how on earth would you _find_ these annotations at run time?? Reflection only goes down to the member level.? So tied to this idea, is a significant upgrade to the classfile format (the VM has no concept of "for loop", so these language-level concepts would need to be described more directly in the class file, and then we'd need ways to describe annotations on each of them), and then a significant upgrade to reflection (being able to reflect over the structure of the bytecode).? And then a way to get your hands on the actual bytecode, so that you can spin new bytecode / generate native code for your parallel loops. On 10/11/2018 4:32 PM, LaMothe, Ryan R wrote: > While I agree with Brian's comments later in this thread on the below question, I'd like to expand on the question just a little: We've always wished we could annotate for loops, while loops, etc. so that we can handle them with custom back-end code/processing (e.g. parallelism, GPU, cluster queue, etc.). Has that already been attempted/proposed or is that something we would need to propose new? > > ____________________________________________ > Ryan LaMothe > > -----Original Message----- > From: discuss [mailto:discuss-bounces at openjdk.java.net] On Behalf Of arjan tijms > Sent: Thursday, October 11, 2018 6:19 AM > To: discuss > Subject: More precise annotation targets > > Hi, > > I wonder if the following would make sense to consider for a Java language > enhancement: > > Annotations can currently be targeted > to TYPE, FIELD, METHOD, TYPE_PARAMETER etc. > > For lots of cases this is fine, but in other case you need a bit more detail. For instance, consider an @ActionEvent annotation that targets METHOD, but actually can only be applied on methods with a specific signature such as void method(Action); and void method(); > > You might want to have correct placement of the annotation expressed in a little more exact way, like e.g. > > @Target(METHOD) > @TargetMethods( {ActionInterface.class, ActionInterface2.class}) > @Retention(RUNTIME) > public @interface ActionEvent {} > > > With ActionInterface.class and ActionInterface2.class both functional classes. > > Alternatively: > > @Target(METHOD) > @TargetMethods( { > @MethodSignature( > return=Void.class, arguments=Action.class), > @MethodSignature( > return=Void.class)} > } > @Retention(RUNTIME) > public @interface ActionEvent {} > > The syntax used is just illustrative of the idea. > > Thoughts? > > Kind regards, > Arjan From peter.lawrey at gmail.com Tue Oct 16 08:21:35 2018 From: peter.lawrey at gmail.com (Peter Lawrey) Date: Tue, 16 Oct 2018 09:21:35 +0100 Subject: More precise annotation targets In-Reply-To: References: Message-ID: Sometimes for clarity or performance or profiling reasons, I put each key loop in its own private method with a descriptive name. You could then add an annotation to this method to control how the loop(s) in the method should be optimised. On Thu, 11 Oct 2018 at 21:33, LaMothe, Ryan R wrote: > While I agree with Brian's comments later in this thread on the below > question, I'd like to expand on the question just a little: We've always > wished we could annotate for loops, while loops, etc. so that we can handle > them with custom back-end code/processing (e.g. parallelism, GPU, cluster > queue, etc.). Has that already been attempted/proposed or is that something > we would need to propose new? > > ____________________________________________ > Ryan LaMothe > > -----Original Message----- > From: discuss [mailto:discuss-bounces at openjdk.java.net] On Behalf Of > arjan tijms > Sent: Thursday, October 11, 2018 6:19 AM > To: discuss > Subject: More precise annotation targets > > Hi, > > I wonder if the following would make sense to consider for a Java language > enhancement: > > Annotations can currently be targeted > to TYPE, FIELD, METHOD, TYPE_PARAMETER etc. > > For lots of cases this is fine, but in other case you need a bit more > detail. For instance, consider an @ActionEvent annotation that targets > METHOD, but actually can only be applied on methods with a specific > signature such as void method(Action); and void method(); > > You might want to have correct placement of the annotation expressed in a > little more exact way, like e.g. > > @Target(METHOD) > @TargetMethods( {ActionInterface.class, ActionInterface2.class}) > @Retention(RUNTIME) > public @interface ActionEvent {} > > > With ActionInterface.class and ActionInterface2.class both functional > classes. > > Alternatively: > > @Target(METHOD) > @TargetMethods( { > @MethodSignature( > return=Void.class, arguments=Action.class), > @MethodSignature( > return=Void.class)} > } > @Retention(RUNTIME) > public @interface ActionEvent {} > > The syntax used is just illustrative of the idea. > > Thoughts? > > Kind regards, > Arjan >