Re: [9] Review request: JDK-8147781: Javapackager installer needs to cleanup temporary folders

[Stefan Fuchs]

Hi,

are you sure that there is a bug?

The verbose paramter is explicitly documented to leave temporary files 
around, as a starting point for customization.


Quote from 
https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/self-contained-packaging.html


Verbose mode includes the following actions:

.

A copy of the configuration files and resources used to create the self 
contained package are saved to a temporary folder. You can use these 
files as a starting point for customization


...


- Stefan

Chris,

Please review the changes about removing temporary files.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8147781
Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8147781/webrev.00/

--Victor

Re: [9] Review request: JDK-8169443 Deprecate Java Packager Blob Signing

[Stefan Fuchs]

Well, in Java 8  is part of the javafx_ant_task reference [1]
and advertised as being the new and more efficient way to sign jars [2]

Anyway, perhaps the deprecation message for  could be 
enhanced to point to https://ant.apache.org/manual/Tasks/signjar.html as 
the recommended way to sign jars.

The Deployment Guide should be updated as well.

- Stefan


[1] 
http://docs.oracle.com/javase/8/docs/technotes/guides/deploy/javafx_ant_task_reference.html#CIADDAEE
[2] 
http://docs.oracle.com/javase/8/docs/technotes/guides/deploy/packaging.html#BABJGFBH




David DeHaven wrote:

This is only signing via the  mechanism, which was never fully 
supported or part of any standard. To sign webstart applications (even FX apps) just 
use jarsigner or the associated ant signjar task.

-DrD-

[1] https://ant.apache.org/manual/Tasks/signjar.html


On Dec 13, 2016, at 11:02 AM, Stefan Fuchs <snfu...@gmx.de> wrote:

Hi Chris,

well I think reason number 1 is not correct. The definition of self signed 
depends on who created the signing key. If you created it yourself, it is a 
self signed jar and will rightfully be blocked.
If you however obtained the signing key from a Certification Authority, that 
java accepts, it is not a self signed jar and will not be blocked.
This is a perfectly valid usecase for fxsign jar.

For the 2nd reason: I don't think many users will go modular for Webstart 
Applications. Normally you simply pack all your classes in a single big 
jar-file (and perhaps a second, if you use a preloader).
This avoids various network round trips, when the application starts and makes 
deployment much easier.


Stefan


Hi Stefan,

Yes, it is being deprecated. It will continue to function as it has. Two main 
reasons for the deprecation are:

1. Self signed jars are blocked and sign as blob is a self signed jars.

2. There will be a replacement for modules that will be better.

Chris



On Dec 12, 2016, at 11:56 PM, Stefan Fuchs <snfu...@gmx.de> wrote:

Hi,

so blog signing as deprecated.

What are the reasons for deprecating blog signing? Are there alternatives?
How do I sign a webstart application?

Stefan


David,

Please review these changes to deprecate the blob signing from the Java 
Packager.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8169443 
<https://bugs.openjdk.java.net/browse/JDK-8169443>
Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8169443/webrev.00/ 
<http://cr.openjdk.java.net/~cbensen/JDK-8169443/webrev.00/>

Chris

Re: [9] Review request: JDK-8169443 Deprecate Java Packager Blob Signing

[Stefan Fuchs]

Hi Chris,

well I think reason number 1 is not correct. The definition of self 
signed depends on who created the signing key. If you created it 
yourself, it is a self signed jar and will rightfully be blocked.
If you however obtained the signing key from a Certification Authority, 
that java accepts, it is not a self signed jar and will not be blocked.

This is a perfectly valid usecase for fxsign jar.

For the 2nd reason: I don't think many users will go modular for 
Webstart Applications. Normally you simply pack all your classes in a 
single big jar-file (and perhaps a second, if you use a preloader).
This avoids various network round trips, when the application starts and 
makes deployment much easier.



Stefan


Hi Stefan,

Yes, it is being deprecated. It will continue to function as it has. Two main 
reasons for the deprecation are:

1. Self signed jars are blocked and sign as blob is a self signed jars.

2. There will be a replacement for modules that will be better.

Chris



On Dec 12, 2016, at 11:56 PM, Stefan Fuchs <snfu...@gmx.de> wrote:

Hi,

so blog signing as deprecated.

What are the reasons for deprecating blog signing? Are there alternatives?
How do I sign a webstart application?

Stefan


David,

Please review these changes to deprecate the blob signing from the Java 
Packager.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8169443 
<https://bugs.openjdk.java.net/browse/JDK-8169443>
Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8169443/webrev.00/ 
<http://cr.openjdk.java.net/~cbensen/JDK-8169443/webrev.00/>

Chris

Re: [9] Review request: JDK-8169443 Deprecate Java Packager Blob Signing

[Stefan Fuchs]

Hi,

so blog signing as deprecated.

What are the reasons for deprecating blog signing? Are there alternatives?
How do I sign a webstart application?

Stefan


David,

Please review these changes to deprecate the blob signing from the Java 
Packager.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8169443 

Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8169443/webrev.00/ 


Chris

Re: JDK-8163078 ArrayIndexOutOfBounds is thrown in Parent.updateCachedBounds

[Stefan Fuchs]

Hi Daniel,

I mentioned it, because we got similar exceptions in our application, 
which stalled our application completely

