Re: Subject: JavaFX dependency injection

[Matthieu BROUILLARD]

Hi,

This is not a new subject and I guess we already received answers in the
past on this list: JavaFX team does not provide any DI mechanism just like
core java teams do not provide any DI on java-se. What is provided is
"only" the possibility to hook controller factory (which allows already a
lot).

It has been for a while since people started to use DI for JavaFX:
- guice blog post July 2012:
http://andrewtill.blogspot.be/2012/07/creating-javafx-controllers-using-guice.html
- CDI blog post August 2012 :
http://blog.matthieu.brouillard.fr/2012/08/06/fxml-javafx-powered-by-cdi-jboss-weld_6/
- then Adam Bien provided Afterburner in April 2013 :
https://github.com/AdamBien/afterburner.fx
- you can even use another DI engine with afterburner :
http://blog.matthieu.brouillard.fr/2014/12/05/topgun-afterburner-finally-announced/

At AGFA, we used to have our own little CDI based framework to do DI, but
we stopped due to memory consumption of weld-client at that time.

As currently the only information provided by the controller factory is the
controller class I would suggest you to use that instead of a bean id.

And if you want a maintained javafx enabled DI framework, go with
Afterburner or Gluon Ignite.

Matthieu

On Wed, Nov 25, 2015 at 4:29 PM, Nitin Malik  wrote:

