Re: JavaFX on iOS and Android: The real problem and challenge
ups, I made one mistake: So both solutions use the real Java platform (=OpenJDK)!“ should be So both solutions does not use the real Java platform (=OpenJDK)!“ ;) Am 24.10.2013 um 08:41 schrieb Tobias Bley t...@ultramixer.com: Hello to the community, I read the last discussion about „JavaFX native look and feel“ and have to get out of my mind the following: In my opinion the MAIN point is not „how to bring the native look and feel to iOS/Android“, the real MAIN issue is: we need a professional JVM(!) which works performant and reliable on iOS, Android and Windows 8! Only if we have such a JVM, developers and companies are motivated to develop real commercial apps with JavaFX and contribute stuff back to OpenJFX! RoboVM is a good „prototype“. Niklas is currently one of the most important people for the JavaFX community. He and his company has build the first and one and only real solution to deploy Java and JavaFX code to the iOS platform! His work is really great! But: He is only one(!) person! This kind of complex task I would expect from big companies like Oracle, IBM, SAP or Twitter. But from this direction we don’t hear anything about it. It is not enough that people like Niklas (Trillian AB) or Matthias and me (UltraMixer) are trying to bring JavaFX to iOS and Android. It’s all experimental stuff! Yes, currently we can start JavaFX apps on a real iPhone and iPad. And yes, we have managed to start JavaFX on a real Android device using the Dalvik VM. BUT: this is not a long term solution and only experimental! RoboVM on iOS uses the android class library instead of the real Java = OpenJDK. Our „JavaFX on Android“ solution uses Google Dalvik VM and the Android class library as well! So both solutions use the real Java platform (=OpenJDK)! In my opinion there are only two solutions: 1) Oracle releases their JVM for iOS and Android. 2) The „community“ starts a new company who develops a professional, performant and reliable solution for „JavaFX on iOS and Android“ which contains of a JVM and the 6 degrees Felix described in his blog post, mainly native integration (API) and look and feel (skins, native controls). Cheers, Tobi Am 23.10.2013 um 22:30 schrieb Richard Bair richard.b...@oracle.com: Yes, definitely. On Oct 23, 2013, at 11:52 AM, Scott Palmer swpal...@gmail.com wrote: This is starting to sound like it may also partially address the issue in the desktop space of supplying a native surface (the heavyweight) to draw in that is part of the scene graph. It may not be the ideal solution, but could be useful for specific use cases, like a video preview overlay. Would that make any sense? Scott On Tue, Oct 22, 2013 at 7:59 PM, Richard Bair richard.b...@oracle.com wrote: To do this we need to either solve the auto-layer problem in the NG nodes / Glass / Quantum, or we need to ask the app developer to use SubScene and put all the native stuff in a single SubScene, and all lightweight content above and below it. For the short term, we could use the SubScene approach (Just be careful and don't draw lightweight on top of heavyweights unless you layer an entire sub scene above them) which is probably a perfectly workable solution in the short term. Then somebody just needs to write a set of skins (which can be done in an external project) that map various UI controls directly to native controls. This approach would allow people to have completely native controls while using the FX API, or they can use the lightweight controls (with Modena or with an iOS 7 skin or iOS 6 skin etc). I'm thinking about how to implement the auto-layer, and I'm not sure of the best approach. It seems like you need to hook into the sync-time to determine which nodes can be batched into the same layer, reusing previous layers where possible. If there is a way to then setup the NG peer side so that it thinks it was setup in sub scenes etc, although it really wasn't, then that would leave prism out of the problem (which makes this an easier thing to pull off). hmmm. SubScene itself has a peer. So what I'm thinking is, suppose I have a package: com.sun.javafx.ext.ios.controls and in this package you have all the skins. There is also someplace in here a map of skin - sub scene peer, indicating which of the nodes is in which sub scene peer (layer). Then when the sync takes place, a skin node looks back at siblings etc to determine if it can be placed in the same layer as something before it. If so, then it sets itself as a child on the sub scene as needed. If not, then it creates a new sub scene peer and sets itself on there and then carry on. So then it isn't sync'd to the real scene but instead to one of these fake sub scenes that was created. The idea can be refined, but actually I think this approach might be workable for doing auto-layering. Richard On
hg: openjfx/8/graphics/rt: RT-33491 FXML contains treatAsPrivate stuff that is not prefixed by impl_
Changeset: e3c32ab8f05f Author:Martin Sladecek martin.slade...@oracle.com Date: 2013-10-24 09:26 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e3c32ab8f05f RT-33491 FXML contains treatAsPrivate stuff that is not prefixed by impl_ Reviewed-by: ekrejcir + modules/fxml/src/main/java/com/sun/javafx/fxml/ParseTraceElement.java ! modules/fxml/src/main/java/javafx/fxml/FXMLLoader.java - modules/fxml/src/main/java/javafx/fxml/ParseTraceElement.java ! modules/fxml/src/test/java/javafx/fxml/FXMLLoader_ScriptTest.java ! modules/fxml/src/test/java/javafx/fxml/RT_18218Test.java
CFV: New OpenJFX Committer: Oleg Barbashov
I hereby nominate Oleg Barbashov (OpenJDK user name: ogb) to OpenJFX Committer. Oleg is a member of JavaFX SQE team at Oracle. He is currently an Author in OpenJFX and is an active contributor to this project, about 30 changesets in the tests repository: http://hg.openjdk.java.net/openjfx/8/master Votes are due by Nov 07, 2013. Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Nomination to a project Committer is described in [3]. [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus [3] http://openjdk.java.net/projects#project-committer Thanks, Artem
Re: CFV: New OpenJFX Committer: Oleg Barbashov
Vote: YES Btw, the correct repo is: http://hg.openjdk.java.net/openjfx/8/master/tests -- Kevin Artem Ananiev wrote: I hereby nominate Oleg Barbashov (OpenJDK user name: ogb) to OpenJFX Committer. Oleg is a member of JavaFX SQE team at Oracle. He is currently an Author in OpenJFX and is an active contributor to this project, about 30 changesets in the tests repository: http://hg.openjdk.java.net/openjfx/8/master Votes are due by Nov 07, 2013. Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Nomination to a project Committer is described in [3]. [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus [3] http://openjdk.java.net/projects#project-committer Thanks, Artem
Re: CFV: New OpenJFX Committer: Oleg Barbashov
Vote: YES -- best regards, Anthony On 10/24/2013 04:58 PM, Artem Ananiev wrote: I hereby nominate Oleg Barbashov (OpenJDK user name: ogb) to OpenJFX Committer. Oleg is a member of JavaFX SQE team at Oracle. He is currently an Author in OpenJFX and is an active contributor to this project, about 30 changesets in the tests repository: http://hg.openjdk.java.net/openjfx/8/master Votes are due by Nov 07, 2013. Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Nomination to a project Committer is described in [3]. [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus [3] http://openjdk.java.net/projects#project-committer Thanks, Artem
Re: CFV: New OpenJFX Committer: Oleg Barbashov
On 10/24/2013 5:07 PM, Kevin Rushforth wrote: Vote: YES Btw, the correct repo is: http://hg.openjdk.java.net/openjfx/8/master/tests Thanks for correction. This is indeed the repo I meant. Artem -- Kevin Artem Ananiev wrote: I hereby nominate Oleg Barbashov (OpenJDK user name: ogb) to OpenJFX Committer. Oleg is a member of JavaFX SQE team at Oracle. He is currently an Author in OpenJFX and is an active contributor to this project, about 30 changesets in the tests repository: http://hg.openjdk.java.net/openjfx/8/master Votes are due by Nov 07, 2013. Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Nomination to a project Committer is described in [3]. [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus [3] http://openjdk.java.net/projects#project-committer Thanks, Artem
Re: CFV: New OpenJFX Committer: Victor Shubov
Vote: YES
On Oct 24, 2013, at 9:05 AM, Artem Ananiev artem.anan...@oracle.com wrote:
I hereby nominate Victor Shubov to OpenJFX Committer.
Victor is a member of JavaFX SQE team at Oracle. He has already contributed
enough changesets into the tests repository:
$ hg log -M -u Victor Shubov --template '{author}\n' |wc -l
29
Votes are due by Nov 07, 2013.
Only current OpenJFX Committers [1] are eligible to vote on this nomination.
Votes must be cast in the open by replying to this mailing list.
For Lazy Consensus voting instructions, see [2]. Nomination to a project
Committer is described in [3].
[1] http://openjdk.java.net/census#openjfx
[2] http://openjdk.java.net/bylaws#lazy-consensus
[3] http://openjdk.java.net/projects#project-committer
Thanks,
Artem
Re: CFV: New OpenJFX Committer: Oleg Barbashov
Vote: YES On 10/24/2013 8:58 AM, Artem Ananiev wrote: I hereby nominate Oleg Barbashov (OpenJDK user name: ogb) to OpenJFX Committer. Oleg is a member of JavaFX SQE team at Oracle. He is currently an Author in OpenJFX and is an active contributor to this project, about 30 changesets in the tests repository: http://hg.openjdk.java.net/openjfx/8/master Votes are due by Nov 07, 2013. Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Nomination to a project Committer is described in [3]. [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus [3] http://openjdk.java.net/projects#project-committer Thanks, Artem
Re: CFV: New OpenJFX Committer: Victor Shubov
Vote: YES
On 10/24/2013 9:05 AM, Artem Ananiev wrote:
I hereby nominate Victor Shubov to OpenJFX Committer.
Victor is a member of JavaFX SQE team at Oracle. He has already
contributed enough changesets into the tests repository:
$ hg log -M -u Victor Shubov --template '{author}\n' |wc -l
29
Votes are due by Nov 07, 2013.
Only current OpenJFX Committers [1] are eligible to vote on this
nomination. Votes must be cast in the open by replying to this mailing
list.
For Lazy Consensus voting instructions, see [2]. Nomination to a
project Committer is described in [3].
[1] http://openjdk.java.net/census#openjfx
[2] http://openjdk.java.net/bylaws#lazy-consensus
[3] http://openjdk.java.net/projects#project-committer
Thanks,
Artem
Re: CFV: New OpenJFX Committer: Oleg Barbashov
Vote: yes -phil.
JFXPanel vs. real world usage
Hi, I just took a look at JFXPanel. This implementation is from my perspective just a pin point for a real implementation. The problem with the current one is, that a JFX scene is rendered down to a pixelbuffer that is rendered on a Swing Panel by paintComponent. Is there a particular reason for this? Actually, I expected the embedding of the OpenGL/DirectX context in other words the heavy weigth component of the entire JFX scene. In the current stage of the JFXPanel it's not even usable for very small addons, since the performance is soo damn bad ;) Maybe I missed another way to get JFX inserted into an existing Swing-Application? Any hints? regards Matthias
hg: openjfx/8/graphics/rt: 5 new changesets
Changeset: 6151a4b1b4ef Author:David Grievedavid.gri...@oracle.com Date: 2013-10-24 12:40 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6151a4b1b4ef [DOCS-ONLY] RT-33640 add link to cssref from Node id, style and styleclass properties ! modules/graphics/src/main/java/javafx/css/Styleable.java ! modules/graphics/src/main/java/javafx/scene/Node.java Changeset: 7e06da8d88fb Author:David Grievedavid.gri...@oracle.com Date: 2013-10-24 12:40 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7e06da8d88fb [DOCS-ONLY] RT-33584 minor update to cssref ! modules/graphics/src/main/docs/javafx/scene/doc-files/cssref.html Changeset: 5977c564dda4 Author:David Grievedavid.gri...@oracle.com Date: 2013-10-24 12:40 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5977c564dda4 [DOCS-ONLY] RT-33583 minor update to cssref ! modules/graphics/src/main/docs/javafx/scene/doc-files/cssref.html Changeset: 7a1c60a98900 Author:David Grievedavid.gri...@oracle.com Date: 2013-10-24 12:40 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7a1c60a98900 [DOCS-ONLY] RT-33572 cssref - add section for TableColumnHeader and fix TableView property table. ! modules/graphics/src/main/docs/javafx/scene/doc-files/cssref.html Changeset: bc90b41e06c1 Author:David Grievedavid.gri...@oracle.com Date: 2013-10-24 12:40 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/bc90b41e06c1 [DOCS-ONLY] RT-33548 minor edit to cssref ! modules/graphics/src/main/docs/javafx/scene/doc-files/cssref.html
Re: JFXPanel vs. real world usage
Hi Matthais, There was quite a debate way back when as to whether there should be heavyweight or lightweight embedding. If heavyweight, then FX would not play well with AWT/Swing and would have all the heavyweight/lightweight issues inherent there. If lightweight, then this is more work for the embedding toolkit because it needs to forward events and implement drawing. The simplest implementation of drawing is to draw images. A more complex implementation would require that FX and AWT/Swing communicate using a common underlying graphics currency that both toolkits support (such as OpenGL or DirectX textures). 1) There has been some talk of doing the underlying communication thing but nobody has looked into it. It will require quite low level coordinated changes to AWT/Swing and FX. I did not see a JIRA that is tracking this idea. Feel free to enter one. 2) Please enter a JIRA with a benchmark that is too slow for you using the current JFXPanel implementation. Steve On 2013-10-24 12:03 PM, Matthias Hänel wrote: Hi, I just took a look at JFXPanel. This implementation is from my perspective just a pin point for a real implementation. The problem with the current one is, that a JFX scene is rendered down to a pixelbuffer that is rendered on a Swing Panel by paintComponent. Is there a particular reason for this? Actually, I expected the embedding of the OpenGL/DirectX context in other words the heavy weigth component of the entire JFX scene. In the current stage of the JFXPanel it's not even usable for very small addons, since the performance is soo damn bad ;) Maybe I missed another way to get JFX inserted into an existing Swing-Application? Any hints? regards Matthias
RE: JFXPanel vs. real world usage
Hi Matthias, I don't see any problems with performance and I've been using this a lot. Best regards, -- Pedro Duque Vieira
Re: JFXPanel vs. real world usage
I have the same experience. We're using this and it works ok as far as performance. -Original Message- From: Pedro Duque Vieira pedro.duquevie...@gmail.com Sender: openjfx-dev-boun...@openjdk.java.net Date: Thu, 24 Oct 2013 18:20:42 To: OpenJFX Mailing Listopenjfx-dev@openjdk.java.net Subject: RE: JFXPanel vs. real world usage Hi Matthias, I don't see any problems with performance and I've been using this a lot. Best regards, -- Pedro Duque Vieira
Re: CFV: New OpenJFX Committer: Oleg Barbashov
Vote: YES -- Jonathan On 25/10/2013 1:58 a.m., Artem Ananiev wrote: I hereby nominate Oleg Barbashov (OpenJDK user name: ogb) to OpenJFX Committer. Oleg is a member of JavaFX SQE team at Oracle. He is currently an Author in OpenJFX and is an active contributor to this project, about 30 changesets in the tests repository: http://hg.openjdk.java.net/openjfx/8/master Votes are due by Nov 07, 2013. Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Nomination to a project Committer is described in [3]. [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus [3] http://openjdk.java.net/projects#project-committer Thanks, Artem
Re: JFXPanel vs. real world usage
On Thu, 24 Oct 2013 19:20:42 +0200, Pedro Duque Vieira pedro.duquevie...@gmail.com wrote: Hi Matthias, I don't see any problems with performance and I've been using this a lot. Best regards, +1 for me. Of course, it depends a lot on the usage and unfortunately I can't comment further because my experience is from a closed-source project of a customer. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: JFXPanel vs. real world usage
I added a simple accordion as JFXPanel into a swing frame and the performance is not good. the cpu usage goes up to 100% when moving the mouse over the accordion title panes (hover effect). The resizing performance is bad too. Am 24.10.2013 um 20:10 schrieb rdarr...@yahoo.com: I have the same experience. We're using this and it works ok as far as performance. -Original Message- From: Pedro Duque Vieira pedro.duquevie...@gmail.com Sender: openjfx-dev-boun...@openjdk.java.net Date: Thu, 24 Oct 2013 18:20:42 To: OpenJFX Mailing Listopenjfx-dev@openjdk.java.net Subject: RE: JFXPanel vs. real world usage Hi Matthias, I don't see any problems with performance and I've been using this a lot. Best regards, -- Pedro Duque Vieira
hg: openjfx/8/graphics/rt: RT-14187: Support glyph rasterisation to sub-pixel precision
Changeset: c0c85cc23907 Author:Felipe Heidrich felipe.heidr...@oracle.com Date: 2013-10-24 11:38 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c0c85cc23907 RT-14187: Support glyph rasterisation to sub-pixel precision Reviewed-by: Phil Race ! modules/graphics/src/main/java/com/sun/javafx/font/CompositeStrike.java ! modules/graphics/src/main/java/com/sun/javafx/font/FontStrike.java ! modules/graphics/src/main/java/com/sun/javafx/font/Glyph.java ! modules/graphics/src/main/java/com/sun/javafx/font/PrismFontFactory.java ! modules/graphics/src/main/java/com/sun/javafx/font/PrismFontStrike.java ! modules/graphics/src/main/java/com/sun/javafx/font/coretext/CTFontStrike.java ! modules/graphics/src/main/java/com/sun/javafx/font/coretext/CTGlyph.java ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/DWFontStrike.java ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java ! modules/graphics/src/main/java/com/sun/javafx/font/pango/FTFontStrike.java ! modules/graphics/src/main/java/com/sun/javafx/font/pango/FTGlyph.java ! modules/graphics/src/main/java/com/sun/prism/impl/GlyphCache.java ! modules/graphics/src/main/java/com/sun/prism/impl/ps/BaseShaderGraphics.java ! modules/graphics/src/main/java/com/sun/prism/sw/SWGraphics.java
Re: JFXPanel vs. real world usage
Please enter a JIRA with your sample code attached. Steve On 2013-10-24 2:37 PM, Tobias Bley wrote: I added a simple accordion as JFXPanel into a swing frame and the performance is not good. the cpu usage goes up to 100% when moving the mouse over the accordion title panes (hover effect). The resizing performance is bad too. Am 24.10.2013 um 20:10 schrieb rdarr...@yahoo.com: I have the same experience. We're using this and it works ok as far as performance. -Original Message- From: Pedro Duque Vieira pedro.duquevie...@gmail.com Sender: openjfx-dev-boun...@openjdk.java.net Date: Thu, 24 Oct 2013 18:20:42 To: OpenJFX Mailing Listopenjfx-dev@openjdk.java.net Subject: RE: JFXPanel vs. real world usage Hi Matthias, I don't see any problems with performance and I've been using this a lot. Best regards, -- Pedro Duque Vieira
Re: JFXPanel vs. real world usage
There are maybe some components or use cases where the performance is not ok, but for our use cases, we also don't have any problem. Hervé Sent from my iPhone On 24 oct. 2013, at 20:10, rdarr...@yahoo.com wrote: I have the same experience. We're using this and it works ok as far as performance. -Original Message- From: Pedro Duque Vieira pedro.duquevie...@gmail.com Sender: openjfx-dev-boun...@openjdk.java.net Date: Thu, 24 Oct 2013 18:20:42 To: OpenJFX Mailing Listopenjfx-dev@openjdk.java.net Subject: RE: JFXPanel vs. real world usage Hi Matthias, I don't see any problems with performance and I've been using this a lot. Best regards, -- Pedro Duque Vieira
Re: JFXPanel vs. real world usage
My experience has been okay, though I've seen the resizing lag. The only real problem I've seen is bad performance on a retina display Mac Book Pro. jeff On Oct 24, 2013, at 1:37 PM, Tobias Bley t...@ultramixer.com wrote: I added a simple accordion as JFXPanel into a swing frame and the performance is not good. the cpu usage goes up to 100% when moving the mouse over the accordion title panes (hover effect). The resizing performance is bad too. Am 24.10.2013 um 20:10 schrieb rdarr...@yahoo.com: I have the same experience. We're using this and it works ok as far as performance. -Original Message- From: Pedro Duque Vieira pedro.duquevie...@gmail.com Sender: openjfx-dev-boun...@openjdk.java.net Date: Thu, 24 Oct 2013 18:20:42 To: OpenJFX Mailing Listopenjfx-dev@openjdk.java.net Subject: RE: JFXPanel vs. real world usage Hi Matthias, I don't see any problems with performance and I've been using this a lot. Best regards, -- Pedro Duque Vieira
hg: openjfx/8/graphics/rt: RT-33620: TextField should not shrink vertically by default
Changeset: 659cc7864404 Author:leifs Date: 2013-10-24 12:33 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/659cc7864404 RT-33620: TextField should not shrink vertically by default Reviewed-by: jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TextFieldSkin.java
hg: openjfx/8/graphics/rt: RT-33071: Gradle: command line override sometimes ignored for boolean properties
Changeset: 86c40357ada4 Author:kcr Date: 2013-10-24 15:51 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/86c40357ada4 RT-33071: Gradle: command line override sometimes ignored for boolean properties Reviewed-by: felipe ! build.gradle ! buildSrc/android.gradle ! buildSrc/armv6hf.gradle ! buildSrc/armv6sf.gradle ! buildSrc/ios.gradle ! buildSrc/linux.gradle ! buildSrc/mac.gradle ! buildSrc/win.gradle
hg: openjfx/8/graphics/rt: 2 new changesets
Changeset: 405182d0e3c4 Author:kcr Date: 2013-10-24 16:41 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/405182d0e3c4 Partial RT-31560: javafx-font-pango should be built by default [NOTE: still disabled] Reviewed-by: felipe ! build.gradle ! buildSrc/armv6hf.gradle ! buildSrc/armv6sf.gradle ! buildSrc/linux.gradle ! modules/graphics/src/main/java/com/sun/javafx/font/pango/OS.java Changeset: 2c8c59c8f66d Author:Felipe Heidrich felipe.heidr...@oracle.com Date: 2013-10-24 16:44 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2c8c59c8f66d RT-32873: Improve performance for text calculations in skin.Utils ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/Utils.java
JavaFX Builders, possible solution
I briefly discussed the builder deprecation with Richard when he visited our company back in May. One of the ways he said to test any solution would be to build a library jar with the test hierarchy, then build a client jar using the library jar, then change the hierarchy in the library code and run the client jar against the new library jar without re-compiling the client jar. I have done that, and it works in my simple test: BuilderLibA - is the original builder library (my version) BuilderClient - is the client app (main class is com.cpex.javafx.test.BuilderClientTest), built against the BuilderLibA.jar. BuilderLibB - I have inserted a new class in the hierarchy between RegionBuilderBase and ParentBuilderBase. I had tested the solution in both JDK 7 and JDK 8, a few months back, and then forgot about it as several other things came up. All of the code has been uploaded to DropBox: https://www.dropbox.com/sh/fs8o105bvmr4s2k/ze-hJssiHC If there is something else that I'm missing in this issue let me know...I really hate to see builders go away. --Andy This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.
hg: openjfx/8/graphics/rt: 2 new changesets
Changeset: 24e60f5070be Author:jgiles Date: 2013-10-25 10:38 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/24e60f5070be RT-28132: [TableView] Focus in editing cell. Reviewed-by: psomashe ! modules/controls/src/main/java/javafx/scene/control/cell/CellUtils.java Changeset: 0a99458da1dd Author:jgiles Date: 2013-10-25 11:44 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0a99458da1dd RT-2944: Modena: Tab focus is messed up on Windows Reviewed-by: psomashe ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TabPaneSkin.java