We moved the add of the listeners around.
Luckily we could move most of the code,which added or removed listeners, 
to the application startup code.

So the problem went away.

As of JDK-8163078 I wonder, if the code below is correct, given that 
https://docs.oracle.com/javase/8/javafx/api/javafx/scene/Node.html#layoutBoundsProperty 
says:


...
"Because the computation of layoutBounds is often tied to a node's 
geometric variables, it is an error to bind any such variables to an 
expression that depends upon |layoutBounds|. For example, the x or y 
variables of a shape should never be bound to layoutBounds for the 
purpose of positioning the node. "




DoubleBinding innerWidth = 
javafx.beans.binding.Bindings.createDoubleBinding(

() -> g.layoutBoundsProperty().get().getWidth(),
g.layoutBoundsProperty());
l.endXProperty().bind(innerWidth);


-- Stefan

Hi Stefan,

>From code review it seems that this is not the case. I'll ask my team mate to 
check this programmatically just to make sure...

Note that JDK-8163078 contains a code example which reproduces the exception 
but adds and removes listeners on the JavaFX thread.

Kind regards,
Daniel


-Original Message-----
From: Stefan Fuchs [mailto:snfu...@gmx.de]
Sent: Wednesday, November 09, 2016 7:59 PM
To: Daniel Glöckner; openjfx-dev@openjdk.java.net
Subject: Re: JDK-8163078 ArrayIndexOutOfBounds is thrown in
Parent.updateCachedBounds

Hi Daniel,

are you registering or removing the listeners on  a thread other than the
JavaFX Application Thread?
I think the Observables are not thread save.


-- regards
   Stefan


Hi guys,

We're facing an exception triggered from Parent.updateCachedBounds. I've

pasted the stack trace below.

This looks very similar to https://bugs.openjdk.java.net/browse/JDK-

8163078.

We have a few listeners to layoutBounds property, similar to the reporter of

that issue. This seems to trigger the issue.

For us it's hard to reproduce this issue in our application. If the bug shows

up the result is quite disastrous though. The application freezes in this case.

Has anyone observed this bug or is aware of a workaround? P4 suggests that

it's a low priority issue with minor loss of functionality... really?

Kind regards,
Daniel

   ERROR [28.10.16 13:01:45.415] DefaultLogger uncaughtException()
java.lang.ArrayIndexOutOfBoundsException: -1
at java.util.ArrayList.elementData(Unknown Source)
at java.util.ArrayList.get(Unknown Source)
at

com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrappe
r.java:89)

at

com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.ja
va:306)

at javafx.scene.Parent.updateCachedBounds(Parent.java:1591)
at javafx.scene.Parent.recomputeBounds(Parent.java:1535)
at javafx.scene.Parent.impl_computeGeomBounds(Parent.java:1388)
at

javafx.scene.layout.Region.impl_computeGeomBounds(Region.java:3078)

at javafx.scene.Node.updateGeomBounds(Node.java:3579)
at javafx.scene.Node.getGeomBounds(Node.java:3532)
at javafx.scene.Node.getLocalBounds(Node.java:3480)
at javafx.scene.Node.updateTxBounds(Node.java:3643)
at javafx.scene.Node.getTransformedBounds(Node.java:3426)
at javafx.scene.Node.updateBounds(Node.java:559)
at javafx.scene.Parent.updateBounds(Parent.java:1719)
at javafx.scene.Parent.updateBounds(Parent.java:1717)
at javafx.scene.Parent.updateBounds(Parent.java:1717)
at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2404)
at com.sun.javafx.tk.Toolkit.lambda$runPulse$30(Toolkit.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:354)
at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:381)
at

com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:510)

at

com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:490)

at

com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$404(Quantum
Toolkit.java:319)

at

com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.jav
a:95)

at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
at

com.sun.glass.ui.win.WinApplication.lambda$null$148(WinApplication.java:19
1)

at java.lang.Thread.run(Unknown Source)

Re: JDK-8163078 ArrayIndexOutOfBounds is thrown in Parent.updateCachedBounds

[Stefan Fuchs]

Hi Daniel,

are you registering or removing the listeners on  a thread other than 
the JavaFX Application Thread?

I think the Observables are not thread save.


-- regards
 Stefan


Hi guys,

We're facing an exception triggered from Parent.updateCachedBounds. I've pasted 
the stack trace below.

This looks very similar to https://bugs.openjdk.java.net/browse/JDK-8163078.

We have a few listeners to layoutBounds property, similar to the reporter of 
that issue. This seems to trigger the issue.

For us it's hard to reproduce this issue in our application. If the bug shows 
up the result is quite disastrous though. The application freezes in this case.

Has anyone observed this bug or is aware of a workaround? P4 suggests that it's 
a low priority issue with minor loss of functionality... really?

Kind regards,
Daniel

  ERROR [28.10.16 13:01:45.415] DefaultLogger uncaughtException()