> + mailgroup
>
> I dont think its non-standard. We have solved this by creating a factory
> that holds the bean id (and does a lookup when callback is invoked).
> Alternatively, to make the solution Spring-free, the factory can hold the
> controller object.
>
> Both these approaches work, but seem like a work around due to the
> restrictive API.
>
> I would like to get inputs from the Oracle folks on this.
>
> Nitin
>
>
> -- Forwarded message --
> From: Eugene Ryzhikov 
> Date: Tue, Nov 24, 2015 at 8:22 PM
> Subject: Re: Subject: JavaFX dependency injection
> To: Nitin Malik 
> Cc: openjfx-dev 
>
>
> Nitin,
>
> Ignite makes use of standard JavaFX API, which provides only controller
> class as a parameter to a controller factory.
> I imagine you're proposing that access to bean id would be given in some
> non-standard way?
>
> In any case, Ignite is an open source framework, and any type of
> contributions are welcome.
> If you have an idea which can add to existing functionality, please send us
> a pull request. We’ll be glad to discuss it.
>
> Eugene
>
> From: Nitin Malik 
> Date: Tuesday, November 24, 2015 at 8:03 PM
> To: Eugene Ryzhikov 
> Subject: Re: Subject: JavaFX dependency injection
>
> Hi Eugene,
>
> This look promising, but I dont think it addresses the multiple controller
> scenario (#1) I outlined in my original mail.
>
> Specifically looking at this line
> <
> https://bitbucket.org/gluon-oss/ignite/src/c85197b33852b78b1a519dca2b1424314cb899fb/spring/src/main/java/com/gluonhq/ignite/spring/SpringContext.java?at=default=file-view-default#SpringContext.java-89
> >,
> the lookup is by class, not Spring bean. Are there plans to add support for
> this?
>
> Regards,
> Nitin
>
>
> On Tue, Nov 24, 2015 at 4:55 PM, Eugene Ryzhikov 
> wrote:
>
> >
> > At Gluon we’ve open-sourced the framework called Ignite just for this
> > purpose.
> >
> > With this library, developers can use popular dependency injection
> > frameworks in their JavaFX applications, including inside their FXML
> > controllers. Gluon Ignite creates a common abstraction over several
> popular
> > dependency injection frameworks (currently Guice, Spring, and Dagger).
> Full
> > support of JSR-330 makes using dependency injection in JavaFX
> applications
> > trivial.
> >
> > For more information take a look at our blog at
> >
> >
> http://gluonhq.com/announcing-gluon-ignite-easy-javafx-dependency-injection/
> >
> > Eugene
> >
> >
> >
>

Re: TableCell.getTableRow() return value

[Jonathan Giles]

It was an oversight at the time, and (from memory) is now a breaking change to 
fix it, so for now it remains as it is, sadly.

-- Jonathan
Sent from a touch device. Please excuse my brevity.

On 26 November 2015 03:33:04 GMT+13:00, Lawrence Parker 
 wrote:
>Seems like getTableRow() should return TableRow instead of just
>TableRow.  That way I wouldn’t have to cast getItem().
>
>   
> https://docs.oracle.com/javase/8/javafx/api/javafx/scene/control/TableCell.html
>
>
>
>
>
>@Override
>public void updateItem(Boolean isEnabled, boolean empty) {
>...
>TestCase testCase = (TestCase)getTableRow().getItem();
>
>This would be nicer:
>
>TestCase testCase = getTableRow().getItem();
>
>Seems like an easy change to the getTableRow() method:
>
>public class TableCell extends IndexedCell {
>...
>public final TableRow getTableRow() { return tableRow.get(); }
>
>
>Was this an oversight, or is there a reason that getTableRow() needs to
>return TableRow instead of TableRow?
>
>Thanks for any help.
>
>-Larry

Bulk packager integration

[Danno Ferrin]

Kevin, Chris, Dmitry

This is a bulk packager integration from the packager sandbox to the JavaFX 
Sandbox, please review.

webrev: 

There are three changes outside of the fxpackager module that I think Kevin 
needs to give his approval for.

Two changes are in the build.gradle.  The first adds a concept of 
classesModuleExclude which is a regexp for files to exclude from the modular 
jar. This is to support creating the ant jar outside of the module system so 
that ant can read the required types and classes.

The second change is to introduce JDK9_MODULES, read off of an environmental 
variable.  This should point to your jmods directory (not explored modules, 
this must be jmods).  This is to support the packagerdev target which now needs 
a pointer to the jmods which as of yet does not have a standard location 
relative to the JDK/JRE.

The third change is the addition of another module-info.java.extra file.  This 
one exposes the invocation API for JDeps to packager so the detectmodules can 
use it to sniff out modules from the classpath.

The remainder of the changes are internal to the fxpackager modules and 
represent contributions from Chris Bensen, Dmitry Cherepanov, and myself 
finishing out the last details for JEP275.  This patch should make it feature 
complete (but not bug complete, we got another milestone for that).

--Danno

Re: Bulk packager integration

[Danno Ferrin]

Here's the webrev: http://cr.openjdk.java.net/~shemnon/8080531/webrev.07/ 

(it's been a stressful morning)

> On Nov 25, 2015, at 9:38 AM, Danno Ferrin  wrote:
> 
> Kevin, Chris, Dmitry
> 
> This is a bulk packager integration from the packager sandbox to the JavaFX 
> Sandbox, please review.
> 
> webrev: 
> 
> There are three changes outside of the fxpackager module that I think Kevin 
> needs to give his approval for.
> 
> Two changes are in the build.gradle.  The first adds a concept of 
> classesModuleExclude which is a regexp for files to exclude from the modular 
> jar. This is to support creating the ant jar outside of the module system so 
> that ant can read the required types and classes.
> 
> The second change is to introduce JDK9_MODULES, read off of an environmental 
> variable.  This should point to your jmods directory (not explored modules, 
> this must be jmods).  This is to support the packagerdev target which now 
> needs a pointer to the jmods which as of yet does not have a standard 
> location relative to the JDK/JRE.
> 
> The third change is the addition of another module-info.java.extra file.  
> This one exposes the invocation API for JDeps to packager so the 
> detectmodules can use it to sniff out modules from the classpath.
> 
> The remainder of the changes are internal to the fxpackager modules and 
> represent contributions from Chris Bensen, Dmitry Cherepanov, and myself 
> finishing out the last details for JEP275.  This patch should make it feature 
> complete (but not bug complete, we got another milestone for that).
> 
> --Danno

[9, 8u] review request: [JAVADOC] Change docs to not refer to full-screen exclusive mode

[Kevin Rushforth]

David,

Please review this simple doc fix.

https://bugs.openjdk.java.net/browse/JDK-8089847
http://cr.openjdk.java.net/~kcr/8089847/webrev.00/

Thanks.

-- Kevin

Re: TableCell.getTableRow() return value

[Richard Bair]

You should be able to add generics compatibly, you just can't change the 
generics signature. One shot to get it right IIRC.

> On Nov 25, 2015, at 8:57 AM, Jonathan Giles  wrote:
> 
> It was an oversight at the time, and (from memory) is now a breaking change 
> to fix it, so for now it remains as it is, sadly.
> 
> -- Jonathan
> Sent from a touch device. Please excuse my brevity.
> 
>> On 26 November 2015 03:33:04 GMT+13:00, Lawrence Parker 
>>  wrote:
>> Seems like getTableRow() should return TableRow instead of just
>> TableRow.  That way I wouldn’t have to cast getItem().
>> 
>>
>> https://docs.oracle.com/javase/8/javafx/api/javafx/scene/control/TableCell.html
>> 
>> 
>> 
>> 
>> 
>>   @Override
>>   public void updateItem(Boolean isEnabled, boolean empty) {
>> ...
>>   TestCase testCase = (TestCase)getTableRow().getItem();
>> 
>> This would be nicer:
>> 
>>   TestCase testCase = getTableRow().getItem();
>> 
>> Seems like an easy change to the getTableRow() method:
>> 
>> public class TableCell extends IndexedCell {
>> ...
>>   public final TableRow getTableRow() { return tableRow.get(); }
>> 
>> 
>> Was this an oversight, or is there a reason that getTableRow() needs to
>> return TableRow instead of TableRow?
>> 
>> Thanks for any help.
>> 
>> -Larry

Re: Bulk packager integration

[Kevin Rushforth]

1) I get the following error if I apply the patch and do a build:

:fxpackager:compileJava/localhome/kcr/javafx/9-jake-kcr/jfx/rt/modules/fxpackager/src/main/java/com/oracle/tools/packager/JLinkBundlerHelper.java:3: 
error: package com.sun.tools.jdeps does not exist

import com.sun.tools.jdeps.Main;
 ^

Does this require a newer version of JDK9 jigsaw or is there some other 
issue? If the former, then we need to solve a problem that isn't yet 
solved with the build environment on our Hudson machines before this can 
go in.



2) The JDK9_MODULES is a new variable that isn't currently defined. What 
should it be set to? It looks like it is only used by the packagerDev 
task, so might be OK.



3) The classesModuleExclude mechanism duplicates an existing mechanism 
to filter out classes from going into the modules. Are you sure this new 
mechanism is needed? After I fixed 
https://bugs.openjdk.java.net/browse/JDK-8142381 a couple weeks ago I no 
longer see any classes from ant-javafx.jar showing up in the fxpackager 
module.


-- Kevin


Danno Ferrin wrote:

Here's the webrev: http://cr.openjdk.java.net/~shemnon/8080531/webrev.07/ 

(it's been a stressful morning)

  

On Nov 25, 2015, at 9:38 AM, Danno Ferrin  wrote:

Kevin, Chris, Dmitry

This is a bulk packager integration from the packager sandbox to the JavaFX 
Sandbox, please review.

webrev: 


There are three changes outside of the fxpackager module that I think Kevin 
needs to give his approval for.

Two changes are in the build.gradle.  The first adds a concept of 
classesModuleExclude which is a regexp for files to exclude from the modular 
jar. This is to support creating the ant jar outside of the module system so 
that ant can read the required types and classes.

The second change is to introduce JDK9_MODULES, read off of an environmental 
variable.  This should point to your jmods directory (not explored modules, 
this must be jmods).  This is to support the packagerdev target which now needs 
a pointer to the jmods which as of yet does not have a standard location 
relative to the JDK/JRE.

The third change is the addition of another module-info.java.extra file.  This 
one exposes the invocation API for JDeps to packager so the detectmodules can 
use it to sniff out modules from the classpath.

The remainder of the changes are internal to the fxpackager modules and 
represent contributions from Chris Bensen, Dmitry Cherepanov, and myself 
finishing out the last details for JEP275.  This patch should make it feature 
complete (but not bug complete, we got another milestone for that).

--Danno



  

Re: TableCell.getTableRow() return value

[Kevin Rushforth]

Sounds good. Thanks, Jonathan (and Richard for pointing this out).

-- Kevin


Jonathan Giles wrote:
I think in this situation you're right - I just made the change 
locally and did a full build of the SDK and all apps, and everything 
compiles. My Jira-foo is not strong enough to find the issue I'm 
thinking of, but I do recall an issue in one place in the TableView 
API about generics being added and it breaking something. I wish I 
could find it - I'll keep looking in any case.


I will file a new JBS issue and will propose this change. We can try 
to put it into JDK 9 and give it time to bake, and see if anyone comes 
forward due to being broken by it...


-- Jonathan

On 26/11/15 6:46 AM, Richard Bair wrote:
You should be able to add generics compatibly, you just can't change 
the generics signature. One shot to get it right IIRC.


On Nov 25, 2015, at 8:57 AM, Jonathan Giles 
 wrote:


It was an oversight at the time, and (from memory) is now a breaking 
change to fix it, so for now it remains as it is, sadly.


-- Jonathan
Sent from a touch device. Please excuse my brevity.

On 26 November 2015 03:33:04 GMT+13:00, Lawrence Parker 
 wrote:

Seems like getTableRow() should return TableRow instead of just
TableRow.  That way I wouldn’t have to cast getItem().


https://docs.oracle.com/javase/8/javafx/api/javafx/scene/control/TableCell.html 

 






   @Override
   public void updateItem(Boolean isEnabled, boolean empty) {
...
   TestCase testCase = (TestCase)getTableRow().getItem();

This would be nicer:

   TestCase testCase = getTableRow().getItem();

Seems like an easy change to the getTableRow() method:

public class TableCell extends IndexedCell {
...
   public final TableRow getTableRow() { return tableRow.get(); }


Was this an oversight, or is there a reason that getTableRow() 
needs to

return TableRow instead of TableRow?

Thanks for any help.

-Larry

Fwd: Subject: JavaFX dependency injection

[Nitin Malik]

+ mailgroup

I dont think its non-standard. We have solved this by creating a factory
that holds the bean id (and does a lookup when callback is invoked).
Alternatively, to make the solution Spring-free, the factory can hold the
controller object.

Both these approaches work, but seem like a work around due to the
restrictive API.

I would like to get inputs from the Oracle folks on this.

Nitin


-- Forwarded message --
From: Eugene Ryzhikov 
Date: Tue, Nov 24, 2015 at 8:22 PM
Subject: Re: Subject: JavaFX dependency injection
To: Nitin Malik 
Cc: openjfx-dev 


Nitin,

Ignite makes use of standard JavaFX API, which provides only controller
class as a parameter to a controller factory.
I imagine you're proposing that access to bean id would be given in some
non-standard way?

In any case, Ignite is an open source framework, and any type of
contributions are welcome.
If you have an idea which can add to existing functionality, please send us
a pull request. We’ll be glad to discuss it.

Eugene

From: Nitin Malik 
Date: Tuesday, November 24, 2015 at 8:03 PM
To: Eugene Ryzhikov 
Subject: Re: Subject: JavaFX dependency injection

Hi Eugene,

This look promising, but I dont think it addresses the multiple controller
scenario (#1) I outlined in my original mail.

Specifically looking at this line
,
the lookup is by class, not Spring bean. Are there plans to add support for
this?

Regards,
Nitin


On Tue, Nov 24, 2015 at 4:55 PM, Eugene Ryzhikov 
wrote:

>
> At Gluon we’ve open-sourced the framework called Ignite just for this
> purpose.
>
> With this library, developers can use popular dependency injection
> frameworks in their JavaFX applications, including inside their FXML
> controllers. Gluon Ignite creates a common abstraction over several popular
> dependency injection frameworks (currently Guice, Spring, and Dagger). Full
> support of JSR-330 makes using dependency injection in JavaFX applications
> trivial.
>
> For more information take a look at our blog at
>
> http://gluonhq.com/announcing-gluon-ignite-easy-javafx-dependency-injection/
>
> Eugene
>
>
>

Re: TableCell.getTableRow() return value

[Lawrence Parker]

Sounds good, thank you very much!!

-Larry

> On Nov 25, 2015, at 3:37 PM, Jonathan Giles  wrote:
> 
> I think in this situation you're right - I just made the change locally and 
> did a full build of the SDK and all apps, and everything compiles. My 
> Jira-foo is not strong enough to find the issue I'm thinking of, but I do 
> recall an issue in one place in the TableView API about generics being added 
> and it breaking something. I wish I could find it - I'll keep looking in any 
> case.
> 
> I will file a new JBS issue and will propose this change. We can try to put 
> it into JDK 9 and give it time to bake, and see if anyone comes forward due 
> to being broken by it...
> 
> -- Jonathan
> 
> On 26/11/15 6:46 AM, Richard Bair wrote:
>> You should be able to add generics compatibly, you just can't change the 
>> generics signature. One shot to get it right IIRC.
>> 
>>> On Nov 25, 2015, at 8:57 AM, Jonathan Giles  
>>> wrote:
>>> 
>>> It was an oversight at the time, and (from memory) is now a breaking change 
>>> to fix it, so for now it remains as it is, sadly.
>>> 
>>> -- Jonathan
>>> Sent from a touch device. Please excuse my brevity.
>>> 
 On 26 November 2015 03:33:04 GMT+13:00, Lawrence Parker 
  wrote:
 Seems like getTableRow() should return TableRow instead of just
 TableRow.  That way I wouldn’t have to cast getItem().
 

 https://docs.oracle.com/javase/8/javafx/api/javafx/scene/control/TableCell.html
 
 
 
 
 
   @Override
   public void updateItem(Boolean isEnabled, boolean empty) {
 ...
   TestCase testCase = (TestCase)getTableRow().getItem();
 
 This would be nicer:
 
   TestCase testCase = getTableRow().getItem();
 
 Seems like an easy change to the getTableRow() method:
 
 public class TableCell extends IndexedCell {
 ...
   public final TableRow getTableRow() { return tableRow.get(); }
 
 
 Was this an oversight, or is there a reason that getTableRow() needs to
 return TableRow instead of TableRow?
 
 Thanks for any help.
 
 -Larry
> 

Re: TableCell.getTableRow() return value

[Jonathan Giles]

I have filed and attached the issue here:
https://bugs.openjdk.java.net/browse/JDK-8144088

@Kevin - would you mind giving this a quick API review please?

-- Jonathan

On 26/11/15 10:00 AM, Jonathan Giles wrote:
I found the Jira issue I was looking forunfortunately it lacks a 
lot of detail. I have just updated it to give the example of why it 
had to be backed out.


https://bugs.openjdk.java.net/browse/JDK-8102370

Fortunately the issue was in another location, and I don't think we 
will have the same issue in this proposed change.


-- Jonathan

On 26/11/15 6:46 AM, Richard Bair wrote:
You should be able to add generics compatibly, you just can't change 
the generics signature. One shot to get it right IIRC.


On Nov 25, 2015, at 8:57 AM, Jonathan Giles 
 wrote:


It was an oversight at the time, and (from memory) is now a breaking 
change to fix it, so for now it remains as it is, sadly.


-- Jonathan
Sent from a touch device. Please excuse my brevity.

On 26 November 2015 03:33:04 GMT+13:00, Lawrence Parker 
 wrote:

Seems like getTableRow() should return TableRow instead of just
TableRow.  That way I wouldn’t have to cast getItem().

https://docs.oracle.com/javase/8/javafx/api/javafx/scene/control/TableCell.html
 






   @Override
   public void updateItem(Boolean isEnabled, boolean empty) {
...
   TestCase testCase = (TestCase)getTableRow().getItem();

This would be nicer:

   TestCase testCase = getTableRow().getItem();

Seems like an easy change to the getTableRow() method:

public class TableCell extends IndexedCell {
...
   public final TableRow getTableRow() { return tableRow.get(); }


Was this an oversight, or is there a reason that getTableRow() 
needs to

return TableRow instead of TableRow?

Thanks for any help.

-Larry

Re: TableCell.getTableRow() return value

[Kevin Rushforth]

Looks good to me. I also added a comment to the bug report.

-- Kevin


Jonathan Giles wrote:

I have filed and attached the issue here:
https://bugs.openjdk.java.net/browse/JDK-8144088

@Kevin - would you mind giving this a quick API review please?

-- Jonathan

On 26/11/15 10:00 AM, Jonathan Giles wrote:
I found the Jira issue I was looking forunfortunately it lacks a 
lot of detail. I have just updated it to give the example of why it 
had to be backed out.


https://bugs.openjdk.java.net/browse/JDK-8102370

Fortunately the issue was in another location, and I don't think we 
will have the same issue in this proposed change.


-- Jonathan

On 26/11/15 6:46 AM, Richard Bair wrote:
You should be able to add generics compatibly, you just can't change 
the generics signature. One shot to get it right IIRC.


On Nov 25, 2015, at 8:57 AM, Jonathan Giles 
 wrote:


It was an oversight at the time, and (from memory) is now a 
breaking change to fix it, so for now it remains as it is, sadly.


-- Jonathan
Sent from a touch device. Please excuse my brevity.

On 26 November 2015 03:33:04 GMT+13:00, Lawrence Parker 
 wrote:

Seems like getTableRow() should return TableRow instead of just
TableRow.  That way I wouldn’t have to cast getItem().

https://docs.oracle.com/javase/8/javafx/api/javafx/scene/control/TableCell.html 

 






   @Override
   public void updateItem(Boolean isEnabled, boolean empty) {
...
   TestCase testCase = (TestCase)getTableRow().getItem();

This would be nicer:

   TestCase testCase = getTableRow().getItem();

Seems like an easy change to the getTableRow() method:

public class TableCell extends IndexedCell {
...
   public final TableRow getTableRow() { return tableRow.get(); }


Was this an oversight, or is there a reason that getTableRow() 
needs to

return TableRow instead of TableRow?

Thanks for any help.

-Larry

Re: TableCell.getTableRow() return value

[Jonathan Giles]

I think in this situation you're right - I just made the change locally 
and did a full build of the SDK and all apps, and everything compiles. 
My Jira-foo is not strong enough to find the issue I'm thinking of, but 
I do recall an issue in one place in the TableView API about generics 
being added and it breaking something. I wish I could find it - I'll 
keep looking in any case.


I will file a new JBS issue and will propose this change. We can try to 
put it into JDK 9 and give it time to bake, and see if anyone comes 
forward due to being broken by it...


-- Jonathan

On 26/11/15 6:46 AM, Richard Bair wrote:

You should be able to add generics compatibly, you just can't change the 
generics signature. One shot to get it right IIRC.


On Nov 25, 2015, at 8:57 AM, Jonathan Giles  wrote:

It was an oversight at the time, and (from memory) is now a breaking change to 
fix it, so for now it remains as it is, sadly.

-- Jonathan
Sent from a touch device. Please excuse my brevity.


On 26 November 2015 03:33:04 GMT+13:00, Lawrence Parker 
 wrote:
Seems like getTableRow() should return TableRow instead of just
TableRow.  That way I wouldn’t have to cast getItem().


https://docs.oracle.com/javase/8/javafx/api/javafx/scene/control/TableCell.html





   @Override
   public void updateItem(Boolean isEnabled, boolean empty) {
...
   TestCase testCase = (TestCase)getTableRow().getItem();

This would be nicer:

   TestCase testCase = getTableRow().getItem();

Seems like an easy change to the getTableRow() method:

public class TableCell extends IndexedCell {
...
   public final TableRow getTableRow() { return tableRow.get(); }


Was this an oversight, or is there a reason that getTableRow() needs to
return TableRow instead of TableRow?

Thanks for any help.

-Larry

[9] Review request for 8139841: Axis class does not render ticks marks when tick labels are invisible

[Vadim Pakhnushev]

Jonathan,

Please review the fix:
https://bugs.openjdk.java.net/browse/JDK-8139841
http://cr.openjdk.java.net/~vadim/8139841/webrev.00/

Thanks,
Vadim