hg: openjfx/8/graphics/rt: iOS build: fixed due to RT-31035 remove hyphens from library names
Changeset: 7282123d73a1 Author:David Pulkrabek david.pulkra...@oracle.com Date: 2013-07-18 10:04 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7282123d73a1 iOS build: fixed due to RT-31035 remove hyphens from library names ! buildSrc/ios.gradle
Re: Books and documents about JavaFX 8
Another place to find JavaFX blog posts is the JavaFX Community site [1] [1] http://javafxcommunity.com Regards, Jim Weaver On 7/18/13 7:08 AM, Neil Galarneau wrote: Hi Peter, I find _Pro JavaFX 2_ from Apress to be helpful. There are also guides on Oracle's website. There are also bloggers blogging about JavaFX. Many of them are linked to from fxexperience.com which also has its own JavaFX articles. Neil On Jul 17, 2013, at 2:07 PM, Peter Penzov peter.pen...@gmail.com wrote: Hi, I'm looking for books or document about JavaFX 8. Can you recommend me some material about advanced topics how to work with JavaFX 8 if there is any. I use javadoc but I some cases it's not enough. Best wishes, Peter -- Regards, Jim Weaver Java Technology Ambassador Oracle Corporation james.wea...@oracle.com
Re: JavaFX 8 Progress
On 7/18/2013 3:00 AM, David Ray wrote: Hi Richard, I don't see any mention of WebStart and JavaFX on the milestone list - are issues surrounding (and suffocating :)) WebStart going to addressed as part of the JDK release 8 instead? Java Plugin and Java Web Start are not parts of JavaFX (although JavaFX provides some APIs for them), they are shared between JDK and JavaFX and released as a part of Oracle JDK8 (not included to OpenJDK). Thanks, Artem David Sent from my iPhone On Jul 17, 2013, at 12:06 PM, Richard Bair richard.b...@oracle.com wrote: Hi Peter, Our dates match up with JDK 8: http://openjdk.java.net/projects/jdk8/milestones Feature complete was a month ago (but little API tweaks continue to happen). Things are supposed to be reasonably stable by October 24 (Zero Bug Bounce http://openjdk.java.net/projects/jdk8/milestones#Zero_Bug_Bounce) and GA in March. Richard On Jul 17, 2013, at 9:52 AM, Peter Penzov peter.pen...@gmail.com wrote: Hi, I'm new to JavaFX I'm interested what is the current progress of development of JavaFX 8. I want to use it for base framework for my enterprise application but I have concerns is it stable to be used? Can you give me some information do you plan to add something else before the official release? Best wishes, Peter
Re: Books and documents about JavaFX 8
+1 on Jims answer… Gerrit Am 18.07.2013 um 13:47 schrieb Jim Weaver james.wea...@oracle.com: Another place to find JavaFX blog posts is the JavaFX Community site [1] [1] http://javafxcommunity.com Regards, Jim Weaver On 7/18/13 7:08 AM, Neil Galarneau wrote: Hi Peter, I find _Pro JavaFX 2_ from Apress to be helpful. There are also guides on Oracle's website. There are also bloggers blogging about JavaFX. Many of them are linked to from fxexperience.com which also has its own JavaFX articles. Neil On Jul 17, 2013, at 2:07 PM, Peter Penzov peter.pen...@gmail.com wrote: Hi, I'm looking for books or document about JavaFX 8. Can you recommend me some material about advanced topics how to work with JavaFX 8 if there is any. I use javadoc but I some cases it's not enough. Best wishes, Peter -- Regards, Jim Weaver Java Technology Ambassador Oracle Corporation james.wea...@oracle.com
Font size in JavaFX 8
Hi, I tested to run code developed on JavaFX 2.2. On JavaFX 8 the size of the Font cannot be set properly with setStyle(-fx-font-size: 12pt;). I suppose that this is caused by the JavaFX 8 code change. Is this going to be fixed into the near future? Best wishes
Re: Font size in JavaFX 8
Which build? Yesterday I filed https://javafx-jira.kenai.com/browse/RT-31745 On Jul 18, 2013, at 9:39 AM, Peter Penzov peter.pen...@gmail.com wrote: Hi, I tested to run code developed on JavaFX 2.2. On JavaFX 8 the size of the Font cannot be set properly with setStyle(-fx-font-size: 12pt;). I suppose that this is caused by the JavaFX 8 code change. Is this going to be fixed into the near future? Best wishes
Re: JavaFX 8 Progress
Sure, but no one other than the JFX team are (or will be) working on these right? They are effectively desktop technologies and no other team has any interest in them I'm guessing? I'd assume if they're not on the JFX roadmap, they're not on the Java roadmap? On Thu, Jul 18, 2013 at 9:48 PM, Artem Ananiev artem.anan...@oracle.comwrote: On 7/18/2013 3:00 AM, David Ray wrote: Hi Richard, I don't see any mention of WebStart and JavaFX on the milestone list - are issues surrounding (and suffocating :)) WebStart going to addressed as part of the JDK release 8 instead? Java Plugin and Java Web Start are not parts of JavaFX (although JavaFX provides some APIs for them), they are shared between JDK and JavaFX and released as a part of Oracle JDK8 (not included to OpenJDK). Thanks, Artem David Sent from my iPhone On Jul 17, 2013, at 12:06 PM, Richard Bair richard.b...@oracle.com wrote: Hi Peter, Our dates match up with JDK 8: http://openjdk.java.net/** projects/jdk8/milestoneshttp://openjdk.java.net/projects/jdk8/milestones Feature complete was a month ago (but little API tweaks continue to happen). Things are supposed to be reasonably stable by October 24 (Zero Bug Bounce http://openjdk.java.net/**projects/jdk8/milestones#Zero_** Bug_Bouncehttp://openjdk.java.net/projects/jdk8/milestones#Zero_Bug_Bounce) and GA in March. Richard On Jul 17, 2013, at 9:52 AM, Peter Penzov peter.pen...@gmail.com wrote: Hi, I'm new to JavaFX I'm interested what is the current progress of development of JavaFX 8. I want to use it for base framework for my enterprise application but I have concerns is it stable to be used? Can you give me some information do you plan to add something else before the official release? Best wishes, Peter
Re: JavaFX 8 Progress
I don't want to open up the webstart can of worms here, but we have multiple issues surrounding recognition and validity of signed jars when using certain VMARGS in combination with OSGi style deployment. We finally settled on JWrapper due to WebStarts apparent brittleness - but as you say, this is neither here nor there as far as JavaFX is concerned… Anyway, thanks for getting back to us on the deployment tools organization… David On Jul 18, 2013, at 9:22 AM, Joe McGlynn joe.mcgl...@oracle.com wrote: No, the deployment team works on these, not the FX team. It's the same bits for FX and Swing/AWT when running browser-deployed apps (which includes applets and web start). Deployment, FX and Swing are all part of the Java client org. There are a number of bug fixed being worked in this area, as well as new requirements around how to deploy a secure applet or web start app. The deploy code base is currently identical between 7u and JDK 8. If you are working with deploy technologies you should know this area is rapidly changing and I'd strongly advise staying on the latest release (currently 7u40 EA) and following the updates to the docs, especially around best practices for deployment. In short, these are: Buy a code signing certificate from a recognized CA and sign your app Use the new permissions and codebase JAR manifest attributes I'd recommend avoiding the use of mixed code if at all possible as that results in additional warning prompts to the end user and additional runtime risks. I'd also recommend testing your app with the security slider at the Very High level with every update of the JRE. Typically new restrictions are introduced first at Very High, and then propagated down into High and ultimately Medium over time. If there are problems using deployment with FX, of course report the issue and the team will investigate. I'm aware of one problem that causes some FX web start apps not to work with the latest release. It's being investigated right now. On Jul 18, 2013, at 6:40 AM, Daniel Zwolenski zon...@gmail.com wrote: Sure, but no one other than the JFX team are (or will be) working on these right? They are effectively desktop technologies and no other team has any interest in them I'm guessing? I'd assume if they're not on the JFX roadmap, they're not on the Java roadmap? On Thu, Jul 18, 2013 at 9:48 PM, Artem Ananiev artem.anan...@oracle.comwrote: On 7/18/2013 3:00 AM, David Ray wrote: Hi Richard, I don't see any mention of WebStart and JavaFX on the milestone list - are issues surrounding (and suffocating :)) WebStart going to addressed as part of the JDK release 8 instead? Java Plugin and Java Web Start are not parts of JavaFX (although JavaFX provides some APIs for them), they are shared between JDK and JavaFX and released as a part of Oracle JDK8 (not included to OpenJDK). Thanks, Artem David Sent from my iPhone On Jul 17, 2013, at 12:06 PM, Richard Bair richard.b...@oracle.com wrote: Hi Peter, Our dates match up with JDK 8: http://openjdk.java.net/** projects/jdk8/milestoneshttp://openjdk.java.net/projects/jdk8/milestones Feature complete was a month ago (but little API tweaks continue to happen). Things are supposed to be reasonably stable by October 24 (Zero Bug Bounce http://openjdk.java.net/**projects/jdk8/milestones#Zero_** Bug_Bouncehttp://openjdk.java.net/projects/jdk8/milestones#Zero_Bug_Bounce) and GA in March. Richard On Jul 17, 2013, at 9:52 AM, Peter Penzov peter.pen...@gmail.com wrote: Hi, I'm new to JavaFX I'm interested what is the current progress of development of JavaFX 8. I want to use it for base framework for my enterprise application but I have concerns is it stable to be used? Can you give me some information do you plan to add something else before the official release? Best wishes, Peter
hg: openjfx/8/graphics/rt: disable missing symbol warnings in egl
Changeset: ab8e75844575 Author:ddhill Date: 2013-07-18 12:38 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ab8e75844575 disable missing symbol warnings in egl ! modules/graphics/src/main/native-prism-es2/eglfb/eglUtils.c
hg: openjfx/8/graphics/rt: 2 new changesets
Changeset: 16a266d9f6fc Author:Martin Sladecek martin.slade...@oracle.com Date: 2013-07-18 16:01 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/16a266d9f6fc RT-29544 Use only nanosecond timer in AbstractMasterTimer ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/MasterTimer.java ! modules/graphics/src/main/java/com/sun/scenario/animation/AbstractMasterTimer.java ! modules/graphics/src/stub/java/com/sun/javafx/pgstub/StubMasterTimer.java ! modules/graphics/src/stub/java/javafx/animation/AbstractMasterTimerMock.java ! modules/graphics/src/test/java/com/sun/scenario/animation/AbstractMasterTimerMock.java Changeset: 9209dfabb60a Author:Martin Sladecek martin.slade...@oracle.com Date: 2013-07-18 16:02 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/9209dfabb60a Automated merge with file:///home/martin/Work/JavaFx/jfx-80-sync/rt
Re: JavaFX 8 Progress
By 'deployment team' you mean Mark Howe, etc? There's no other team working on anything to do with deployment right? On 19/07/2013, at 12:22 AM, Joe McGlynn joe.mcgl...@oracle.com wrote: No, the deployment team works on these, not the FX team. It's the same bits for FX and Swing/AWT when running browser-deployed apps (which includes applets and web start). Deployment, FX and Swing are all part of the Java client org. There are a number of bug fixed being worked in this area, as well as new requirements around how to deploy a secure applet or web start app. The deploy code base is currently identical between 7u and JDK 8. If you are working with deploy technologies you should know this area is rapidly changing and I'd strongly advise staying on the latest release (currently 7u40 EA) and following the updates to the docs, especially around best practices for deployment. In short, these are: Buy a code signing certificate from a recognized CA and sign your app Use the new permissions and codebase JAR manifest attributes I'd recommend avoiding the use of mixed code if at all possible as that results in additional warning prompts to the end user and additional runtime risks. I'd also recommend testing your app with the security slider at the Very High level with every update of the JRE. Typically new restrictions are introduced first at Very High, and then propagated down into High and ultimately Medium over time. If there are problems using deployment with FX, of course report the issue and the team will investigate. I'm aware of one problem that causes some FX web start apps not to work with the latest release. It's being investigated right now. On Jul 18, 2013, at 6:40 AM, Daniel Zwolenski zon...@gmail.com wrote: Sure, but no one other than the JFX team are (or will be) working on these right? They are effectively desktop technologies and no other team has any interest in them I'm guessing? I'd assume if they're not on the JFX roadmap, they're not on the Java roadmap? On Thu, Jul 18, 2013 at 9:48 PM, Artem Ananiev artem.anan...@oracle.comwrote: On 7/18/2013 3:00 AM, David Ray wrote: Hi Richard, I don't see any mention of WebStart and JavaFX on the milestone list - are issues surrounding (and suffocating :)) WebStart going to addressed as part of the JDK release 8 instead? Java Plugin and Java Web Start are not parts of JavaFX (although JavaFX provides some APIs for them), they are shared between JDK and JavaFX and released as a part of Oracle JDK8 (not included to OpenJDK). Thanks, Artem David Sent from my iPhone On Jul 17, 2013, at 12:06 PM, Richard Bair richard.b...@oracle.com wrote: Hi Peter, Our dates match up with JDK 8: http://openjdk.java.net/** projects/jdk8/milestoneshttp://openjdk.java.net/projects/jdk8/milestones Feature complete was a month ago (but little API tweaks continue to happen). Things are supposed to be reasonably stable by October 24 (Zero Bug Bounce http://openjdk.java.net/**projects/jdk8/milestones#Zero_** Bug_Bouncehttp://openjdk.java.net/projects/jdk8/milestones#Zero_Bug_Bounce) and GA in March. Richard On Jul 17, 2013, at 9:52 AM, Peter Penzov peter.pen...@gmail.com wrote: Hi, I'm new to JavaFX I'm interested what is the current progress of development of JavaFX 8. I want to use it for base framework for my enterprise application but I have concerns is it stable to be used? Can you give me some information do you plan to add something else before the official release? Best wishes, Peter
hg: openjfx/8/graphics/rt: Fixed Circle3D test
Changeset: 5431d508a39c Author:rbair Date: 2013-07-18 13:04 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5431d508a39c Fixed Circle3D test ! apps/toys/Shape3DToy/src/main/java/shapet3dtest/CircleT3D.java
Mixing 2D and 3D
While working on RT-5534, we found a large number of odd cases when mixing 2D and 3D. Some of these we talked about previously, some either we hadn't or, at least, they hadn't occurred to me. With 8 we are defining a lot of new API for 3D, and we need to make sure that we've very clearly defined how 2D and 3D nodes interact with each other, or developers will run into problems frequently and fire off angry emails about it :-) Fundamentally, 2D and 3D rendering are completely different. There are differences in how opacity is understood and applied. 2D graphics frequently use clips, whereas 3D does not (other than clipping the view frustum or other such environmental clipping). 2D uses things like filter effects (drop shadow, etc) that is based on pixel bashing, whereas 3D uses light sources, shaders, or other such techniques to cast shadows, implement fog, dynamic lighting, etc. In short, 2D is fundamentally about drawing pixels and blending using the Painters Algorithm, whereas 3D is about geometry and shaders and (usually) a depth buffer. Of course 2D is almost always defined as 0,0 in the top left, positive x to the right and positive y down, whereas 3D is almost always 0,0 in the center, positive x to the right and positive y up. But that's just a transform away, so I don't consider that a *fundamental* difference. There are many ways in which these differences manifest themselves when mixing content between the two graphics. http://fxexperience.com/?attachment_id=2853 This picture shows 4 circles and a rectangle. They are setup such that all 5 shapes are in the same group [c1, c2, r, c3, c4]. However depthBuffer is turned on (as well as perspective camera) so that I can use Z to position the shapes instead of using the painter's algorithm. You will notice that the first two circles (green and magenta) have a dirty edge, whereas the last two circles (blue and orange) look beautiful. Note that even though there is a depth buffer involved, we're still issuing these shapes to the card in a specific order. For those not familiar with the depth buffer, the way it works is very simple. When you draw something, in addition to recording the RGBA values for each pixel, you also write to an array (one element per pixel) with a value for every non-transparent pixel that was touched. In this way, if you draw something on top, and then draw something beneath it, the graphics card can check the depth buffer to determine whether it should skip a pixel. So in the image, we draw green for the green circle, and then later draw the black for the rectangle, and because some pixels were already drawn to by the green circle, the card knows not to overwrite those with the black pixel in the background rectangle. The depth buffer is just a technique used to ensure that content rendered respects Z for the order in which things appear composited in the final frame. (You can individually cause nodes to ignore this requirement by setting depthTest to false for a specific node or branch of the scene graph, in which case they won't check with the depth buffer prior to drawing their pixels, they'll just overwrite anything that was drawn previously, even if it has a Z value that would put it behind the thing it is drawing over!). For the sake of this discussion 3D World means depth buffer enabled and assumes perspective camera is enabled, and 2D means 2.5D capable by which I mean perspective camera but no depth buffer. So: 1) Draw the first green circle. This is done by rendering the circle into an image with nice anti-aliasing, and then rotating that image and blend with anything already in the frame buffer 2) Draw the magenta circle. Same as with green -- draw into an image with nice AA and rotate and blend 3) Draw the rectangle. Because the depth buffer is turned on, for each pixel of the green magenta circles, we *don't* render any black. Because the AA edge has been touched with some transparency, it was written to the depth buffer, and we will not draw any black there. Hence the dirty fringe! No blending! 4) Draw the blue circle into an image with nice AA, rotate, and blend. AA edges are blended nicely with black background! 5) Draw the orange circle into an image with nice AA, rotate, and blend. AA edges are blended nicely with black background! Transparency in 3D is a problem, and on ES2 it is particularly difficult to solve. As such, it is usually up to the application to sort their scene graph nodes in such a way as to end up with something sensible. The difficulty in this case is that when you use any 2D node and mix it in with 3D nodes (or even other 2D nodes but with the depth buffer turned on) then you end up in a situation where the nice AA ends up being a liability rather than an asset -- unless you have manually sorted all your nodes in such a way as to avoid the transparency
Re: ComboBoxTableCell: Can we make it easier to use?
Hi Scott,
The pre-built cell factories that ship with JavaFX are intended to
provide convenience for the common use cases, and in some cases it just
makes more sense to roll your own. Which use case you fall into I'm not
quite sure, so the first thing to do is file bugs on the issues you're
uncovering and we can try to make things more convenient for you. If
that just isn't possible, then we can try to work out the best way
forward from there. It certainly sounds like there is a combination of
bugs and feature work to be done, so we can review again once the bugs
are squashed.
Thanks,
-- Jonathan
On 19/07/2013 7:01 a.m., Scott Palmer wrote:
ComboBoxTableCell is very awkward to use if you want to have graphics in
the choices.
There is poor support in general for setting the graphic for items in a
combobox, we have a StringConverter for the text part, but no
NodeConverter for the graphic part.
With ComboBoxTableCell it gets worse because the TableCell graphic is used
to render the actual combobox during editing. If you subclassed to
override updateItem such as
@Override
public void updateItem(MyData data, boolean bln) {
super.updateItem(data, bln);
setGraphic(createGraphicFor(data));
}
(createGraphicFor is part of your implementation that returns a Node)
You get graphics in the table cells, but cancelEdit will clear the graphic
on you when it removes the ComboBox.
You need to override cancelEdit as well with something like:
@Override
public void cancelEdit() {
super.cancelEdit();
setGraphic(createGraphicFor(getItem()));
}
That's just to keep the TableCell rendering the graphic outside of edit
mode. To get the graphics into the ComboBox used for editing you need to
do something even uglier like:
@Override
public void startEdit() {
super.startEdit();
ComboBoxMyData cb = (ComboBox) getGraphic();
cb.setCellFactory(new CallbackListViewMyData ,
ListCellMyData () {
@Override
public ListCellMyData call(ListViewMyData
p) {
return createMyListCell();
}
});
cb.setButtonCell(createMyListCell());
}
Which uses undocumented knowledge of how these things work to know that it
can get a ComboBox from the graphic in the first place.
Just needed to subclass ListCell to get graphics into the Node seems like
an over-complicated way to implement this concept.
new ListCellMyData () {
@Override
protected void updateItem(MyData data, boolean bln) {
super.updateItem(data, bln);
setGraphic(createGraphicFor(data));
setText(data != null ? data.toString() : null);
}
Would it be reasonable to extend the things like ComboBoxXXXCell to better
handle graphics?
The idea is to avoid having to override things in so many places:
ComboBoxTableCell.updateItem, startEdit, cancelEdit, replace the
cellFactory for the Combo which is itself buried inside the TableCell
graphic, all in addition to setting the TableColumn cellFactory.
Instead of just the one CellFactory that can be set on a ComboBox or
ComboBoxXXXCell, such that the right thing just happens.
The Cell editing process needs better documentation, but I already filed an
issue for that.
Regards,
Scott
Re: JavaFX 8 Progress
JWrapper (no plug - I don't work for them or own stock) solves all of this - you have to bundle the jvm but it's small and the installation is hitch-less… Oracle should buy them out - seriously! David On Jul 18, 2013, at 4:09 PM, ozem...@ozemail.com.au wrote: +1 The various applet and Web Start deployment options are severly damaging the entire Java brand. and should be discontinued ASAP. Even before the recent security issues raised their ugly heads there have been several issues with either launching Java applications from within a web page or running them as applets and the user experience has been dismal to say the least. The main reason why Java applets had such a short-lived period of popularity was because Flash came along. Flash applets started significantly faster, didn't pop-up any security warnings and almost always just worked. The exact opposite was true of applets and, sadly, this has only gone further downhill lately. For many years the browser vendors have gone out of their way to make running Java in the browser a very painful experience for the end user. Now we have the situation where most people assume every Java applet is a security threat and avoid them like the plague. Anyway, I do not believe Java, JavaFX or any plugin-based technology has any place in a web browser. This includes Flash and Silverlight. We have HTML5 for that kind of app. Surely it won't be long until all browser vendors make it *impossible* for Java to run inside the browser or simply not support *any* plugins. What's the point of investing any further effort into the Java Plugin? Yes, I know there are legacy apps and applets out there that need to run but Oracle should be focused on getting JavaFX into the modern platforms and their associated app stores. Why not issue an End Of LIfe bulletin that signals the end of the Java Plugin so anyone out there still relying on Java applets can have time to find an alternative. Let's face it, almost *all* the security vulnerabilities exposed in recent months only affect Java in the browser. All the effort Oracle expends on patching these vulnerabilities and tightening up the security model should be spent on advancing JavaFX on mobiles and tablets. -jct - Original Message - From: Daniel Zwolenski zon...@gmail.com To: David Ray cognitionmiss...@gmail.com Cc: mike.ehrenb...@barchart.com Ehrenberg mike.ehrenb...@barchart.com, openjfx-dev@openjdk.java.net openjfx-dev@openjdk.java.net, JeremyJongsma jer...@barchart.com Sent: Fri, 19 Jul 2013 06:47:46 +1000 Subject: Re: JavaFX 8 Progress Among general complaints and my own disasters with it, I had this guy write to me: http://web-conferencing-central.com The failure of webstart is making him lose customers (they literally are emailing him and telling him it's too hard to install). This is one of the very few commercial, public apps that use desktop-java and webstart (I'd be keen to know about any others - I know of none that use jfx?). From what I understand of the work being carried out, I highly doubt any of the fixes or improvements being worked on are going to help people like this. I love the idea of web deployment but it's failed and getting worse with the complexities now added in your attempts to keep it secure. In my opinion, web deploy should be deprecated or at least placed in minimal 'bandaid' only fixes and all effort should be put into making native bundles actually useful and into adding app store support. On 19/07/2013, at 2:10 AM, David Ray cognitionmiss...@gmail.com wrote: I don't want to open up the webstart can of worms here, but we have multiple issues surrounding recognition and validity of signed jars when using certain VMARGS in combination with OSGi style deployment. We finally settled on JWrapper due to WebStarts apparent brittleness - but as you say, this is neither here nor there as far as JavaFX is concerned… Anyway, thanks for getting back to us on the deployment tools organization… David On Jul 18, 2013, at 9:22 AM, Joe McGlynn joe.mcgl...@oracle.com wrote: No, the deployment team works on these, not the FX team. It's the same bits for FX and Swing/AWT when running browser-deployed apps (which includes applets and web start). Deployment, FX and Swing are all part of the Java client org. There are a number of bug fixed being worked in this area, as well as new requirements around how to deploy a secure applet or web start app. The deploy code base is currently identical between 7u and JDK 8. If you are working with deploy technologies you should know this area is rapidly changing and I'd strongly advise staying on the latest release (currently 7u40 EA) and following the updates to the docs, especially around best practices for deployment. In short, these are: Buy
Re: Mixing 2D and 3D
Does it need to be a separate class, can it not just be a setting on scene like setRenderMode(3d)? Just thinking you may want a base 3d view for example but then show 2d screens at times for settings, etc, so you could switch it on and off. I assume there's no way to do it pane by pane, so the docked components of a BorderPane are 2d optimized but the center is 3d? Or is that what SubScene3d is for (not real clear how this would be used)? On 19/07/2013, at 6:58 AM, Richard Bair richard.b...@oracle.com wrote: While working on RT-5534, we found a large number of odd cases when mixing 2D and 3D. Some of these we talked about previously, some either we hadn't or, at least, they hadn't occurred to me. With 8 we are defining a lot of new API for 3D, and we need to make sure that we've very clearly defined how 2D and 3D nodes interact with each other, or developers will run into problems frequently and fire off angry emails about it :-) Fundamentally, 2D and 3D rendering are completely different. There are differences in how opacity is understood and applied. 2D graphics frequently use clips, whereas 3D does not (other than clipping the view frustum or other such environmental clipping). 2D uses things like filter effects (drop shadow, etc) that is based on pixel bashing, whereas 3D uses light sources, shaders, or other such techniques to cast shadows, implement fog, dynamic lighting, etc. In short, 2D is fundamentally about drawing pixels and blending using the Painters Algorithm, whereas 3D is about geometry and shaders and (usually) a depth buffer. Of course 2D is almost always defined as 0,0 in the top left, positive x to the right and positive y down, whereas 3D is almost always 0,0 in the center, positive x to the right and positive y up. But that's just a transform away, so I don't consider that a *fundamental* difference. There are many ways in which these differences manifest themselves when mixing content between the two graphics. http://fxexperience.com/?attachment_id=2853 This picture shows 4 circles and a rectangle. They are setup such that all 5 shapes are in the same group [c1, c2, r, c3, c4]. However depthBuffer is turned on (as well as perspective camera) so that I can use Z to position the shapes instead of using the painter's algorithm. You will notice that the first two circles (green and magenta) have a dirty edge, whereas the last two circles (blue and orange) look beautiful. Note that even though there is a depth buffer involved, we're still issuing these shapes to the card in a specific order. For those not familiar with the depth buffer, the way it works is very simple. When you draw something, in addition to recording the RGBA values for each pixel, you also write to an array (one element per pixel) with a value for every non-transparent pixel that was touched. In this way, if you draw something on top, and then draw something beneath it, the graphics card can check the depth buffer to determine whether it should skip a pixel. So in the image, we draw green for the green circle, and then later draw the black for the rectangle, and because some pixels were already drawn to by the green circle, the card knows not to overwrite those with the black pixel in the background rectangle. The depth buffer is just a technique used to ensure that content rendered respects Z for the order in which things appear composited in the final frame. (You can individually cause nodes to ignore this requirement by setting depthTest to false for a specific node or branch of the scene graph, in which case they won't check with the depth buffer prior to drawing their pixels, they'll just overwrite anything that was drawn previously, even if it has a Z value that would put it behind the thing it is drawing over!). For the sake of this discussion 3D World means depth buffer enabled and assumes perspective camera is enabled, and 2D means 2.5D capable by which I mean perspective camera but no depth buffer. So: 1) Draw the first green circle. This is done by rendering the circle into an image with nice anti-aliasing, and then rotating that image and blend with anything already in the frame buffer 2) Draw the magenta circle. Same as with green -- draw into an image with nice AA and rotate and blend 3) Draw the rectangle. Because the depth buffer is turned on, for each pixel of the green magenta circles, we *don't* render any black. Because the AA edge has been touched with some transparency, it was written to the depth buffer, and we will not draw any black there. Hence the dirty fringe! No blending! 4) Draw the blue circle into an image with nice AA, rotate, and blend. AA edges are blended nicely with black background! 5) Draw the orange circle into an image with nice AA, rotate, and blend. AA edges are blended nicely with black
Re: JavaFX 8 Progress
I've heard the webstart is broke, don't fix it, move on song before from a number of people. What I haven't heard is a credible solution to solving the very real problem of keeping an app up-to-date in a corporate setting. For the most part, I agree that if you're in the business of selling commercial software, selling and distributing through an app store probably makes sense for you. Although I wouldn't relish having to build on all of those platforms. However, posting proprietary apps to external OS-specific app stores doesn't really work for anyone in a corporate setting. Neither does making a user re-install an application every time you post a bug fix. In addition, many corporations limit the privileges they give users. Cheers, Mark
Re: Mixing 2D and 3D
I'm not a 3D expert but my gut tells me that the two pipelines should remain distinct as you say. I can't imagine the evolution of such different functions converging in such a way where the semantic treatment of the two will coincide in a clean, simple and unconfusing manner. That only seems like it would lead to compromise and the inability to develop both concepts to their full maturity - and what about what you mentioned regarding possible OpenGL exposure from the 3D API ? Would this be possible while still merging 2D and 3D semantics? David On Jul 18, 2013, at 3:58 PM, Richard Bair richard.b...@oracle.com wrote: While working on RT-5534, we found a large number of odd cases when mixing 2D and 3D. Some of these we talked about previously, some either we hadn't or, at least, they hadn't occurred to me. With 8 we are defining a lot of new API for 3D, and we need to make sure that we've very clearly defined how 2D and 3D nodes interact with each other, or developers will run into problems frequently and fire off angry emails about it :-) Fundamentally, 2D and 3D rendering are completely different. There are differences in how opacity is understood and applied. 2D graphics frequently use clips, whereas 3D does not (other than clipping the view frustum or other such environmental clipping). 2D uses things like filter effects (drop shadow, etc) that is based on pixel bashing, whereas 3D uses light sources, shaders, or other such techniques to cast shadows, implement fog, dynamic lighting, etc. In short, 2D is fundamentally about drawing pixels and blending using the Painters Algorithm, whereas 3D is about geometry and shaders and (usually) a depth buffer. Of course 2D is almost always defined as 0,0 in the top left, positive x to the right and positive y down, whereas 3D is almost always 0,0 in the center, positive x to the right and positive y up. But that's just a transform away, so I don't consider that a *fundamental* difference. There are many ways in which these differences manifest themselves when mixing content between the two graphics. http://fxexperience.com/?attachment_id=2853 This picture shows 4 circles and a rectangle. They are setup such that all 5 shapes are in the same group [c1, c2, r, c3, c4]. However depthBuffer is turned on (as well as perspective camera) so that I can use Z to position the shapes instead of using the painter's algorithm. You will notice that the first two circles (green and magenta) have a dirty edge, whereas the last two circles (blue and orange) look beautiful. Note that even though there is a depth buffer involved, we're still issuing these shapes to the card in a specific order. For those not familiar with the depth buffer, the way it works is very simple. When you draw something, in addition to recording the RGBA values for each pixel, you also write to an array (one element per pixel) with a value for every non-transparent pixel that was touched. In this way, if you draw something on top, and then draw something beneath it, the graphics card can check the depth buffer to determine whether it should skip a pixel. So in the image, we draw green for the green circle, and then later draw the black for the rectangle, and because some pixels were already drawn to by the green circle, the card knows not to overwrite those with the black pixel in the background rectangle. The depth buffer is just a technique used to ensure that content rendered respects Z for the order in which things appear composited in the final frame. (You can individually cause nodes to ignore this requirement by setting depthTest to false for a specific node or branch of the scene graph, in which case they won't check with the depth buffer prior to drawing their pixels, they'll just overwrite anything that was drawn previously, even if it has a Z value that would put it behind the thing it is drawing over!). For the sake of this discussion 3D World means depth buffer enabled and assumes perspective camera is enabled, and 2D means 2.5D capable by which I mean perspective camera but no depth buffer. So: 1) Draw the first green circle. This is done by rendering the circle into an image with nice anti-aliasing, and then rotating that image and blend with anything already in the frame buffer 2) Draw the magenta circle. Same as with green -- draw into an image with nice AA and rotate and blend 3) Draw the rectangle. Because the depth buffer is turned on, for each pixel of the green magenta circles, we *don't* render any black. Because the AA edge has been touched with some transparency, it was written to the depth buffer, and we will not draw any black there. Hence the dirty fringe! No blending! 4) Draw the blue circle into an image with nice AA, rotate, and blend. AA edges are blended nicely with black
Re: Mixing 2D and 3D
You just embed a SubScene within a 3D scene, or a SubScene3D within a 2D scene, etc. So you can easily nest one rendering mode within the other -- where easily means, that each SubScene / SubScene3D has the semantics of draw into a texture and composite into the parent scene. Richard On Jul 18, 2013, at 2:20 PM, Daniel Zwolenski zon...@gmail.com wrote: Does it need to be a separate class, can it not just be a setting on scene like setRenderMode(3d)? Just thinking you may want a base 3d view for example but then show 2d screens at times for settings, etc, so you could switch it on and off. I assume there's no way to do it pane by pane, so the docked components of a BorderPane are 2d optimized but the center is 3d? Or is that what SubScene3d is for (not real clear how this would be used)? On 19/07/2013, at 6:58 AM, Richard Bair richard.b...@oracle.com wrote: While working on RT-5534, we found a large number of odd cases when mixing 2D and 3D. Some of these we talked about previously, some either we hadn't or, at least, they hadn't occurred to me. With 8 we are defining a lot of new API for 3D, and we need to make sure that we've very clearly defined how 2D and 3D nodes interact with each other, or developers will run into problems frequently and fire off angry emails about it :-) Fundamentally, 2D and 3D rendering are completely different. There are differences in how opacity is understood and applied. 2D graphics frequently use clips, whereas 3D does not (other than clipping the view frustum or other such environmental clipping). 2D uses things like filter effects (drop shadow, etc) that is based on pixel bashing, whereas 3D uses light sources, shaders, or other such techniques to cast shadows, implement fog, dynamic lighting, etc. In short, 2D is fundamentally about drawing pixels and blending using the Painters Algorithm, whereas 3D is about geometry and shaders and (usually) a depth buffer. Of course 2D is almost always defined as 0,0 in the top left, positive x to the right and positive y down, whereas 3D is almost always 0,0 in the center, positive x to the right and positive y up. But that's just a transform away, so I don't consider that a *fundamental* difference. There are many ways in which these differences manifest themselves when mixing content between the two graphics. http://fxexperience.com/?attachment_id=2853 This picture shows 4 circles and a rectangle. They are setup such that all 5 shapes are in the same group [c1, c2, r, c3, c4]. However depthBuffer is turned on (as well as perspective camera) so that I can use Z to position the shapes instead of using the painter's algorithm. You will notice that the first two circles (green and magenta) have a dirty edge, whereas the last two circles (blue and orange) look beautiful. Note that even though there is a depth buffer involved, we're still issuing these shapes to the card in a specific order. For those not familiar with the depth buffer, the way it works is very simple. When you draw something, in addition to recording the RGBA values for each pixel, you also write to an array (one element per pixel) with a value for every non-transparent pixel that was touched. In this way, if you draw something on top, and then draw something beneath it, the graphics card can check the depth buffer to determine whether it should skip a pixel. So in the image, we draw green for the green circle, and then later draw the black for the rectangle, and because some pixels were already drawn to by the green circle, the card knows not to overwrite those with the black pixel in the background rectangle. The depth buffer is just a technique used to ensure that content rendered respects Z for the order in which things appear composited in the final frame. (You can individually cause nodes to ignore this requirement by setting depthTest to false for a specific node or branch of the scene graph, in which case they won't check with the depth buffer prior to drawing their pixels, they'll just overwrite anything that was drawn previously, even if it has a Z value that would put it behind the thing it is drawing over!). For the sake of this discussion 3D World means depth buffer enabled and assumes perspective camera is enabled, and 2D means 2.5D capable by which I mean perspective camera but no depth buffer. So: 1) Draw the first green circle. This is done by rendering the circle into an image with nice anti-aliasing, and then rotating that image and blend with anything already in the frame buffer 2) Draw the magenta circle. Same as with green -- draw into an image with nice AA and rotate and blend 3) Draw the rectangle. Because the depth buffer is turned on, for each pixel of the green magenta circles, we *don't* render any black. Because the AA edge has been touched with some transparency, it
Re: Mixing 2D and 3D
Basically the embed and OpenGL rendering would be treated as rendering into a texture using OpenGL and composite it into the scene, so it doesn't really impact on either approach. Unless instead of giving you a surface to scribble into using OpenGL, we gave you a callback where you issued OpenGL into the stream of commands such that your code was an integral part of the scene. In that case, there would be all kinds of issues depending on whether it was a 2D or 3D setup. Richard On Jul 18, 2013, at 2:29 PM, David Ray cognitionmiss...@gmail.com wrote: I'm not a 3D expert but my gut tells me that the two pipelines should remain distinct as you say. I can't imagine the evolution of such different functions converging in such a way where the semantic treatment of the two will coincide in a clean, simple and unconfusing manner. That only seems like it would lead to compromise and the inability to develop both concepts to their full maturity - and what about what you mentioned regarding possible OpenGL exposure from the 3D API ? Would this be possible while still merging 2D and 3D semantics? David On Jul 18, 2013, at 3:58 PM, Richard Bair richard.b...@oracle.com wrote: While working on RT-5534, we found a large number of odd cases when mixing 2D and 3D. Some of these we talked about previously, some either we hadn't or, at least, they hadn't occurred to me. With 8 we are defining a lot of new API for 3D, and we need to make sure that we've very clearly defined how 2D and 3D nodes interact with each other, or developers will run into problems frequently and fire off angry emails about it :-) Fundamentally, 2D and 3D rendering are completely different. There are differences in how opacity is understood and applied. 2D graphics frequently use clips, whereas 3D does not (other than clipping the view frustum or other such environmental clipping). 2D uses things like filter effects (drop shadow, etc) that is based on pixel bashing, whereas 3D uses light sources, shaders, or other such techniques to cast shadows, implement fog, dynamic lighting, etc. In short, 2D is fundamentally about drawing pixels and blending using the Painters Algorithm, whereas 3D is about geometry and shaders and (usually) a depth buffer. Of course 2D is almost always defined as 0,0 in the top left, positive x to the right and positive y down, whereas 3D is almost always 0,0 in the center, positive x to the right and positive y up. But that's just a transform away, so I don't consider that a *fundamental* difference. There are many ways in which these differences manifest themselves when mixing content between the two graphics. http://fxexperience.com/?attachment_id=2853 This picture shows 4 circles and a rectangle. They are setup such that all 5 shapes are in the same group [c1, c2, r, c3, c4]. However depthBuffer is turned on (as well as perspective camera) so that I can use Z to position the shapes instead of using the painter's algorithm. You will notice that the first two circles (green and magenta) have a dirty edge, whereas the last two circles (blue and orange) look beautiful. Note that even though there is a depth buffer involved, we're still issuing these shapes to the card in a specific order. For those not familiar with the depth buffer, the way it works is very simple. When you draw something, in addition to recording the RGBA values for each pixel, you also write to an array (one element per pixel) with a value for every non-transparent pixel that was touched. In this way, if you draw something on top, and then draw something beneath it, the graphics card can check the depth buffer to determine whether it should skip a pixel. So in the image, we draw green for the green circle, and then later draw the black for the rectangle, and because some pixels were already drawn to by the green circle, the card knows not to overwrite those with the black pixel in the background rectangle. The depth buffer is just a technique used to ensure that content rendered respects Z for the order in which things appear composited in the final frame. (You can individually cause nodes to ignore this requirement by setting depthTest to false for a specific node or branch of the scene graph, in which case they won't check with the depth buffer prior to drawing their pixels, they'll just overwrite anything that was drawn previously, even if it has a Z value that would put it behind the thing it is drawing over!). For the sake of this discussion 3D World means depth buffer enabled and assumes perspective camera is enabled, and 2D means 2.5D capable by which I mean perspective camera but no depth buffer. So: 1) Draw the first green circle. This is done by rendering the circle into an image with nice anti-aliasing, and then rotating that image and blend with anything already in the frame buffer
Re: JavaFX 8 Progress
Hi Mark, I know it is not necessarily helpful to post comments along the lines of this aint working without suggesting viable alternatives but given that I am not privy to Oracle's strategic plans for Web Start or Java in the browser and not privy to the internal technological limitations of such functionality I can only highlight the situation as perceived by the end user and also by the developer. I think it's true that most commercial developers of Java/JavaFX applications will probably want to deploy their software as native bundles or through an app store in preference to Web Start. This may be because their are security issues with Web Start apps that don't effect locally deployed apps and also because of the other issues with Web Start that I referred to. Also, there are some limitations with Web Start in terms of versioning such as: 1. What if I want to install a specific version? 2. What if I *don't* want to install the version currently offered through the Web Start link because it is not compatible with my system configuration or with other software? 3. How do I roll-back to a previous version if I want to? Your comments on corporate deployment are spot on though. However, there are other options for updating software that do not require Web Start. Indeed, many applications *not* written in Java are able to update themselves through a Check for updates menu option or similar. Surely Java/JavaFX applications could be updated in the same way? I recall there was a discussion on this list earlier this year on this very subject with links to 3rd-party auto-updating mechanisms and discussions on Oracle's own plans in ths area. If such a mechanism is developed then *all* JavaFX applications could make use of it and then what would be the need for Web Start? Corporations utilise thousands of applications not written in Java that have the ability to update themselves so why not Java/JavaFX applications too? Cheers, -jct - Original Message - From: Mark Fortner To:Daniel Zwolenski Cc:mike.ehrenb...@barchart.com Ehrenberg , openjfx-dev@openjdk.java.net , JeremyJongsma Sent:Thu, 18 Jul 2013 14:30:16 -0700 Subject:Re: JavaFX 8 Progress I've heard the webstart is broke, don't fix it, move on song before from a number of people. What I haven't heard is a credible solution to solving the very real problem of keeping an app up-to-date in a corporate setting. For the most part, I agree that if you're in the business of selling commercial software, selling and distributing through an app store probably makes sense for you. Although I wouldn't relish having to build on all of those platforms. However, posting proprietary apps to external OS-specific app stores doesn't really work for anyone in a corporate setting. Neither does making a user re-install an application every time you post a bug fix. In addition, many corporations limit the privileges they give users. Cheers, Mark
Re: Java Deployment (was Re: JavaFX 8 Progress)
So you're saying, once I create my new JavaFX app with all the new beautiful and wondrous JavaFX goodies - I can do what? Sit at home and look at it? :) David On Jul 18, 2013, at 5:02 PM, Daniel Zwolenski zon...@gmail.com wrote: There are definitely credible alternatives. The problem is currently the alternatives are not implemented well enough so web still ends up a contender just by being the only one able to stand up. And for the record I build both public facing apps and back-office apps and web deploy does not work well for either. I stopped using jfx because of deployment. I now build only webapps because of deployment. Credible alternatives: 1. Native bundlers, but we need: - auto updating so people can easily release patch updates - smaller co-bundled jre's so that the initial download and install is smooth and quick - better build tools to make this easier to integrate into a standard build process, with some solution for cross-platform build support or to at least minimize the pain 2. App stores: - ready to go right now for Mac but we don't have the tools and I think we need everything fully open sourced for licensing reasons (hard to say) - need to either pick one of the unofficial win app stores for pre-win8 support (there's a few), or build our own app store - we just need tools for building and deploying to app stores (not that hard) and cut down jre sizes again (app stores are an extension of cobundling approach). 3. Self-hosted 'app store' for corporate settings. install a small, native client on the machine that allows that user to download and install apps from your private server, with auto-updating, etc - we need to build one, not that hard, maybe a month or two of work to get a first working version out. I would have built one by now but because jfx packaging tools are so bad I've burnt up all my spare time just putting wrappers around these to get the most basic of maven plugins to work. All of the above could have been implemented by now if there was just a little bit of love in this area. One resource ticking away would have been enough to get something going. As it stands there has been zero, nada, zip changes into anything other than web/security deployment efforts over the last year. J8 due next year (!) will not include any of the above, or even any simple improvements to deployment approaches other than web, to the best of my knowledge. On 19/07/2013, at 7:30 AM, Mark Fortner phidia...@gmail.com wrote: I've heard the webstart is broke, don't fix it, move on song before from a number of people. What I haven't heard is a credible solution to solving the very real problem of keeping an app up-to-date in a corporate setting. For the most part, I agree that if you're in the business of selling commercial software, selling and distributing through an app store probably makes sense for you. Although I wouldn't relish having to build on all of those platforms. However, posting proprietary apps to external OS-specific app stores doesn't really work for anyone in a corporate setting. Neither does making a user re-install an application every time you post a bug fix. In addition, many corporations limit the privileges they give users. Cheers, Mark
hg: openjfx/8/graphics/rt: 2 new changesets
Changeset: 5d13d4188303 Author:rbair Date: 2013-07-18 14:01 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5d13d4188303 Updated IntelliJ projects to avoid accidentally picking up files from caches for the different apps ! .idea/3DViewer.iml ! .idea/Ensemble8.iml ! .idea/Modena.iml ! .idea/deploy.iml ! .idea/rt-closed.iml ! .idea/web.iml Changeset: de898e64551c Author:rbair Date: 2013-07-18 14:03 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/de898e64551c Fix AbstractMasterTimerTest after fix by martin for RT-29544 (16a266d9f6fc) ! modules/graphics/src/test/java/com/sun/scenario/animation/AbstractMasterTimerTest.java
Re: Java Deployment (was Re: JavaFX 8 Progress)
For Swing you can actually use CacioWeb, works quite well. Zero deployment, no VM needed, no plugin, just an HTML 5 capable browser. Doesn't work with JavaFX unfortunately. Cheers, Mario Il giorno 19/lug/2013 00:03, Daniel Zwolenski zon...@gmail.com ha scritto: There are definitely credible alternatives. The problem is currently the alternatives are not implemented well enough so web still ends up a contender just by being the only one able to stand up. And for the record I build both public facing apps and back-office apps and web deploy does not work well for either. I stopped using jfx because of deployment. I now build only webapps because of deployment. Credible alternatives: 1. Native bundlers, but we need: - auto updating so people can easily release patch updates - smaller co-bundled jre's so that the initial download and install is smooth and quick - better build tools to make this easier to integrate into a standard build process, with some solution for cross-platform build support or to at least minimize the pain 2. App stores: - ready to go right now for Mac but we don't have the tools and I think we need everything fully open sourced for licensing reasons (hard to say) - need to either pick one of the unofficial win app stores for pre-win8 support (there's a few), or build our own app store - we just need tools for building and deploying to app stores (not that hard) and cut down jre sizes again (app stores are an extension of cobundling approach). 3. Self-hosted 'app store' for corporate settings. install a small, native client on the machine that allows that user to download and install apps from your private server, with auto-updating, etc - we need to build one, not that hard, maybe a month or two of work to get a first working version out. I would have built one by now but because jfx packaging tools are so bad I've burnt up all my spare time just putting wrappers around these to get the most basic of maven plugins to work. All of the above could have been implemented by now if there was just a little bit of love in this area. One resource ticking away would have been enough to get something going. As it stands there has been zero, nada, zip changes into anything other than web/security deployment efforts over the last year. J8 due next year (!) will not include any of the above, or even any simple improvements to deployment approaches other than web, to the best of my knowledge. On 19/07/2013, at 7:30 AM, Mark Fortner phidia...@gmail.com wrote: I've heard the webstart is broke, don't fix it, move on song before from a number of people. What I haven't heard is a credible solution to solving the very real problem of keeping an app up-to-date in a corporate setting. For the most part, I agree that if you're in the business of selling commercial software, selling and distributing through an app store probably makes sense for you. Although I wouldn't relish having to build on all of those platforms. However, posting proprietary apps to external OS-specific app stores doesn't really work for anyone in a corporate setting. Neither does making a user re-install an application every time you post a bug fix. In addition, many corporations limit the privileges they give users. Cheers, Mark
Java Deployment (was Re: JavaFX 8 Progress)
There are definitely credible alternatives. The problem is currently the alternatives are not implemented well enough so web still ends up a contender just by being the only one able to stand up. And for the record I build both public facing apps and back-office apps and web deploy does not work well for either. I stopped using jfx because of deployment. I now build only webapps because of deployment. Credible alternatives: 1. Native bundlers, but we need: - auto updating so people can easily release patch updates - smaller co-bundled jre's so that the initial download and install is smooth and quick - better build tools to make this easier to integrate into a standard build process, with some solution for cross-platform build support or to at least minimize the pain 2. App stores: - ready to go right now for Mac but we don't have the tools and I think we need everything fully open sourced for licensing reasons (hard to say) - need to either pick one of the unofficial win app stores for pre-win8 support (there's a few), or build our own app store - we just need tools for building and deploying to app stores (not that hard) and cut down jre sizes again (app stores are an extension of cobundling approach). 3. Self-hosted 'app store' for corporate settings. install a small, native client on the machine that allows that user to download and install apps from your private server, with auto-updating, etc - we need to build one, not that hard, maybe a month or two of work to get a first working version out. I would have built one by now but because jfx packaging tools are so bad I've burnt up all my spare time just putting wrappers around these to get the most basic of maven plugins to work. All of the above could have been implemented by now if there was just a little bit of love in this area. One resource ticking away would have been enough to get something going. As it stands there has been zero, nada, zip changes into anything other than web/security deployment efforts over the last year. J8 due next year (!) will not include any of the above, or even any simple improvements to deployment approaches other than web, to the best of my knowledge. On 19/07/2013, at 7:30 AM, Mark Fortner phidia...@gmail.com wrote: I've heard the webstart is broke, don't fix it, move on song before from a number of people. What I haven't heard is a credible solution to solving the very real problem of keeping an app up-to-date in a corporate setting. For the most part, I agree that if you're in the business of selling commercial software, selling and distributing through an app store probably makes sense for you. Although I wouldn't relish having to build on all of those platforms. However, posting proprietary apps to external OS-specific app stores doesn't really work for anyone in a corporate setting. Neither does making a user re-install an application every time you post a bug fix. In addition, many corporations limit the privileges they give users. Cheers, Mark
RE: Java Deployment (was Re: JavaFX 8 Progress)
auto updating so people can easily release patch updates Checkout getdown = http://code.google.com/p/getdown/. It's simple, proven open source tech used to distribute the Puzzle Pirates MMORPG which had 4 million accounts and 250 million hours of play time in 2008. Forking getdown, swapping out its existing thin Swing UI and replacing it with a configurable JavaFX UI is likely a pretty easy process. Some additional work would need to be done to integrate it into modern build/deploy tool chains such as the javafx maven and gradle plugins. I think it makes sense for the native bundling option where the combination of the two allows (IMO) a reasonable replacement for webstart. Replacing applets is more difficult, you probably want to use something like CacioWeb or have cloud based logic and some rendering with a streaming protocol to the browser and final rendering inside an html5 canvas, but that kind of technology does not exist for JavaFX as far as I know. John -Original Message- From: openjfx-dev-boun...@openjdk.java.net [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Mario Torre Sent: Thursday, July 18, 2013 3:10 PM To: Daniel Zwolenski Cc: mike.ehrenberg@barchart.comEhrenberg; openjfx-dev@openjdk.java.net; JeremyJongsma Subject: Re: Java Deployment (was Re: JavaFX 8 Progress) For Swing you can actually use CacioWeb, works quite well. Zero deployment, no VM needed, no plugin, just an HTML 5 capable browser. Doesn't work with JavaFX unfortunately. Cheers, Mario Il giorno 19/lug/2013 00:03, Daniel Zwolenski zon...@gmail.com ha scritto: There are definitely credible alternatives. The problem is currently the alternatives are not implemented well enough so web still ends up a contender just by being the only one able to stand up. And for the record I build both public facing apps and back-office apps and web deploy does not work well for either. I stopped using jfx because of deployment. I now build only webapps because of deployment. Credible alternatives: 1. Native bundlers, but we need: - auto updating so people can easily release patch updates - smaller co-bundled jre's so that the initial download and install is smooth and quick - better build tools to make this easier to integrate into a standard build process, with some solution for cross-platform build support or to at least minimize the pain 2. App stores: - ready to go right now for Mac but we don't have the tools and I think we need everything fully open sourced for licensing reasons (hard to say) - need to either pick one of the unofficial win app stores for pre-win8 support (there's a few), or build our own app store - we just need tools for building and deploying to app stores (not that hard) and cut down jre sizes again (app stores are an extension of cobundling approach). 3. Self-hosted 'app store' for corporate settings. install a small, native client on the machine that allows that user to download and install apps from your private server, with auto-updating, etc - we need to build one, not that hard, maybe a month or two of work to get a first working version out. I would have built one by now but because jfx packaging tools are so bad I've burnt up all my spare time just putting wrappers around these to get the most basic of maven plugins to work. All of the above could have been implemented by now if there was just a little bit of love in this area. One resource ticking away would have been enough to get something going. As it stands there has been zero, nada, zip changes into anything other than web/security deployment efforts over the last year. J8 due next year (!) will not include any of the above, or even any simple improvements to deployment approaches other than web, to the best of my knowledge. On 19/07/2013, at 7:30 AM, Mark Fortner phidia...@gmail.com wrote: I've heard the webstart is broke, don't fix it, move on song before from a number of people. What I haven't heard is a credible solution to solving the very real problem of keeping an app up-to-date in a corporate setting. For the most part, I agree that if you're in the business of selling commercial software, selling and distributing through an app store probably makes sense for you. Although I wouldn't relish having to build on all of those platforms. However, posting proprietary apps to external OS-specific app stores doesn't really work for anyone in a corporate setting. Neither does making a user re-install an application every time you post a bug fix. In addition, many corporations limit the privileges they give users. Cheers, Mark
Re: Java Deployment (was Re: JavaFX 8 Progress)
A list of JWrapper's features: Oracle, are you ready to buy these guys yet? If you don't, we will… :) Easily deploy Java as native apps (for free) But lets break that down... Easily... To us, this means being able to build for everything, on anything - true cross platform builds. Multiple developers can share one build file, yet everyone can build for every OS. Users can get hold of your app and updates no matter what web server or scripting language you use. You issue a new automatically updated release by overwriting some files on your web server, and if we do our best to ensure your app has a predictable, stable environment. If use a system JRE we even copy it so you aren't exposed when Oracle decides to update it and break API. …deploy Java... To us, this means creating signed, iconified, automatically updating OS-native apps that can pick up a system JRE, download or bundle a heavily compressed one. Since we're replacing applets it also means making your app available on your website by just sharing the files and adding one line of HTML to embed a JavaScript download button. It also means stuff like automatically detecting HTTP proxies from wherever makes the OS has that info (system settings, browser settings) so that you don't have to guess at them yourself or hope that the system JRE is set up to use the right one (if there even is one). …as native apps To us this means it looks and feels like a native app. On Windows this means a signed executable which can elevate as you need. On OSX this means a signed .app file inside a DMG. On Linux this means a native exe inside a double-click extractable tar.
hg: openjfx/8/graphics/rt: Fix intellij designTime module to include unit tests
Changeset: 21a47da3d8b8 Author:rbair Date: 2013-07-18 15:52 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/21a47da3d8b8 Fix intellij designTime module to include unit tests ! .idea/designTime.iml
Re: JavaFX 8 Progress
Awesome - on the surface it does look like what Oracle were/should-be trying to build with their packaging tools - and it's free! If you use it a bit, let me know how it goes. If it's any good I'll look at wrappering this in a Maven plugin (looks straight forward). Maybe we can cut Oracle out of this altogether and get some actual progress here. If you can get your JWrappered reportmill app deployed somewhere, I'd be keen to try it out and see what the end user experience is like. Just trying their sample apps now. On Fri, Jul 19, 2013 at 10:43 AM, Jeff Martin j...@reportmill.com wrote: Wow - JWrapper really is remarkable. It took me less than 30 minutes to figure out how to package our ReportMill app for Mac, Windows and Linux. Worked like magic. It doesn't include JavaFX yet, though, even though the Mac JRE is 1.7.0u25. Jeff On Jul 18, 2013, at 4:20 PM, David Ray cognitionmiss...@gmail.com wrote: JWrapper (no plug - I don't work for them or own stock) solves all of this - you have to bundle the jvm but it's small and the installation is hitch-less… Oracle should buy them out - seriously! David On Jul 18, 2013, at 4:09 PM, ozem...@ozemail.com.au wrote: +1 The various applet and Web Start deployment options are severly damaging the entire Java brand. and should be discontinued ASAP. Even before the recent security issues raised their ugly heads there have been several issues with either launching Java applications from within a web page or running them as applets and the user experience has been dismal to say the least. The main reason why Java applets had such a short-lived period of popularity was because Flash came along. Flash applets started significantly faster, didn't pop-up any security warnings and almost always just worked. The exact opposite was true of applets and, sadly, this has only gone further downhill lately. For many years the browser vendors have gone out of their way to make running Java in the browser a very painful experience for the end user. Now we have the situation where most people assume every Java applet is a security threat and avoid them like the plague. Anyway, I do not believe Java, JavaFX or any plugin-based technology has any place in a web browser. This includes Flash and Silverlight. We have HTML5 for that kind of app. Surely it won't be long until all browser vendors make it *impossible* for Java to run inside the browser or simply not support *any* plugins. What's the point of investing any further effort into the Java Plugin? Yes, I know there are legacy apps and applets out there that need to run but Oracle should be focused on getting JavaFX into the modern platforms and their associated app stores. Why not issue an End Of LIfe bulletin that signals the end of the Java Plugin so anyone out there still relying on Java applets can have time to find an alternative. Let's face it, almost *all* the security vulnerabilities exposed in recent months only affect Java in the browser. All the effort Oracle expends on patching these vulnerabilities and tightening up the security model should be spent on advancing JavaFX on mobiles and tablets. -jct - Original Message - From: Daniel Zwolenski zon...@gmail.com To: David Ray cognitionmiss...@gmail.com Cc: mike.ehrenb...@barchart.com Ehrenberg mike.ehrenb...@barchart.com, openjfx-dev@openjdk.java.net openjfx-dev@openjdk.java.net, JeremyJongsma jer...@barchart.com Sent: Fri, 19 Jul 2013 06:47:46 +1000 Subject: Re: JavaFX 8 Progress Among general complaints and my own disasters with it, I had this guy write to me: http://web-conferencing-central.com The failure of webstart is making him lose customers (they literally are emailing him and telling him it's too hard to install). This is one of the very few commercial, public apps that use desktop-java and webstart (I'd be keen to know about any others - I know of none that use jfx?). From what I understand of the work being carried out, I highly doubt any of the fixes or improvements being worked on are going to help people like this. I love the idea of web deployment but it's failed and getting worse with the complexities now added in your attempts to keep it secure. In my opinion, web deploy should be deprecated or at least placed in minimal 'bandaid' only fixes and all effort should be put into making native bundles actually useful and into adding app store support. On 19/07/2013, at 2:10 AM, David Ray cognitionmiss...@gmail.com wrote: I don't want to open up the webstart can of worms here, but we have multiple issues surrounding recognition and validity of signed jars when using certain VMARGS in combination with OSGi style deployment. We finally settled on JWrapper due to WebStarts apparent brittleness - but as you say, this is neither here nor there as far as JavaFX is concerned… Anyway,