java.lang.ArrayIndexOutOfBoundsException: -1
at java.util.ArrayList.elementData(Unknown Source)
at java.util.ArrayList.get(Unknown Source)
at 
com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:89)
at 
com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:306)
at javafx.scene.Parent.updateCachedBounds(Parent.java:1591)
at javafx.scene.Parent.recomputeBounds(Parent.java:1535)
at javafx.scene.Parent.impl_computeGeomBounds(Parent.java:1388)
at javafx.scene.layout.Region.impl_computeGeomBounds(Region.java:3078)
at javafx.scene.Node.updateGeomBounds(Node.java:3579)
at javafx.scene.Node.getGeomBounds(Node.java:3532)
at javafx.scene.Node.getLocalBounds(Node.java:3480)
at javafx.scene.Node.updateTxBounds(Node.java:3643)
at javafx.scene.Node.getTransformedBounds(Node.java:3426)
at javafx.scene.Node.updateBounds(Node.java:559)
at javafx.scene.Parent.updateBounds(Parent.java:1719)
at javafx.scene.Parent.updateBounds(Parent.java:1717)
at javafx.scene.Parent.updateBounds(Parent.java:1717)
at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2404)
at com.sun.javafx.tk.Toolkit.lambda$runPulse$30(Toolkit.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:354)
at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:381)
at 
com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:510)
at 
com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:490)
at 
com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$404(QuantumToolkit.java:319)
at 
com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95)
at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
at 
com.sun.glass.ui.win.WinApplication.lambda$null$148(WinApplication.java:191)
at java.lang.Thread.run(Unknown Source)

Re: JavaFX 9: Expose PlatformImpl.runAndWait() as Platform.runAndWait()

[Stefan Fuchs]

Hi,

in my experience blocking your working thread for the JavaFX application 
thread is almost always a sign of bad application design.
You can easily deadlock your application. In our quite complex JavaFX 
Application, we could eliminate almost all of its uses.


However, in one case it is still needed: In a thread we sequentially 
prepare several images in the background, create a snapshot and save 
them as jpegs.
Here we use java.util.concurrent.CountDownLatch to simulate 
PlatformImpl.runAndWait.


final WritableImage image = new WritableImage((int) 
targetWidth, (int) targetHeight);

final CountDownLatch countDownLatch = new CountDownLatch(1);
Platform.runLater(() -> {

 /* render  and snapshot image */

 countDownLatch.countDown();
 });

boolean released = countDownLatch.await(10, TimeUnit.SECONDS);
if (!released) {
Logger.getLogger(getClass()).error("Timeout reached, while 
waiting for snapshot");

return null;
}

return image;



What I would like to see implemented is a method, we call runNowOrLater.

That is, if I'm on the JavaFX ApplicationThread execute the Runnable 
immediately, if not call Platform.runLater().
With this method I have not to worry, if I'm on the JavaFX Application 
thread or not and I avoid flooding the event queue with calls to 
Platform.runLater, that could have been executed directly.


So basically:

public static void runNowOrLater(final Runnable runnable) {
if (Platform.isFxApplicationThread()) {
runnable.run();
} else {
Platform.runLater(runnable);
}
}

-- Stefan




Hi, Kevin. Thanks for the info!

On Wed, Nov 2, 2016 at 5:36 PM, Kevin Rushforth 
wrote:


No. This isn't something we will do for JDK 9, which is feature complete
(with an exception process for critical requests, especially relating to
Jigsaw). I note in this case that it isn't clear whether we want to do this
one at all.

-- Kevin



Benjamin Gudehus wrote:


Hey!

Are there plans to expose this API [1] in JavaFX 9?

// NOTE: Add the following if we decide to expose it publicly
// public static void runAndWait(Runnable runnable) {
// PlatformImpl.runAndWait(runnable);
// }

[1] http://hg.openjdk.java.net/openjfx/9-dev/rt/file/
6edd0c3c01f4/modules/javafx.graphics/src/main/java/javafx/
application/Platform.java#l148

--Benjamin

JDK-8153350 - JavaFX webstart with javaws.exe selects wrong toolkit (unnecessary relaunch)

[Stefan Fuchs]

Hi,

it may be unrelated to these relaunches, but I have been wondering for 
awhile, what the toolkit parameter in the  ant element 
is supposed to do.


see:

https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/javafx_ant_task_reference.html#CIAGCAFH

At least in my tests changing the parameter had no effect on the 
generated jnlp file.


- Stefan

Re: Handling Enter key presses on Buttons in JavaFX

[Stefan Fuchs]

Tomas Mikula wrote:



On Tue, Jun 7, 2016 at 6:33 PM, Stefan Fuchs <snfu...@gmx.de 
<mailto:snfu...@gmx.de>> wrote:


Hi,

well, if my dialog would include  a TextField, an cancel- and an
ok-button, I would obviously want to have the TextField the
initial focus.

Once the dialog opens I can immediately type some text.
When I'm done, I hit enter to confirm the dialog.
To cancel the dialog i would hit escape.

Therefor I would prefer the following behavior.

If the focused control has an action handler attached
(cancel-Button and ok-Button), enter should trigger its action.
If the focused control has no action handler attached (TextField),
the action of the default button should be triggered.


This would be very confusing if you had two TextFields and after 
entering text into the first one the user hits Enter and the form gets 
submitted with empty second field.
Well it might be confusing, but that's how traditional Windows dialogs 
work.
You press tab to reach the second textfield. If the second textfield is 
required, the dialog should refuse to close.


See Windows 7 Taskbar properties dialog as an example.


Escape always triggers the action of the cancel-Button.

Stefan



What about forgetting the whole notion of a "default button"
and the only
effect of setting the default property to true being that the
button will
start as focused?

So I add a question:

3) Would anyone miss the "default button"?

Tomas

