Re: [External] : Re: Eclipse and Gradle in OpenJFX

[Nir Lisker]

https://github.com/eclipse/buildship/issues/658 is not that relevant
because it describes a problem in Gradle's integration with Eclipse, not
with Buildship, but it's reported on Buildship, so I don't think there's
much to resolve there except for alignment issues. It has since been solved
on Gradle's side. If you go to Preferences > Grade > Experimental features
> Enable module support, the described issue will be resolved (and maybe
even without it because I'm not sure these features are experimental
anymore - Gradle 7 enabled module support by default
https://docs.gradle.org/7.0/release-notes.html#promoted-features).

On Wed, Jun 19, 2024 at 3:28 AM Andy Goryachev 
wrote:

> Thank you Kevin, for this bit of insight.  I see the Buildship issue
> mentioned in one of the comments is still open with no one assigned
>
>
>
> https://github.com/eclipse/buildship/issues/658
>
>
>
> Chances that it will be fixed in a reasonable time frame are slim to
> none.  I would recommend to make the changes (remove the gradle nature from
> eclipse config files) in the meantime, as it allows for clean import of the
> whole thing into Eclipse.
>
>
>
> Once the situation with Buildship changes, we can remove the Eclipse files
> altogether and rely on gradle import per JDK-8223374.
>
>
>
> I am also very interested in Nir's view on the subject.
>
>
>
> -andy
>
>
>
>
>
>
>
> *From: *Kevin Rushforth 
> *Date: *Tuesday, June 18, 2024 at 16:09
> *To: *Andy Goryachev , Thiago Milczarek Sayão <
> thiago.sa...@gmail.com>
> *Cc: *openjfx-dev@openjdk.org 
> *Subject: *Re: [External] : Re: Eclipse and Gradle in OpenJFX
>
> We also did that for NetBeans, meaning we removed the NetBeans
> IDE-specific files and use their gradle plug-in (with somewhat mixed
> results). See https://bugs.openjdk.org/browse/JDK-8223375
>
> FWIW, there is an open issue to do the same for Eclipse, but I think it
> hasn't been looked at in a while. Nir is the assignee so he will likely
> have some thoughts on this. https://bugs.openjdk.org/browse/JDK-8223374
>
> -- Kevin
>
> On 6/18/2024 1:14 PM, Andy Goryachev wrote:
>
> Interesting, thank you, Thiago.
>
>
>
> Maybe it's just the quality of gradle support in IntelliJ, or complexity
> of the Buildship plug-in in Eclipse.  It never worked for me, and removing
> the gradle nature from Eclipse project files has an added benefit of
> removing an extra dependency.
>
>
>
> -andy
>
>
>
>
>
>
>
> *From: *Thiago Milczarek Sayão 
> 
> *Date: *Tuesday, June 18, 2024 at 12:51
> *To: *Andy Goryachev 
> 
> *Cc: *openjfx-dev@openjdk.org 
> 
> *Subject: *[External] : Re: Eclipse and Gradle in OpenJFX
>
> Andy,
>
>
>
> We kind of did the opposite for Intellij (got rid of the .iml files and
> went for gradle import):
>
>
>
> https://github.com/openjdk/jfx/pull/1009
> 
>
>
>
> I couldn't get it to detect the manual tests tho. Changing some gradle
> files worked, but would require a deeper review, so we went without it.
>
>
>
> -- Thiago.
>
>
>
> Em ter., 18 de jun. de 2024 às 16:05, Andy Goryachev <
> andy.goryac...@oracle.com> escreveu:
>
> Dear developers:
>
>
>
> Does anyone use gradle in Eclipse (Buildship plug-in) with the OpenJFX
> repo?
>
>
>
> The reason I am asking is that in my experience, the gradle nature in
> OpenJFX is either misconfigured, or obsolete, or both.  There is a rather
> old wiki page [0] which describes the Eclipse setup, though I don't think
> it is correct anymore.  The initial import of the repository in Eclipse
> triggers an internal gradle run which creates/modifies a bunch of
> .classpath and .project files which must be undone before the workspace
> becomes usable.  In any case, only a proper command line gradle build is
> supported anyway.
>
>
>
> I would like to propose removing the gradle nature from Eclipse's .project
> files in OpenJFX.  Once done, the projects can be trivially imported into a
> new workspace with no extra steps required.  This change has no impact on
> command line build whatsoever.
>
>
>
> What do you think?
>
>
>
> Thank you
>
> -andy
>
>
>
>
>
>
>
> *References*
>
>
>
> [1]
> https://wiki.openjdk.org/display/OpenJFX/Using+an+IDE#UsinganIDE-ConfigureEclipsetousethelatestJDK
>
>
>

Re: Eclipse and Gradle in OpenJFX

[Nir Lisker]

It has been a while since I tried a clean import of jfx, but the
instructions in
https://wiki.openjdk.org/display/OpenJFX/Using+an+IDE#UsinganIDE-UsingEclipse
seem correct, unless something changed. What you describe is written there.
Only the initial import requires a gradle build, and after reverting the
project and classpath changes, you can work with ECJ (unless you need tasks
to build native code etc.)

What is worth looking at is the 'eclipse' gradle task that tries to
generate these files according to the gradle files. However, the way the
project is built in gradle is both complicated and very old (compliant with
gradle 2 I think), so I don't know how well that will work. In my modern
projects, the 'eclipse' task works really well and allows me to not check
in the eclipse files: a gradle refresh/synch is run once (does all the
configuration and dependency management), and then running 'eclipse' once
sets up the eclipse side.

On Tue, Jun 18, 2024 at 10:52 PM Thiago Milczarek Sayão <
thiago.sa...@gmail.com> wrote:

> Andy,
>
> We kind of did the opposite for Intellij (got rid of the .iml files and
> went for gradle import):
>
> https://github.com/openjdk/jfx/pull/1009
>
> I couldn't get it to detect the manual tests tho. Changing some gradle
> files worked, but would require a deeper review, so we went without it.
>
> -- Thiago.
>
> Em ter., 18 de jun. de 2024 às 16:05, Andy Goryachev <
> andy.goryac...@oracle.com> escreveu:
>
>> Dear developers:
>>
>>
>>
>> Does anyone use gradle in Eclipse (Buildship plug-in) with the OpenJFX
>> repo?
>>
>>
>>
>> The reason I am asking is that in my experience, the gradle nature in
>> OpenJFX is either misconfigured, or obsolete, or both.  There is a rather
>> old wiki page [0] which describes the Eclipse setup, though I don't think
>> it is correct anymore.  The initial import of the repository in Eclipse
>> triggers an internal gradle run which creates/modifies a bunch of
>> .classpath and .project files which must be undone before the workspace
>> becomes usable.  In any case, only a proper command line gradle build is
>> supported anyway.
>>
>>
>>
>> I would like to propose removing the gradle nature from Eclipse's
>> .project files in OpenJFX.  Once done, the projects can be trivially
>> imported into a new workspace with no extra steps required.  This change
>> has no impact on command line build whatsoever.
>>
>>
>>
>> What do you think?
>>
>>
>>
>> Thank you
>>
>> -andy
>>
>>
>>
>>
>>
>>
>>
>> *References*
>>
>>
>>
>> [1]
>> https://wiki.openjdk.org/display/OpenJFX/Using+an+IDE#UsinganIDE-ConfigureEclipsetousethelatestJDK
>>
>

Re: [External] : Re: Eclipse and Gradle in OpenJFX

[Andy Goryachev]

Thank you Kevin, for this bit of insight.  I see the Buildship issue mentioned 
in one of the comments is still open with no one assigned

https://github.com/eclipse/buildship/issues/658

Chances that it will be fixed in a reasonable time frame are slim to none.  I 
would recommend to make the changes (remove the gradle nature from eclipse 
config files) in the meantime, as it allows for clean import of the whole thing 
into Eclipse.

Once the situation with Buildship changes, we can remove the Eclipse files 
altogether and rely on gradle import per JDK-8223374.

I am also very interested in Nir's view on the subject.

-andy



From: Kevin Rushforth 
Date: Tuesday, June 18, 2024 at 16:09
To: Andy Goryachev , Thiago Milczarek Sayão 

Cc: openjfx-dev@openjdk.org 
Subject: Re: [External] : Re: Eclipse and Gradle in OpenJFX
We also did that for NetBeans, meaning we removed the NetBeans IDE-specific 
files and use their gradle plug-in (with somewhat mixed results). See 
https://bugs.openjdk.org/browse/JDK-8223375

FWIW, there is an open issue to do the same for Eclipse, but I think it hasn't 
been looked at in a while. Nir is the assignee so he will likely have some 
thoughts on this. https://bugs.openjdk.org/browse/JDK-8223374

-- Kevin

On 6/18/2024 1:14 PM, Andy Goryachev wrote:
Interesting, thank you, Thiago.

Maybe it's just the quality of gradle support in IntelliJ, or complexity of the 
Buildship plug-in in Eclipse.  It never worked for me, and removing the gradle 
nature from Eclipse project files has an added benefit of removing an extra 
dependency.

-andy



From: Thiago Milczarek Sayão 

Date: Tuesday, June 18, 2024 at 12:51
To: Andy Goryachev 
Cc: openjfx-dev@openjdk.org 

Subject: [External] : Re: Eclipse and Gradle in OpenJFX
Andy,

We kind of did the opposite for Intellij (got rid of the .iml files and went 
for gradle import):

https://github.com/openjdk/jfx/pull/1009

I couldn't get it to detect the manual tests tho. Changing some gradle files 
worked, but would require a deeper review, so we went without it.

-- Thiago.

Em ter., 18 de jun. de 2024 às 16:05, Andy Goryachev 
mailto:andy.goryac...@oracle.com>> escreveu:
Dear developers:

Does anyone use gradle in Eclipse (Buildship plug-in) with the OpenJFX repo?

The reason I am asking is that in my experience, the gradle nature in OpenJFX 
is either misconfigured, or obsolete, or both.  There is a rather old wiki page 
[0] which describes the Eclipse setup, though I don't think it is correct 
anymore.  The initial import of the repository in Eclipse triggers an internal 
gradle run which creates/modifies a bunch of .classpath and .project files 
which must be undone before the workspace becomes usable.  In any case, only a 
proper command line gradle build is supported anyway.

I would like to propose removing the gradle nature from Eclipse's .project 
files in OpenJFX.  Once done, the projects can be trivially imported into a new 
workspace with no extra steps required.  This change has no impact on command 
line build whatsoever.

What do you think?

Thank you
-andy



References

[1] 
https://wiki.openjdk.org/display/OpenJFX/Using+an+IDE#UsinganIDE-ConfigureEclipsetousethelatestJDK

Re: [External] : Re: Eclipse and Gradle in OpenJFX

[Kevin Rushforth]

We also did that for NetBeans, meaning we removed the NetBeans 
IDE-specific files and use their gradle plug-in (with somewhat mixed 
results). See https://bugs.openjdk.org/browse/JDK-8223375


FWIW, there is an open issue to do the same for Eclipse, but I think it 
hasn't been looked at in a while. Nir is the assignee so he will likely 
have some thoughts on this. https://bugs.openjdk.org/browse/JDK-8223374


-- Kevin


On 6/18/2024 1:14 PM, Andy Goryachev wrote:


Interesting, thank you, Thiago.

Maybe it's just the quality of gradle support in IntelliJ, or 
complexity of the Buildship plug-in in Eclipse.  It never worked for 
me, and removing the gradle nature from Eclipse project files has an 
added benefit of removing an extra dependency.


-andy

*From: *Thiago Milczarek Sayão 
*Date: *Tuesday, June 18, 2024 at 12:51
*To: *Andy Goryachev 
*Cc: *openjfx-dev@openjdk.org 
*Subject: *[External] : Re: Eclipse and Gradle in OpenJFX

Andy,

We kind of did the opposite for Intellij (got rid of the .iml files 
and went for gradle import):


https://github.com/openjdk/jfx/pull/1009 



I couldn't get it to detect the manual tests tho. Changing some gradle 
files worked, but would require a deeper review, so we went without it.


-- Thiago.

Em ter., 18 de jun. de 2024 às 16:05, Andy Goryachev 
 escreveu:


Dear developers:

Does anyone use gradle in Eclipse (Buildship plug-in) with the
OpenJFX repo?

The reason I am asking is that in my experience, the gradle nature
in OpenJFX is either misconfigured, or obsolete, or both.  There
is a rather old wiki page [0] which describes the Eclipse setup,
though I don't think it is correct anymore.  The initial import of
the repository in Eclipse triggers an internal gradle run which
creates/modifies a bunch of .classpath and .project files which
must be undone before the workspace becomes usable. In any case,
only a proper command line gradle build is supported anyway.

I would like to propose removing the gradle nature from Eclipse's
.project files in OpenJFX.  Once done, the projects can be
trivially imported into a new workspace with no extra steps
required.  This change has no impact on command line build whatsoever.

What do you think?

Thank you

-andy

*References*

[1]

https://wiki.openjdk.org/display/OpenJFX/Using+an+IDE#UsinganIDE-ConfigureEclipsetousethelatestJDK

Re: Platform diferences

[Martin Fox]

The alert is being shown without setting its screen or position so it will 
default to the primary screen regardless of where the main window is. It might 
make sense for new windows to default to the screen of the active stage to 
reduce these sorts of surprises. In any case it looks like this decision isn’t 
being made in the platform code, when creating a new window glass is passed the 
screen.

On Mac things do get strange if the main window is in fullscreen mode and has 
taken over a Space (aka virtual desktop). The alert and the main window are 
both top-level DECORATED windows and can’t share that space. The work-around is 
to set the alert’s StageStyle to UTILITY before showing it.

> On 6/17/2024 1:52 PM, Andy Goryachev wrote:
> Thank you for clarification.
>  
> I guess the only problem I see (and which applies to both mac and linux) is 
> that the alert window appears on the wrong monitor - I would expect it to 
> appear on the same monitor where the main window is positioned.
>  
> -andy

Re: [External] : Re: Eclipse and Gradle in OpenJFX

[Andy Goryachev]

Interesting, thank you, Thiago.

Maybe it's just the quality of gradle support in IntelliJ, or complexity of the 
Buildship plug-in in Eclipse.  It never worked for me, and removing the gradle 
nature from Eclipse project files has an added benefit of removing an extra 
dependency.

-andy



From: Thiago Milczarek Sayão 
Date: Tuesday, June 18, 2024 at 12:51
To: Andy Goryachev 
Cc: openjfx-dev@openjdk.org 
Subject: [External] : Re: Eclipse and Gradle in OpenJFX
Andy,

We kind of did the opposite for Intellij (got rid of the .iml files and went 
for gradle import):

https://github.com/openjdk/jfx/pull/1009

I couldn't get it to detect the manual tests tho. Changing some gradle files 
worked, but would require a deeper review, so we went without it.

-- Thiago.

Em ter., 18 de jun. de 2024 às 16:05, Andy Goryachev 
mailto:andy.goryac...@oracle.com>> escreveu:
Dear developers:

Does anyone use gradle in Eclipse (Buildship plug-in) with the OpenJFX repo?

The reason I am asking is that in my experience, the gradle nature in OpenJFX 
is either misconfigured, or obsolete, or both.  There is a rather old wiki page 
[0] which describes the Eclipse setup, though I don't think it is correct 
anymore.  The initial import of the repository in Eclipse triggers an internal 
gradle run which creates/modifies a bunch of .classpath and .project files 
which must be undone before the workspace becomes usable.  In any case, only a 
proper command line gradle build is supported anyway.

I would like to propose removing the gradle nature from Eclipse's .project 
files in OpenJFX.  Once done, the projects can be trivially imported into a new 
workspace with no extra steps required.  This change has no impact on command 
line build whatsoever.

What do you think?

Thank you
-andy



References

[1] 
https://wiki.openjdk.org/display/OpenJFX/Using+an+IDE#UsinganIDE-ConfigureEclipsetousethelatestJDK

Re: Eclipse and Gradle in OpenJFX

[Thiago Milczarek Sayão]

Andy,

We kind of did the opposite for Intellij (got rid of the .iml files and
went for gradle import):

https://github.com/openjdk/jfx/pull/1009

I couldn't get it to detect the manual tests tho. Changing some gradle
files worked, but would require a deeper review, so we went without it.

-- Thiago.

Em ter., 18 de jun. de 2024 às 16:05, Andy Goryachev <
andy.goryac...@oracle.com> escreveu:

> Dear developers:
>
>
>
> Does anyone use gradle in Eclipse (Buildship plug-in) with the OpenJFX
> repo?
>
>
>
> The reason I am asking is that in my experience, the gradle nature in
> OpenJFX is either misconfigured, or obsolete, or both.  There is a rather
> old wiki page [0] which describes the Eclipse setup, though I don't think
> it is correct anymore.  The initial import of the repository in Eclipse
> triggers an internal gradle run which creates/modifies a bunch of
> .classpath and .project files which must be undone before the workspace
> becomes usable.  In any case, only a proper command line gradle build is
> supported anyway.
>
>
>
> I would like to propose removing the gradle nature from Eclipse's .project
> files in OpenJFX.  Once done, the projects can be trivially imported into a
> new workspace with no extra steps required.  This change has no impact on
> command line build whatsoever.
>
>
>
> What do you think?
>
>
>
> Thank you
>
> -andy
>
>
>
>
>
>
>
> *References*
>
>
>
> [1]
> https://wiki.openjdk.org/display/OpenJFX/Using+an+IDE#UsinganIDE-ConfigureEclipsetousethelatestJDK
>

Eclipse and Gradle in OpenJFX

[Andy Goryachev]

Dear developers:

Does anyone use gradle in Eclipse (Buildship plug-in) with the OpenJFX repo?

The reason I am asking is that in my experience, the gradle nature in OpenJFX 
is either misconfigured, or obsolete, or both.  There is a rather old wiki page 
[0] which describes the Eclipse setup, though I don't think it is correct 
anymore.  The initial import of the repository in Eclipse triggers an internal 
gradle run which creates/modifies a bunch of .classpath and .project files 
which must be undone before the workspace becomes usable.  In any case, only a 
proper command line gradle build is supported anyway.

I would like to propose removing the gradle nature from Eclipse's .project 
files in OpenJFX.  Once done, the projects can be trivially imported into a new 
workspace with no extra steps required.  This change has no impact on command 
line build whatsoever.

What do you think?

Thank you
-andy



References

[1] 
https://wiki.openjdk.org/display/OpenJFX/Using+an+IDE#UsinganIDE-ConfigureEclipsetousethelatestJDK

Re: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout [v2]

[Andy Goryachev]

On Tue, 14 May 2024 22:29:18 GMT, Martin Fox  wrote:

>> On Linux getKeyCodeForChar does not consult the current keyboard layout. For 
>> example, it assumes the “+” character is on KeyCode.PLUS even on layouts 
>> which don’t generate KeyCode.PLUS. The result is that most 
>> KeyCharacterCombinations don’t work.
>> 
>> This PR fixes this using the same approach that Mac glass uses. When the 
>> user types a key we lookup all the characters that key might generate and 
>> put them in a map. getKeyCodeForChar then consults the map to find the Java 
>> key code. This ensures that we only pay attention to keys that are on the 
>> user’s physical keyboard.
>> 
>> (Some Linux layout maps are expansive and include entries for keys that may 
>> be on the user’s keyboard but probably aren’t, like “(“ and “)” on the 
>> numeric keypad. If we simply ask for all entries that generate a given 
>> character we can get multiple hits with no good way to determine which ones 
>> are physically present.)
>> 
>> This PR also contains fixes to the Robot to enable testing. When Glass 
>> consults the GdkKeymap to determine which keys might generate a keyval GDK 
>> returns a list covering every installed layout and shift level. The old 
>> Glass code simply picked the first entry in the list. This PR iterates 
>> through the list looking for one that works for the current layout and 
>> correct shift level.
>
> Martin Fox has updated the pull request with a new target base due to a merge 
> or a rebase. The incremental webrev excludes the unrelated changes brought in 
> by the merge/rebase. The pull request contains ten additional commits since 
> the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into linuxcharcombo
>  - Comment fixes
>  - Consistency in naming conventions and comment cleanup.
>  - Merge remote-tracking branch 'upstream/master' into linuxcharcombo
>  - Expanded robot lookup table, general cleanup
>  - Merge remote-tracking branch 'upstream/master' into linuxcharcombo
>  - Resolving duplicates for Robot, fallback for getKeyCodeForChar
>  - Merge remote-tracking branch 'upstream/master' into linuxcharcombo
>  - KeyCharacterCombination fixes on Linux

Tested on linux mint, the app in the ticket fails without the fix and works 
with the fix.

The code looks good to me, though I'd like to have a second pair of eyes on it.

-

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1373#pullrequestreview-2125852531

Re: RFR: 8327255: javac lint warnings: removal, missing-explicit-ctor

[Ambarish Rapte]

On Wed, 12 Jun 2024 20:03:24 GMT, Kevin Rushforth  wrote:

> This PR updates `build.gradle` to define javac lint options for three 
> different types of java compilation tasks: sdk classes, test classes 
> (including shims), and tool classes (including JSLC). The defaults for these 
> three groups of lint options are specified in `build.gradle`.
> 
> We also define three gradle properties that can be used at build time to 
> override the global lint options for each of the three categories of tasks as 
> follows:
> 
> * `LINT` - used when compiling sdk tasks : default = 
> "removal,missing-explicit-ctor"
> * `TOOL_LINT` - used when compiling tool tasks : default = ""
> * `TEST_LINT` - used when compiling test tasks : default = ""
> 
> Each property takes a string with a comma-separated list of lint options. For 
> example:
> 
> 
> gradle -PLINT="deprecation,removal" sdk
> 
> 
> I provided a build mechanism to add extra per-module lint options in 
> `build.gradle`. None are currently defined, but I tested the logic to show 
> that it can be. I did not provide a way to override the per-module lint 
> options via the command line. Once we start using them, we might consider 
> adding that.
> 
> While testing this PR, I ran into a few places where we need to suppress 
> removal warnings for use of our own internal classes that are terminally 
> deprecated, so I filed 
> [JDK-8334143](https://bugs.openjdk.org/browse/JDK-8334143) to track this, and 
> added the missing annotations in this PR.
> 
> I also tested with JDK 23 to verify that we are now getting the expected 
> warnings for the use of sun.misc.Unsafe, and filed two bugs 
> --[JDK-8334138](https://bugs.openjdk.org/browse/JDK-8334138) to (temporarily) 
> suppress those warnings in this PR and 
> [JDK-8334137](https://bugs.openjdk.org/browse/JDK-8334137) to eventually fix 
> them by replacing our use of sun.misc.Unsafe.

Looks good, tested several combination of options. Have one minor query, added 
as comment.
An observation to mention: 
In setupLintOptions the options are separated and provided to javac 
individually. though the comma separated list can be provided at once.
I tested that a single comma separated list works, but in case of any invalid 
option the error message is not clear (It prints all the options in list). But 
when options are provided individually then error points out exact invalid 
option.

build.gradle line 4139:

> 4137: }
> 4138: } else if (compile.name == "compileJslcJava" ||
> 4139: compile.name == "compileToolJava") {

Should we include the _compileToolsJava_ task from media too ?

-

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1474#pullrequestreview-2125657996
PR Review Comment: https://git.openjdk.org/jfx/pull/1474#discussion_r1644548174