[11] Review Request - JDK-8196615: Skip 3D unit tests on system without 3D capability
Hi Kevin,Murali, Please review this fix for skipping 3D tests on systems with missing hardware support. JBS : https://bugs.openjdk.java.net/browse/JDK-8196615 WebRev : http://cr.openjdk.java.net/~rkamath/8196615/webrev.00/ Thanks, Rajath
Re: More community participation in JavaFX
I think Kevin outlined in his opening post what would be considered "out of scope". However, I agree with you on the basic premise that, in general, the bar has been set way too low as to the potential use cases and performance of JavaFX. In fact, I firmly believe that games & complex visualisations etc. *should* be possible with JavaFX given that most of the heavy lifting is being done by the GPU. It's just that, at the moment, the scene graph rendering pipeline is significantly slower than it could be and it is for this reason that we don't find applications using advanced 3D graphics & animations etc. (like we see in games) being built with JavaFX. It's just not possible when the node count reaches even a very small threshold. This is a topic I have tried to discuss numerous times and also believe that I can improve the performance of the scene graph rendering in a very tangible way. If things pan-out as they are being described and becoming & being a contributor is simplified to the extent where it justifies me devoting a large chunk of my time to OpenJFX, this is probably what I would want to work on first. Graciously, John-Val Rose On 3 February 2018 at 14:07, Stephen Desofi wrote: > I don’t understand why discussing new graphics capabilities such as gaming > or WebGPU, etc is so off limits. Can you explain that? > > Steve Desofi > > Sent from my iPhone > > > On Feb 2, 2018, at 8:51 PM, Kevin Rushforth > wrote: > > > > Looks like we have some good discussion so far. > > > > I see a few themes emerging (build/test, sandbox on GitHub, ease of > filing bugs, etc) along with some discussion on graphics performance (which > is fine as long as the discussion doesn't veer too far into discussing > specific graphics features). > > > > I'll let more folks chime in before I reply to anything specifically > (and I'll be offline over the weekend anyway). > > > > Thanks! > > > > -- Kevin > > >
Re: More community participation in JavaFX
I don’t understand why discussing new graphics capabilities such as gaming or WebGPU, etc is so off limits. Can you explain that? Steve Desofi Sent from my iPhone > On Feb 2, 2018, at 8:51 PM, Kevin Rushforth > wrote: > > Looks like we have some good discussion so far. > > I see a few themes emerging (build/test, sandbox on GitHub, ease of filing > bugs, etc) along with some discussion on graphics performance (which is fine > as long as the discussion doesn't veer too far into discussing specific > graphics features). > > I'll let more folks chime in before I reply to anything specifically (and > I'll be offline over the weekend anyway). > > Thanks! > > -- Kevin >
Re: More community participation in JavaFX
Looks like we have some good discussion so far. I see a few themes emerging (build/test, sandbox on GitHub, ease of filing bugs, etc) along with some discussion on graphics performance (which is fine as long as the discussion doesn't veer too far into discussing specific graphics features). I'll let more folks chime in before I reply to anything specifically (and I'll be offline over the weekend anyway). Thanks! -- Kevin
Re: More community participation in JavaFX
+1 It is not only games that would benefit from better graphics support, but also other areas such as CAD/CAM or architectural drawing which is less spoken about but is also an important part of the graphics world as well. With Apple pushing for WebGPU and working with the W3C to make it a Web Standard and Khronos pushing Vulkan, I see no reason Java FX should by intention become a laggard. Years ago Apple proposed the Canvas API and made it a Web standard and JavaFX adopted it. The FX Canvas and Web Canvas API’s are nearly identical. I see no reason why we can’t follow suit and once again and make FX a great WebGPU platform. Apple is doing all the heavy lifting, why shouldn't FX follow? Where else should JavaFX go? With new languages on the horizon like Dart, Swift, and TypScript, Java is getting competition and if we don’t keep up we will slowly become irrelevant. Over the years Java has gotten new Java language features, but it is falling behind in it's graphics support. In the end it is not the syntax of the language that matters most, it is what you can do with the language that matters. Just look at JavaScript for proof. It is a horrendous language but it's capabilities keep increasing and so does it's usage. Soon browsers will have heavy graphics capabilities, and Swift will be everywhere. Dart is making serious inroads (in capability, not in usage). Why would a new programmer pick JavaFX as a starting point? Rather than starting off by declaring "Java is not for Games" we should instead aim to say "anything you can do with Swift, we can be done with FX, and even better!". Apple's WebGPU will become a winner. They are using the same winning formula they used the last time with Canvas. Just release it as a standard and declare "WE ARE APPLE". They are more powerful a company today than they were back then, so of course they will succeed. Will they be the only standard? Maybe not. The Web has SVG and Canvas. In the 3D world it will have WebGPU and maybe Vulkan, although there are serious reasons to question Vulkan's success. SVG and Canvas are really two different technologies. WebGPU and Vulkan are just two different API's to the same technology. I'll bet on Apple. They have already made it a W3C working group, and the world doesn't need two different API's to the same technology. Apple will win. I have limited time for projects, and I also have a day job. At night I am doing a lot of graphics work using both Web Canvas and JavaFX Canvas. Soon I will have to make a decision. Will it be Web Graphics plus Java or Web Graphics plus Swift. Swift is getting a clearer roadmap. JavaFX is declaring itself out of the game. (no pun intended) I have not contributed time to the FX platform, but would love to, but I have to be assured that JavaFX has a future. If I feel this way, how many others feel the same way as I do? You mentioned planning for the next 10 years. What will JavaFX look like in 10 years without serious graphics support? Without it, I don't think JavaFX will exist. Other platforms will have past us by. Steve Desofi Sent from iCloud On Feb 02, 2018, at 05:15 AM, Paul Ray Russell wrote: Yeah - I looked at the windows build process recently - which was enough to dissuade me from starting. I do know JavaFX fairly well, and have a potted history working in software companies. I'd like to get on-board once I finish my current game. I'd be interested in game related areas; but realise these may not be areas of development that JavaFX was ever intended, or *will* ever be directed to cover. That would be another whole conversation to have. If it's the case that JavaFX is to remain a GUI toolkit, with v. limited graphics abilities: something useful for front-ending business apps, but not much more, then it needs to be made clearer that this is the aim. The games community has grown despondent about JavaFX as a framework, which is a shame. I see evidence of this scattered all over the web. Too many abandoned projects from 2013 era. It's all bit depressing. It's such a great framework. On 2 February 2018 at 00:07, wrote: Send openjfx-dev mailing list submissions to openjfx-dev@openjdk.java.net To subscribe or unsubscribe via the World Wide Web, visit http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev or, via email, send a message with subject or body 'help' to openjfx-dev-requ...@openjdk.java.net You can reach the person managing the list at openjfx-dev-ow...@openjdk.java.net When replying, please edit your Subject line so it is more specific than "Re: Contents of openjfx-dev digest..." Today's Topics: 1. More community participation in JavaFX (Kevin Rushforth) 2. Re: More community participation in JavaFX (Michael Ennen) 3. Re: More community participation in JavaFX (Richard Steiger) -- Message: 1 Date
JavaFX embed API
Hi everyone, Since Java 9 makes com.sun.javafx.embed.* unavailable. Some people use this internal API to integrate javaFX as GUI into some OpenGL based games. This API is a great thing to integrate javaFX with any other graphics frameworks/engines, so do you have any plans to make this internal API as public?
Re: More community participation in JavaFX
Hi, I fully agree with what you said with one exception. Via the bug report form it is possible to add any kind of attachments. So this is no problem. The rest is sadly true. Cheers Michael Am 02.02.18 um 18:29 schrieb John Neffenger: On 02/01/2018 03:26 PM, Kevin Rushforth wrote: We are specifically looking to discuss ideas around the following areas: * Easing barriers to contribution (e.g., making JavaFX easier to build, better documentation, making it easier to test changes) Thank you for asking. In my case, the barrier was not being able to upload images to a bug report or even add a comment to my own report after creating it. The specific bugs don't matter. I'm concerned about the process, because I've always ended up contributing to projects by finding some bug and being motivated enough to fix it. Bugs are the hooks that get me involved. So I spent a couple of months porting JavaFX to an ARM E-Ink device and found three bugs in the process. I lost enthusiasm, though, when I realized I had to get these bug reports: https://gitlab.com/groups/openjfxepd/-/issues into here: https://bugreport.java.com/ One of the reports has five images that illustrate the problem, but I see no way to add those. Worse yet, once I submit the report, my participation ends, and there's no record that I was involved at all. In other systems, from GNOME to Mozilla to Ubuntu, I can open a bug report directly, upload images, and participate in the discussion until it's closed. Of course, I will eventually submit those bug reports if they're not already fixed, but it takes just enough extra emotional effort -- giving up credit, control, and participation -- that I haven't. John
Re: More community participation in JavaFX
On 02/01/2018 03:26 PM, Kevin Rushforth wrote: We are specifically looking to discuss ideas around the following areas: * Easing barriers to contribution (e.g., making JavaFX easier to build, better documentation, making it easier to test changes) Thank you for asking. In my case, the barrier was not being able to upload images to a bug report or even add a comment to my own report after creating it. The specific bugs don't matter. I'm concerned about the process, because I've always ended up contributing to projects by finding some bug and being motivated enough to fix it. Bugs are the hooks that get me involved. So I spent a couple of months porting JavaFX to an ARM E-Ink device and found three bugs in the process. I lost enthusiasm, though, when I realized I had to get these bug reports: https://gitlab.com/groups/openjfxepd/-/issues into here: https://bugreport.java.com/ One of the reports has five images that illustrate the problem, but I see no way to add those. Worse yet, once I submit the report, my participation ends, and there's no record that I was involved at all. In other systems, from GNOME to Mozilla to Ubuntu, I can open a bug report directly, upload images, and participate in the discussion until it's closed. Of course, I will eventually submit those bug reports if they're not already fixed, but it takes just enough extra emotional effort -- giving up credit, control, and participation -- that I haven't. John
Re: JDK-8196130: Eclipse configuration files need to be updated
Alright, got most of them ready. About buildSrc: - What is "rt\buildSrc\build\generated-src\antlr\com\sun\scenario\effect\compiler" supposed to be? It is listed as a source folder but it's empty. - The project lists dependencies such as "build/libs/swt-debug.jar", JUnit and a JRE/JDK, but doesn't need any of them (from Eclipse's point of view). I see the base module listing this project as a dependency, but it's not used. Where is it located in the dependency chain? On Thu, Feb 1, 2018 at 9:48 PM, Kevin Rushforth wrote: > It probably makes sense to submit what you have now as a partially working > solution. > > As for Eclipse making any changes, I'm not sure there is a spec you could > point to ... we do some of the same magic that I'm sure other projects have > had to do w.r.t running tests: > > * We have test "shims" for white-box testing that we add into our modules > when running tests (this requires copying all of the class files for our > modules and adding the shim classes on top of that) > > * We build the tests separately (the tests are in a separate source set in > gradle) without a module-info so that they run in the unnamed module. This > allows them to access JUnit, etc., as well as any public package of any > module in the system. As such we need to explicitly list any internal > packages that they use from the module they are testing. These are listed > in src/test/addExports > > > -- Kevin > > > Nir Lisker wrote: > > Looks like I understood the problem. Eclipse does not support (yet) > multiple modules per project. Do you know any specifications I can point > them to to fix this properly? > > The current workaround would be to add 'requires' for all the modules > which are used in tests as well. This change is local and would be excluded > from webrevs. > > At this point I can either submit the partially fixed Eclipse files, which > work with main code fully and with test code only if the above fix is used; > or wait until Eclipse sorts it out. > > On Wed, Jan 31, 2018 at 4:21 PM, Kevin Rushforth < > kevin.rushfo...@oracle.com> wrote: > >> >> >> Nir Lisker wrote: >> >> rt/modules/javafx.base/build/classes/main/javafx.base/ >>> rt/modules/javafx.base/src/main/java/ >> >> >> Why not rely on source first? >> >> >> Yes, that might work...you could try switching the order. >> >> >> >> Another question as I move along: there are imports >> from java.util.logging in base module, but the module-info doesn't >> require java.logging. How do I give access to these imports? >> >> >> The only references to java.util.logging are in the javafx.base unit >> tests, which are compiled and run in the unnamed modules (no >> module-info.java for the unit tests). >> >> -- Kevin >> >> >> >> On Tue, Jan 30, 2018 at 9:03 PM, Kevin Rushforth < >> kevin.rushfo...@oracle.com> wrote: >> >>> Oh, I see. You are pointing to the exploded modules for the JDK in >>> build/X/jdk rather than the JDK image in build/X/images/jdk. >>> >>> Yes, I think it would be preferable to both reverse the order and also >>> add in the location of the built class files. So the following order seems >>> best: >>> >>> rt/modules/javafx.base/build/classes/main/javafx.base/ >>> rt/modules/javafx.base/src/main/java/ >>> jdk/modules/javafx.base >>> >>> >>> -- Kevin >>> >>> >>> Nir Lisker wrote: >>> >>> This is what I mean: In the type /base/src/test/java/test/ >>> com/sun/javafx/collections/ListListenerHelperTest.java there are these >>> imports: >>> >>> import test.javafx.collections.MockListObserver; >>> import java.util.BitSet; >>> import javafx.beans.Observable; >>> >>> The first one is the one in FX: rt\modules\javafx.base\src >>> \test\java\test\javafx\collections\MockListObserver.java >>> The second one is in the referenced JDK which was built with >>> FX: jdk\modules\java.base\java\util\BitSet.class >>> The third one exists in both: >>> - in JFX it's in: rt\modules\javafx.base\src\mai >>> n\java\javafx\beans\Observable.java >>> - in the JDK it's in: jdk\modules\javafx.base\ja >>> vafx\beans\Observable.class >>> >>> Does the question make sense now? >>> >>> On Tue, Jan 30, 2018 at 5:04 AM, Kevin Rushforth < >>> kevin.rushfo...@oracle.com> wrote: >>> one in "rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java" or the one in "jdk\modules\javafx.base\javaf x\beans\InvalidationListener.class"? Not sure I get what you mean. There isn't a jdk/modules/ directory created by the build. Perhaps this is an Eclipse construct that it uses to indicate the modules that are in the JDK that you are using? The FX build puts the class files in: rt/build/modular_sdk/modules/javafx.base/... -- Kevin Nir Lisker wrote: Another question: do imports of javafx.* packages point to the javafx source or to the jdk compilation? For example, in the base module, the type test.javafx.beans.InvalidationListenerMoc
[11] Review request for 8196605: Robot tests fail on Windows platforms if terminal windows are in the way
Hi Kevin, Please review the below simple fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8196605 webrev: http://cr.openjdk.java.net/~mbilla/8196605/webrev.00/ Thanks, Murali
Re: More community participation in JavaFX
Hi Kevin, I'm more than happy to keep the community JavaFX build server at chriswhocodes.com running and host JDK 8/9/10/n + FX builds there. At the moment it's mostly used by the Raspberry Pi community to grab JavaFX overlays for JDK8 on ARM. I can also build and host OSX and Windows builds there once the build instructions are updated. Lastly I'd also be interested in profiling and contributing performance enhancements to the FX Java source code based on JIT analysis. IMO it would be useful if the OpenJFX team would make a statement on what kind of contributions fit with their overall vision (e.g. increasing performance vs bug fixing desktop widgets). Thanks, Chris On Thu, February 1, 2018 23:26, Kevin Rushforth wrote: To: OpenJFX Developers We are looking to grow the community of contributors to the OpenJFX project, especially serious contributors who will stick around long enough to become reviewers, to help us keep the platform vibrant. To this end we are looking at ways to encourage more participation and make it easier for interested folks to contribute. ...
Re: More community participation in JavaFX
Yeah - I looked at the windows build process recently - which was enough to dissuade me from starting. I do know JavaFX fairly well, and have a potted history working in software companies. I'd like to get on-board once I finish my current game. I'd be interested in game related areas; but realise these may not be areas of development that JavaFX was ever intended, or *will* ever be directed to cover. That would be another whole conversation to have. If it's the case that JavaFX is to remain a GUI toolkit, with v. limited graphics abilities: something useful for front-ending business apps, but not much more, then it needs to be made clearer that this is the aim. The games community has grown despondent about JavaFX as a framework, which is a shame. I see evidence of this scattered all over the web. Too many abandoned projects from 2013 era. It's all bit depressing. It's such a great framework. On 2 February 2018 at 00:07, wrote: > Send openjfx-dev mailing list submissions to > openjfx-dev@openjdk.java.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev > or, via email, send a message with subject or body 'help' to > openjfx-dev-requ...@openjdk.java.net > > You can reach the person managing the list at > openjfx-dev-ow...@openjdk.java.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openjfx-dev digest..." > > > Today's Topics: > >1. More community participation in JavaFX (Kevin Rushforth) >2. Re: More community participation in JavaFX (Michael Ennen) >3. Re: More community participation in JavaFX (Richard Steiger) > > > -- > > Message: 1 > Date: Thu, 01 Feb 2018 15:26:24 -0800 > From: Kevin Rushforth > To: "openjfx-dev@openjdk.java.net" > Subject: More community participation in JavaFX > Message-ID: <5a73a220.7030...@oracle.com> > Content-Type: text/plain; charset=windows-1252; format=flowed > > To: OpenJFX Developers > > We are looking to grow the community of contributors to the OpenJFX > project, especially serious contributors who will stick around long > enough to become reviewers, to help us keep the platform vibrant. To > this end we are looking at ways to encourage more participation and make > it easier for interested folks to contribute. > > We are specifically looking to discuss ideas around the following areas: > > * Easing barriers to contribution (e.g., making JavaFX easier to build, > better documentation, making it easier to test changes) > > * Code review policies > > * API / feature review policies > > * Code review tools (we currently use webrev, but that isn't set in stone) > > > To keep this thread productive, the following are explicitly out of scope: > > * Discussion of specific features or bugs that you would like to > implement (or wish someone else would) > > * Discussion about platform support > > * Discussion about version control systems (e.g., hg versus git), > hosting of the OpenJFX repos and bug database (e.g., OpenJDK versus > github), etc...at least for now. We are aware of the potential benefits > of such changes, but we'd like to focus our efforts on higher-leverage > things we can do in the short term. > > * Discussion about the requirement of a signed OCA to become a contributor > > * Off-topic or tangential commentary about OpenJFX that isn't directly > related to the topic at hand > > > As a starting point for discussion, here are some areas I think need > improvement; I'm sure there are others: > > I. Helping contributors get started > > It isn?t as easy to get started with OpenJFX as it should be. We want to > make it easier for potential OpenJFX contributors to get started. Here > are some ideas that I think might help: > > * Improve the build instructions / Wiki (I made a first start, but there > is much more to be done) > > * Make the build itself more resilient where possible, and provide > better error messages, specifically when dealing with native compilers > and libraries > > * Add an option to skip building all native code and use prebuilt > binaries (like we do already for media and webkit); this is tracked by > JDK-8092279, but it hasn?t been looked at recently > > * Make it easier to build / test your local OpenJFX build using an > OpenJDK build (currently the only way to do this is to build OpenJDK > locally, after using configure to point to your just-built javafx.* > modules). > > * Provide step-by-step instructions for how to make a contribution, > including testing requirements; a lot of the pieces are there, but are > out of date or scattered in several places. As part of this, we could > have a section on how to contribute docs, samples or tests, since that > is often a good place to start. > > * Provide a sandbox environment where contributors can discuss and test > ideas. For example, an OpenJFX mirror on
Re: More community participation in JavaFX
Kevin - thanks so much for this extremely well thought-out, informative and positive email. It’s the best post I’ve ever seen from Oracle on this list! It clearly highlights 2 things: 1. The future of JavaFX is heavily reliant on community involvement. 2. Oracle are actually listening to community concerns and are actively trying to address the main issues raised. I’ve never doubted the enthusiasm or expertise of the “small” Oracle JavaFX team and I’m sure if Larry came downstairs and said “Hey Kevin, would you like another 50 devs on your team?”, your answer would probably be “Sure, but 100 would be even better!”. But, we know you must work within the resourcing and financial constraints that prevail. So, I for one have been very keen to contribute to OpenJFX, have suggested several innovative features and have tried to devote at least some of my own very limited time to achieving this, only to be met with a few major barricades. It has been noted that the most fundamental aspect of development (i.e. building the project from source) is currently a significant challenge on all platforms and having to attempt to decipher errors and get the builds to work reliably is in itself enough to put off many potential contributors (perhaps permanently). So, I’m very pleased to see that this issue has been prioritised - thank you. Another barricade is the complexity of the formal process of making contributions and the extensive “red tape” which I see you are also addressing. I’m willing to bet that once the community can build OpenJFX on any platform reliably, quickly and in a repeatable manner, a large increase in the number of people who actually *do* contribute will follow. It is well known that one of the real strengths of JavaFX is the vibrant and passionate community. These proposals give us all a much better chance to become tangible contributors and for JavaFX to not just continue to “exist” but for real innovation and progress to occur. It’s somewhat ironic that I have been discussing setting up and maintaining a mirror build with some devs privately which could act as a sandbox or incubation platform so I’m very pleased to know that the large amount of effort that would have entailed is mostly going to be addressed through these proposals. These are now exciting times for JavaFX! I foresee the fusion of Oracle expertise and stewardship with community passion and skills and the great result for everyone being a living, breathing and thriving OpenJFX :-) Thanks again for putting the time and effort into these awesome proposals and I hope that many “lurkers” will step up and together we can build something of tremendous quality, utility and value! Graciously, John-Val Rose > On 2 Feb 2018, at 11:03, Richard Steiger wrote: > > Hi Kevin, > > As a long-time observer of the OpenJFX project, let me put all my chips at > this point on making builds more stable, bullet-proof, and automated, and > give equal weight making them so on Win10 and OS/X, specifically, the same > weight as is given to making building and developing on Linux work well. > > Over the last 3 or so years, on at least 3 separate occasions, I've gotten a > head of inspirational steam to try-out some new features (the latest being > using byte-code engineering to radically streamline binding, rendering most > of the current API obsolete, and hugely improving performance). I then > attempt to build the whole project from sources (not always required, but > essential when it is) on Win10, my development platform of choice, and > invariably get wound around the axel of no-longer published VS tooling, > missing binaries, and other show-stopper glitches. > > Like many potential contributors, I've got a day job, plus am trying to > launch a garage startup, so my time is a very scarce resource. I simply > don't have the extra cycles to troubleshoot highly convoluted builds (of > which OpenJFX is one of the worst I've seen), so my head of steam bleeds-off > for another year or so. Nor am I willing to switch to a Linux development > environment, remap my motor memory, take-on care and feeding of another > platform (Windows and OS/X suck enough time, and are essential for my > business). Every time I've hit this wall, I've puzzled over how the team has > tolerated the situation, and moved on. > > So, to be redundant, all the other issues you've so cogently enumerated pale > in the face of development portability, starting with build stability and > cleanliness on widely-used platforms. > > Thanks for considering the above input. > > -rjs > > >> On 2/1/18 3:26 PM, Kevin Rushforth wrote: >> To: OpenJFX Developers >> >> We are looking to grow the community of contributors to the OpenJFX project, >> especially serious contributors who will stick around long enough to become >> reviewers, to help us keep the platform vibrant. To this end we are looking >> at ways to encourage more pa