On Tue, Jun 7, 2016 at 5:47 PM, Jonathan Giles
<jonathan.gi...@oracle.com <mailto:jonathan.gi...@oracle.com>>
wrote:

Hi all,

One thing I've been looking into recently is the issue of
what the Enter
key should do when it is pushed with regards to buttons in
a UI where one
of those buttons is a 'default' button. There are number
of Jira issues on
this topic, and I wanted to poll the community to
understand its opinions.

The current situation is that the Enter key does not fire
the focused
Button. The Enter key is reserved for firing the 'default'
Button in the UI
(i.e. if someone has created a Button instance with the
default property
set to true). A default button is rendered slightly
differently (in Modena
it is blue for example). To fire the focused Button, the
user must press
the Space key.

Tom Schindl filed a bug (JDK-8139510) that is a good
example of the
'problem' this creates. In the bug report, a dialog is
shown to the user.
In the dialog is an OK button and a Cancel button. The OK
button has been
made the 'default' button. Regardless of which button has
focus, the Enter
key always fires the OK button. The only way to fire the
Cancel button is
via the Space key. This can be very confusing for users
who have tabbed
specifically to the 'Cancel' button and then pressed the
Enter key, only to
find they unwittingly fired the 'OK' action.

To me this has always been a little counter-intuitive,
because of my
heritage as a long-time Windows user. I believe Linux is
much the same as
Windows. For others who grew up on Mac, I'm less sure on
what people expect
(but it seems to be that the Enter key fires the default
button, not the
focused button, i.e. JavaFX current behavior matches what
is expected on OS
X).

What I'm proposing we do is to change the behavior as follows:

1) On OS X we do not change behavior at all - we keep the
current 'Enter
means default' and 'Space means focus' semantics.

2) On non-OS X platforms, we change the behavior so that
Enter (and Space)
will fire the _focused_ key, if one is focused. If no
Button is focused
(e.g. focus is in a TextField, etc), then Enter will work
as it currently
does and fire the default button, if one is specified. In
short, default
buttons will still be rendered blue to hint to the user
that they are the
default button, but they will be less prevalently fired by
Enter key
presses - only when they also have focus.

The two questions that I have are:

1) Will this confuse users when there is a behavior change
(and
presumably, this change will be made in J

Re: Java 8 updates are causing "Apps that use non-public APIs will be rejected"

[Stefan Fuchs]

Hi Kevin,

well, removing libjfxwebkit.dylib from dmg files would definitely break 
our application, as we heavily rely on WebView.
Our application is not distributed via Mac App Store, but as a download 
from our website.


I think removing libjfxwebkit.dylib from the dmg should be an opt-in for 
users, that want to upload their application to the Mac App Store.


Stefan


Yes, this is correct. We consider this only a short term workaround 
for the problem. A longer term solution will be needed that will allow 
distributing WebView applications.


Chris: is there a way to override this behavior?

-- Kevin


Dr. Michael Paus wrote:
Just in order to better understand this issue and the fix. Does this 
mean that the packager
will now ALWAYS delete the libjfxwebkit.dylib when building a DMG 
file? That would mean
that I could not bundle and distribute any application anymore for 
the Mac which uses
a WebView. Have you considered the fact that many people do bundle 
their apps but
have their own distribution channels and do not upload the apps to 
the Apple store.

There should at least be some switch to override this behavior.
Just my 2+1/2 cents.
Michael




Am 17.11.15 um 18:31 schrieb Kevin Rushforth:

[taking awt-dev off of this thread]

The fix that was put into 8u72-b02 is that the packager will no 
longer include libjfxwebkit.dylib in the packaged app. Is this not 
working correctly?


-- Kevin


Sergey Bylokhov wrote:
I think openjfx-dev@openjdk.java.net (cc) is correct place to ask 
this question.


On 16.11.15 23:10, Ondřej Kvasnovský wrote:

Hi,

We are facing to an issue with latest Java updates when we try to
release apps into Apple app store. I have described the issue 
here, with

all my findings:
http://ondrej-kvasnovsky.blogspot.com/2015/10/java-8-update-60-is-causing-apps-that.html 



In short, the issue is that we are not able to release Java app 
into app

store since 1.8_60 because it uses private API (see the link above if
you want to know how to verify that).

I spoke about this issue with Martijn Verburg and he pointed me to 
these

two issues:
https://bugs.openjdk.java.net/browse/JDK-8138650 - fixed for 8u72
https://bugs.openjdk.java.net/browse/JDK-8138652 - permanent fix 
for 9

(replace private libs with public ones)

I have downloaded that jdk1.8.0_72 b05 JDK and run (downloaded from
https://jdk8.java.net/download.html):
otool -L
/Library/Java/JavaVirtualMachines/jdk1.8.0_72.jdk/Contents/Home/jre/lib/libjfxwebkit.dylib 


| grep icu
/usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current
version 51.1.0)
And it the issue is still there, Build b05 still references 
private API.


I could even try to build and app and try to publish it for code 
review

by Apple... but since there is this reference, I do not believe it is
going to be successful.

Since this issue https://bugs.openjdk.java.net/browse/JDK-8138650 is
considered to be fixed, but it seems it is not, could someone help 
with

that?


Best wishes,
Ondrej Kvasnovsky

Re: Fwd: HostServices on Linux Ubuntu 14.04 trusty

[Stefan Fuchs]

Hi,

this works for us on all platforms, including Ubuntu 14.04

 // Desktop methods must be executed on the Swing Event Thread
 SwingUtilities.invokeLater(() -> {
 Desktop.getDesktop().open(pdfFile);
});

Regards,

Stefan

To: Rahman USTA 


My problem is getHostServices().showDocument does nothing at all in Ubuntu
10.4

Have you tried using Desktop?
as in
if(Desktop.isDesktopSupported()) Desktop.getDesktop().open(docFile);

That also works for me on Windows and Mac but causes a system crash in
Ubuntu so I am no better off.
Regards
John Maton


On Sat, Sep 26, 2015 at 11:08 AM, Rahman USTA 
wrote:


I have similar issue. When using host services to show document in
directory services, in Linux environment it shows documents in Web browser,
not in directory service.

Thanks
26 Eyl 2015 11:47 tarihinde "John Maton"  yazdı:

Good morning all,

I am using getHostServices().showDocument to display documents, such as
.pdf files.
This works find on all versions of Windows I have tested and on Apple
Macs,
but I have a test user running Linux Ubuntu 14.04 trusty where it does not
work (does nothing).
Is there some library/resource which must be installed on Ubuntu to make
HostServices work?
thanks in advance for any comments,
John Maton

Re: Private APIs not usable in Java 9?

[Stefan Fuchs]

I' ll try to compile a list of the private apis we currently use in our 
application and why.


Looking forward to using only public apis in java 9 then :-)

