Subject: RFR: 8087980: Add property to disable Monocle cursor
Please review the fix for Add property to disable Monocle cursor: https://bugs.openjdk.java.net/browse/JDK-8087980 https://github.com/openjdk/jfx/pull/5
[no subject]
I have downloaded openjfx-11_windows-x64_bin-sdk.zip and unzipped it in C:\Program Files\Java\jdk-11 and I have also placed openfx in the C:\Program Files\Java\jdk-11\javafx-sdk-11 directory. Now I'd like to configure eclipse to use this two j/sdk(s), but I have not been able to find adequate information regarding this matter. Any suggestions? *ArbolOne Using Fire Fox and Thunderbird. Developing for Android using Java, C/C++, HTM/CSS and SQLite as our platform has been exciting and most rewarding. [ Ñ ]*
[no subject]
Android’de Yahoo Postadan gönderildi
[no subject]
I am so sorry. Was not thinking.I'm trying to fix my browser it crashes all time..again sorry. Thanks cindy prather
Subject: [8u121] Review request for JDK-8178837: Potential performance drawback due to type mismatch
https://bugs.openjdk.java.net/browse/JDK-8178837 There is a potential performance drawback due to a type mismatch in TriangleMesh.java:548 as `points.size()` returns `int` so storing as `double` makes not much sense. I provided a patch which simply replaces double by int.
Re: Subject: New OpenJFX Project Lead: Kevin Rushforth
2016/6/23 11:00:03 -0700, alexandr.scherba...@oracle.com: > On 6/23/2016 8:01 PM, Alexandr Scherbatiy wrote: >> I hereby nominate Kevin Rushforth to OpenJFX Project Lead [1][2]. >> >> Kevin has been working in OpenJFX Project for several years and is >> currently acting as the de facto Project Lead. >> >> Group Leads of the Project’s Sponsoring Groups, the Swing Group: >> Please vote on whether to ratify this change, as required by the >> Bylaws [2]. >> Votes are due by July 1, 2016. Votes must be cast in the open by >> replying to this message. >> >> ... > > All Group Leads of the Project’s Sponsoring Groups voted yes. > According to the Three-Vote Consensus Kevin Rushforth is now the > Lead of the OpenJFX Project. So recorded. - Mark
Re: Subject: New OpenJFX Project Lead: Kevin Rushforth
On 6/23/2016 8:01 PM, Alexandr Scherbatiy wrote: I hereby nominate Kevin Rushforth to OpenJFX Project Lead [1][2]. Kevin has been working in OpenJFX Project for several years and is currently acting as the de facto Project Lead. Group Leads of the Project’s Sponsoring Groups, the Swing Group: Please vote on whether to ratify this change, as required by the Bylaws [2]. Votes are due by July 1, 2016. Votes must be cast in the open by replying to this message. For Three-Vote Consensus instructions, see [3]. Thanks, Alexandr. [1]: http://openjdk.java.net/census#openjfx [2]: http://openjdk.java.net/bylaws#project-lead [3]: http://openjdk.java.net/bylaws#three-vote-consensus All Group Leads of the Project’s Sponsoring Groups voted yes. According to the Three-Vote Consensus Kevin Rushforth is now the Lead of the OpenJFX Project. Thanks, Alexandr.
Re: Subject: New OpenJFX Project Lead: Kevin Rushforth
Vote: yes. Thanks, Alexandr. On 6/23/2016 8:01 PM, Alexandr Scherbatiy wrote: I hereby nominate Kevin Rushforth to OpenJFX Project Lead [1][2]. Kevin has been working in OpenJFX Project for several years and is currently acting as the de facto Project Lead. Group Leads of the Project’s Sponsoring Groups, the Swing Group: Please vote on whether to ratify this change, as required by the Bylaws [2]. Votes are due by July 1, 2016. Votes must be cast in the open by replying to this message. For Three-Vote Consensus instructions, see [3]. Thanks, Alexandr. [1]: http://openjdk.java.net/census#openjfx [2]: http://openjdk.java.net/bylaws#project-lead [3]: http://openjdk.java.net/bylaws#three-vote-consensus
Re: Subject: New OpenJFX Project Lead: Kevin Rushforth
Vote: yes Artem On 6/23/16 8:01 PM, Alexandr Scherbatiy wrote: I hereby nominate Kevin Rushforth to OpenJFX Project Lead [1][2]. Kevin has been working in OpenJFX Project for several years and is currently acting as the de facto Project Lead. Group Leads of the Project’s Sponsoring Groups, the Swing Group: Please vote on whether to ratify this change, as required by the Bylaws [2]. Votes are due by July 1, 2016. Votes must be cast in the open by replying to this message. For Three-Vote Consensus instructions, see [3]. Thanks, Alexandr. [1]: http://openjdk.java.net/census#openjfx [2]: http://openjdk.java.net/bylaws#project-lead [3]: http://openjdk.java.net/bylaws#three-vote-consensus
Subject: New OpenJFX Project Lead: Kevin Rushforth
I hereby nominate Kevin Rushforth to OpenJFX Project Lead [1][2]. Kevin has been working in OpenJFX Project for several years and is currently acting as the de facto Project Lead. Group Leads of the Project’s Sponsoring Groups, the Swing Group: Please vote on whether to ratify this change, as required by the Bylaws [2]. Votes are due by July 1, 2016. Votes must be cast in the open by replying to this message. For Three-Vote Consensus instructions, see [3]. Thanks, Alexandr. [1]: http://openjdk.java.net/census#openjfx [2]: http://openjdk.java.net/bylaws#project-lead [3]: http://openjdk.java.net/bylaws#three-vote-consensus
Re: Subject: JavaFX dependency injection
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 <nmal...@gmail.com> 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 <eryzhi...@gmail.com> > Date: Tue, Nov 24, 2015 at 8:22 PM > Subject: Re: Subject: JavaFX dependency injection > To: Nitin Malik <nmal...@gmail.com> > Cc: openjfx-dev <openjfx-dev-boun...@openjdk.java.net> > > > 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 <nmal...@gmail.com> > Date: Tuesday, November 24, 2015 at 8:03 PM > To: Eugene Ryzhikov <eryzhi...@gmail.com> > 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 <eryzhi...@gmail.com> > 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 > > > > > > >
Fwd: Subject: JavaFX dependency injection
+ 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 <eryzhi...@gmail.com> Date: Tue, Nov 24, 2015 at 8:22 PM Subject: Re: Subject: JavaFX dependency injection To: Nitin Malik <nmal...@gmail.com> Cc: openjfx-dev <openjfx-dev-boun...@openjdk.java.net> 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 <nmal...@gmail.com> Date: Tuesday, November 24, 2015 at 8:03 PM To: Eugene Ryzhikov <eryzhi...@gmail.com> 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 <eryzhi...@gmail.com> 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 > > >
Subject: JavaFX dependency injection
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
Fwd: Subject: JavaFX dependency injection
+ mailgroup -- Forwarded message -- From: Nitin Malik <nmal...@gmail.com> Date: Tue, Nov 24, 2015 at 8:03 PM Subject: Re: Subject: JavaFX dependency injection To: Eugene Ryzhikov <eryzhi...@gmail.com> 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 <eryzhi...@gmail.com> 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 > > >
[no subject]
On Mon, 02 Sep 2013 18:10:17 +0200, Christian Schudt christian.sch...@gmx.de wrote: I agree with that and I also recommend to have a look at Item 17: Design and document for inheritance or else prohibit it from Effective Java. http://uet.vnu.edu.vn/~chauttm/e-books/java/Effective.Java.2nd.Edition.May.2008.3000th.Release.pdf It explains the burden and dangers of non-final design quite well. +1 -1 This applies only to the perfect (final) framework. In other words for a framework without bugs and a framework, where all possible usecases are considered by its author. I agree that there are dangers, when overwriting methods. But in my experience they rarely matter. Once created methods rarely change in a way that affects subclasses. And for major releases of the framework you have to test your application anyway. If you develop a framework, where methods have complex interdependencies you should step back and write smaller, more manageable methods. There are always legitimate reasons to overwrite methods. e.G.: To work around a bug in the framework. To trigger events, when a certain method has been called, to write debug info in a logfile, And no I don't want to roll out my own fork of jdk to my customers to do this -- -1 as well. One of the major points of Java is that it is an object oriented language. By making things final you kill one of the major O.O. benefits, that is subclassing. You can do composition but it's not the same thing as you can not pass in the object to methods that accept the composed class. Though, I also agree that it should be difficult to create a framework where all use cases of subclassing a class are accounted for, especially when you have to preserve backwards compatibility. Best regards, Pedro Duque Vieira