- Stefan


On Apr 8, 2015, at 1:52 PM, Robert Krüger krue...@lesspain.de wrote:
  our only workaround is to use private API

For the benefit of the devs on the list, could you please point out what 
private APIs you currently need to use?  That way we can make sure proper JIRAs 
are filed and we can connect those to actual real-world problems.

Re: Private APIs not usable in Java 9?

[Stefan Fuchs]

Hi,

and one more thing, I don't care about Unsafe. It can die unless it is 
involved in a workaround for the StringIndexOutOfBoundsException in 
CertUtils.checkWildcardDomain we currently see in java 8u60-ea when 
opening an https connection to our servers. Hopefully this can be fixed 
till the final release.


But in all artificial restrictions to implement your own workarounds 
using private apis its another minus on our assessment of the risks 
involved, when investing in the javafx technology. Others are the 
diminishing plugin support by browser vendors and a lack of commitment 
from oracle for growing platforms like android or ios.
On the other side of the equation is unrestricted access of the 
application to the local filesystem and cpu resources and the rich java 
apis.


Currently the equation still holds in favor of javafx, but is constantly 
evaluated.


And as you can see at http://easyprint.com we currently use different 
technologies for the online editors of our print products. Still adobe 
flash for the simple products (Print products and Textile products) and 
an new JavaFX based editor in the same design as the flash editor for 
the more complex photo products. So an html5 editor could certainly 
become the successor of the javafx editor.


Anyway I think especially for webstart applications, which have no 
control over the installed jre should have the possibility to access 
private apis. If a installed application can do it, why shouldn't the 
same be possible for a webstart application?


evil grin
Or perhaps, as it has full access to the filesystem, my application 
could start patching class files in the installed jre

/evil grin

No, I don't think that would be a good idea.


- Stefan



Hi,

you are right, there are still years to the end of public updates to 
JDK 8   We can use them to migrate to other technologies.


- Stefan


Making any theoretical flag available to the deployment side would 
entirely miss the point.


Let me be blunt -- sun.misc.Unsafe must die in a fire.  It is -- wait 
for it -- Unsafe.  It must go.  Ignore any kind of theoretical rope 
and start the path to righteousness _*/now/*_. It is still years 
until the end of public updates to JDK 8, so we have /*years */to 
work this out properly.  But sticking our heads in the collective 
sands and hoping for trivial work arounds to Unsafe is not going to 
work.  If you're using Unsafe, this is the year to explain where the 
API is broken and get it straight


Please help us kill Unsafe, kill Unsafe dead, kill Unsafe right, and 
do so as quickly as possible to the ultimate benefit of everyone.


 - Don

On 08/04/2015 2:56 PM, Stefan Fuchs wrote:

Hi,

then I can only hope, that this flag is available to webstart 
applications.
Webstart applications have no control over the installed jre. In the 
past we encountered various bugs in the jre, which required using 
internal apis for workarounds.
For example in some releases of Java 7 the swing gui thread did not 
start unless hacking internal apis (see 
https://javafx-jira.kenai.com/browse/RT-31205 for details). If such 
an error occurs again in the future and we are no longer able to 
hack around the problem, our only choice to keep our business alive, 
is to discourage users from upgrading to newer versions of the jre, 
exposing them to security risks.


- Stefan




  it's not strictly JFX-only.

Its not remotely FX only, in fact I could argue FX is not so affected,
as being relatively new it does not have 20 years of accumulation
of people using internal APIs that the larger JDK does, often 
dating from

when there were no suitable public APIs. There still remains some
of that with sun.misc.Unsafe as pointed out which will indeed be
inaccessible in modular mode. But the FX list isn't really the place
for that discussion. The jigsaw-dev is the appropriate list. FX
is simply bound by the rules that are set there.

There will be a -XX flag in JDK 9 that jigsaw provides to aid in 
the transition.


Also remember FX is open source. You can propose patches !
If there are specific APIs that are missing from FX that are suitable
to be *supported* public APIs then those could be considered here 
(this list).


-phil.

On 4/8/2015 9:28 AM, Mike Hearn wrote:

sed -i 's/private/public/g' ;)

The whole notion of a strongly enforced private keyword is IMHO 
dumb when
not using sandboxing. The number of gross hacks that occur in an 
attempt to

work around overly strict enforcement of this stuff is crazy. The D
compiler has a special flag that disables visibility enforcement when
compiling unit tests, and that's a good idea, but why not go all 
the way
and just make accessing of private state a compiler warning a la 
deprecated?


I also need to use private JFX APIs. I think any real JFX app 
does, way too
much basic stuff relies on it. Heck, the number of popular Java 
libraries
that depend on sun.misc.Unsafe is huge. If Java 9 stabs us in the 
back

Re: Private APIs not usable in Java 9?

[Stefan Fuchs]

Hi,

then I can only hope, that this flag is available to webstart applications.
Webstart applications have no control over the installed jre. In the 
past we encountered various bugs in the jre, which required using 
internal apis for workarounds.
For example in some releases of Java 7 the swing gui thread did not 
start unless hacking internal apis (see 
https://javafx-jira.kenai.com/browse/RT-31205 for details). If such an 
error occurs again in the future and we are no longer able to hack 
around the problem, our only choice to keep our business alive, is to 
discourage users from upgrading to newer versions of the jre, exposing 
them to security risks.


- Stefan




  it's not strictly JFX-only.

Its not remotely FX only, in fact I could argue FX is not so affected,
as being relatively new it does not have 20 years of accumulation
of people using internal APIs that the larger JDK does, often dating from
when there were no suitable public APIs. There still remains some
of that with sun.misc.Unsafe as pointed out which will indeed be
inaccessible in modular mode. But the FX list isn't really the place
for that discussion. The jigsaw-dev is the appropriate list. FX
is simply bound by the rules that are set there.

There will be a -XX flag in JDK 9 that jigsaw provides to aid in the 
transition.


Also remember FX is open source. You can propose patches !
If there are specific APIs that are missing from FX that are suitable
to be *supported* public APIs then those could be considered here 
(this list).


-phil.

On 4/8/2015 9:28 AM, Mike Hearn wrote:

sed -i 's/private/public/g' ;)

The whole notion of a strongly enforced private keyword is IMHO dumb 
when
not using sandboxing. The number of gross hacks that occur in an 
attempt to

work around overly strict enforcement of this stuff is crazy. The D
compiler has a special flag that disables visibility enforcement when
compiling unit tests, and that's a good idea, but why not go all the way
and just make accessing of private state a compiler warning a la 
deprecated?


I also need to use private JFX APIs. I think any real JFX app does, 
way too
much basic stuff relies on it. Heck, the number of popular Java 
libraries
that depend on sun.misc.Unsafe is huge. If Java 9 stabs us in the 
back in
this regard then I will just write a simple tool that flips 
private-public
either at the source level or via bytecode editing, and see what 
happens :-)



On Wed, Apr 8, 2015 at 6:14 PM, Robert Krüger krue...@lesspain.de 
wrote:



Hi,

I hope this is not too off-topic, because although it came up in a JFX
context it's not strictly JFX-only.

Someone from our team recently had a chat with a high-ranking regional
Oracle representative who gave a talk on the state of JFX. Our guy
explained our situation (evaluating JFX to migrate our swing-based 
product,

feeling it's in principle the right technology but still having
show-stopping limitations like RT-36215) and the Oracle guy offered to
relay our concrete questions to the right people, which he did.

The answer we got contained one thing that really was a bit of a 
shock and
I would like someone to either confirm this or clear up a 
misunderstanding.


The statement was that private APIs will not be available in JDK 9 
due to

modularity restrictions. If that is the case and we no longer have the
ability to build temporary workarounds using private APIs (which in our
case is controllable as we ship the JRE with our product), I would 
probably

have to stop any development going into the direction of JFX as we will
probably have to use 9 at some point because many things now 
scheduled for
9 will not get fixed in 8 and we will most likely still need 
workarounds

using private API, at least that's what my current experience with JFX
tells me.

Please tell me that this was a misunderstanding (maybe meant for the
general case where one does not ship the JRE) or a non-engineering 
source

that simply made mistake.

Best regards and thanks in advance,

Robert

Re: Private APIs not usable in Java 9?

[Stefan Fuchs]

Hi,

you are right, there are still years to the end of public updates to JDK 
8   We can use them to migrate to other technologies.


- Stefan


Making any theoretical flag available to the deployment side would 
entirely miss the point.


Let me be blunt -- sun.misc.Unsafe must die in a fire.  It is -- wait 
for it -- Unsafe.  It must go.  Ignore any kind of theoretical rope 
and start the path to righteousness _*/now/*_. It is still years until 
the end of public updates to JDK 8, so we have /*years */to work this 
out properly.  But sticking our heads in the collective sands and 
hoping for trivial work arounds to Unsafe is not going to work.  If 
you're using Unsafe, this is the year to explain where the API is 
broken and get it straight


Please help us kill Unsafe, kill Unsafe dead, kill Unsafe right, and 
do so as quickly as possible to the ultimate benefit of everyone.


 - Don

On 08/04/2015 2:56 PM, Stefan Fuchs wrote:

Hi,

then I can only hope, that this flag is available to webstart 
applications.
Webstart applications have no control over the installed jre. In the 
past we encountered various bugs in the jre, which required using 
internal apis for workarounds.
For example in some releases of Java 7 the swing gui thread did not 
start unless hacking internal apis (see 
https://javafx-jira.kenai.com/browse/RT-31205 for details). If such 
an error occurs again in the future and we are no longer able to hack 
around the problem, our only choice to keep our business alive, is to 
discourage users from upgrading to newer versions of the jre, 
exposing them to security risks.


- Stefan




  it's not strictly JFX-only.

Its not remotely FX only, in fact I could argue FX is not so affected,
as being relatively new it does not have 20 years of accumulation
of people using internal APIs that the larger JDK does, often dating 
from

when there were no suitable public APIs. There still remains some
of that with sun.misc.Unsafe as pointed out which will indeed be
inaccessible in modular mode. But the FX list isn't really the place
for that discussion. The jigsaw-dev is the appropriate list. FX
is simply bound by the rules that are set there.

There will be a -XX flag in JDK 9 that jigsaw provides to aid in the 
transition.


Also remember FX is open source. You can propose patches !
If there are specific APIs that are missing from FX that are suitable
to be *supported* public APIs then those could be considered here 
(this list).


-phil.

On 4/8/2015 9:28 AM, Mike Hearn wrote:

sed -i 's/private/public/g' ;)

The whole notion of a strongly enforced private keyword is IMHO 
dumb when
not using sandboxing. The number of gross hacks that occur in an 
attempt to

work around overly strict enforcement of this stuff is crazy. The D
compiler has a special flag that disables visibility enforcement when
compiling unit tests, and that's a good idea, but why not go all 
the way
and just make accessing of private state a compiler warning a la 
deprecated?


I also need to use private JFX APIs. I think any real JFX app does, 
way too
much basic stuff relies on it. Heck, the number of popular Java 
libraries
that depend on sun.misc.Unsafe is huge. If Java 9 stabs us in the 
back in
this regard then I will just write a simple tool that flips 
private-public
either at the source level or via bytecode editing, and see what 
happens :-)



On Wed, Apr 8, 2015 at 6:14 PM, Robert Krüger krue...@lesspain.de 
wrote:



Hi,

I hope this is not too off-topic, because although it came up in a 
JFX

context it's not strictly JFX-only.

Someone from our team recently had a chat with a high-ranking 
regional

Oracle representative who gave a talk on the state of JFX. Our guy
explained our situation (evaluating JFX to migrate our swing-based 
product,

feeling it's in principle the right technology but still having
show-stopping limitations like RT-36215) and the Oracle guy 
offered to

relay our concrete questions to the right people, which he did.

The answer we got contained one thing that really was a bit of a 
shock and
I would like someone to either confirm this or clear up a 
misunderstanding.


The statement was that private APIs will not be available in JDK 9 
due to
modularity restrictions. If that is the case and we no longer have 
the
ability to build temporary workarounds using private APIs (which 
in our
case is controllable as we ship the JRE with our product), I would 
probably
have to stop any development going into the direction of JFX as we 
will
probably have to use 9 at some point because many things now 
scheduled for
9 will not get fixed in 8 and we will most likely still need 
workarounds
using private API, at least that's what my current experience with 
JFX

tells me.

Please tell me that this was a misunderstanding (maybe meant for the
general case where one does not ship the JRE) or a non-engineering 
source

that simply made mistake.

Best regards and thanks in advance,

Robert

Re: Heads up... changing the rt/build/*sdk/ directory

[Stefan Fuchs]

Hi,

hm, is there now a way to crossbuild the apps like Ensemble8?
Seems to me that the apps are now always build against the default sdk.

I ask this, because for the dalvik port, we currently use a stripped 
down version of the sdk, which only contains the classes, we got working.


- Stefan


David Hill wrote:


As part of this Jira https://javafx-jira.kenai.com/browse/RT-35809, 
we are trying to make working in rt/apps easier.


To do that, we found that the only way to make the IDEs happy is be 
able to provide a common path to host build jfxrt.jar.


Currently we have:
 rt/build/${hosttype}-sdk  (rt/build/linux-sdk/...)
which requires evaluation that Netbeans does not want to do.

We do need to support cross builds, so here is what we came up with, 
explained here in the new improved comment from build.gradle


// The jfxrt task is responsible for creating the jfxrt.jar. A 
developer may
// have multiple SDK's on their system at any one time, depending 
on which

// cross compiles they have done. For example, I might have:
//  build/ios-sdk/rt/lib/ext/jfxrt.jar
//  build/armhf-sdk/rt/lib/ext/jfxrt.jar
// and so forth. The default host build will always install into 
'sdk'

// allowing for uses where a known sdk path is needed (like IDEs)
//  build/sdk/rt/lib/ext/jfxrt.jar
// This arrangement allows for multiple independent SDKs to
// exist on a developer's system.

After you sync, you will probably want to perform a clean build.

And then try out the apps, in the new easier to use format.

Note: for now, you will still need to specify the JDK for ant/nb, like 
this:

ant -Dplatforms.JDK_1.8.home=$JAVA_HOME

Re: Android replaces Dalvik with ART

[Stefan Fuchs]

Hi,

well if I understand it correctly, ART is just an Ahead of Time compiler 
like robovm. Therefore we can only hope, that they open-source it, so 
that we can use it on iOS :).


See the German article on heise:
http://www.heise.de/newsticker/meldung/Dalvik-Nachfolger-Google-laedt-zum-Testen-der-neuen-Android-Runtime-ein-2041644.html

Best regards,
Stefan



Hi,

after we reached the goal to use JavaFX on Android via Dalvik, Google announces 
the successor of Dalvik, called ART (Android Runtime). The start to move 
because of the legal issues with Java and Oracle….

http://source.android.com/devices/tech/dalvik/art.html

The question is now: How to use JFX on Android on top of ART? As I posted in my 
blog.software4java.com, we need a own JVM to embed in Android apps.

Best regards,
Tobi

Re: Why is almost everything in the API final

[Stefan Fuchs]

Mario Torre wrote:

In this case, since JavaFX is Free Software! you can actually suggest
the fix, prototype and propose the patch yourself, limiting the round
trip time substantially.

This also increases the chances to get a better fix in the end, since
more eyes are focusing on it.

Cheers,
Mario



...and then wait a year or longer until the fix is delivered with the 
next major java release.
Sorry, this is not really a viable option. Besides we still use 
webstart, so forking the jdk is not an option either.


Wouldn't it be better to allow developers to override methods at their 
own risk.
So, instead of making methods final, add a special annotation like 
@DoNotOverride to methods, which are not intended to be overridden by 
the designer of the framework.
The compiler can emit warnings, if the developer decides to override the 
method anyway.


This would clearly indicate to the developer, that his change is 
dangerous and he can not count on support from oracle, if his 
application breaks.


Yet, those that are willing to take the risks, can do something to keep 
their business alive.


Stefan

Re: Why is almost everything in the API final

[Stefan Fuchs]

Richard Bair wrote:
Wouldn't it be better to allow developers to override methods at 
their own risk.
There's no such thing. When some big customer overrides methods, we 
have no choice but to support their app for the foreseeable future. 
Which is why deprecated stuff never could be removed from the JDK as 
well. And a host of bugs won't be fixed. When the CEO of a customer 
with a major hardware contract comes knocking -- well, at that time 
you really wish you had designed the API differently.
So I just must make a major hardware contract, when I want to have a 
final keyword removed


Anyway... if its clearly documented in the API (by an annotation), that 
this method should not have been overwritten by the developers of  CEO 
of a customer with a major hardware contract and they did it anyway 
there is a strong hint, whose fault it was.


But I must admit, that it might not save you in cooperate politics.
Yet, those that are willing to take the risks, can do something to 
keep their business alive.

I would strongly recommend leaving the shared JRE install world behind.

Richard
Well, one of the main reasons to invest in JavaFX, was the ability to 
start the application web-like.


We develop a fotobook application for both business and consumer 
customers. (e.g.: available german only at 
http://www.lidl-druckservice.de/)


In the past like most of our competitors we had 2 applications. One was 
a very limited web application (html, javascript, php), the other a 
complex. full featured application in C#.


For our business it is critical to get customers to design their product 
as fast as possible. Many are unwilling or unable (e.g.: in a cooperate 
environment) to install software from semi-untrusted sources.


JavaFx provided us the chance to develop an application from the same 
codebase, which
- has full access to the filesystem (no lengthy picture uploads, before 
design can begin)

- can be started similar to a web-application (via webstart)
- can be installed as a native application
- works on all major desktop platforms
- in the future might run on tablets

Note that we leave our customers the choice between the webstart 
application and the installer version. Webstart gets increasingly 
unreliable due to problems with browsers (e.g.: Firefox currently blocks 
webstart, because of unpatched security problems) and the jre (e.g.: 
last security update killed Swing - luckily we found a workaround (no 
final method was involved :-)) and the problem is hopefully fixed with 
Java 7 u40).


If webstart is no longer a viable choice, we might have to reconsider 
our strategy and develop a html 5 application for the web and tablet use 
cases.


Stefan

Re: Why is almost everything in the API final

[Stefan Fuchs]

Fabrizio Giudici wrote:
On Mon, 02 Sep 2013 18:10:17 +0200, Christian Schudt 
christian.sch...@gmx.de wrote:


I agree with that and I also recommend to have a look at Item 17: 
Design and document for inheritance or else prohibit it from 
Effective Java.


http://uet.vnu.edu.vn/~chauttm/e-books/java/Effective.Java.2nd.Edition.May.2008.3000th.Release.pdf 



It explains the burden and dangers of non-final design quite well.


+1



-1

This applies only to the perfect (final) framework.
In other words for a framework without bugs and a framework, where all 
possible usecases are considered by its author.


I agree that there are dangers, when overwriting methods. But in my 
experience they rarely matter. Once created methods rarely change in a 
way that affects subclasses. And for major releases of the framework you 
have to test your application anyway.
If you develop a framework, where methods have complex interdependencies 
you should step back and write smaller, more manageable methods.


There are always legitimate reasons to overwrite methods. e.G.: To work 
around a bug in the framework. To trigger events, when a certain method 
has been called, to write debug info in a logfile, And no I don't 
want to roll out my own fork of jdk to my customers to do this