Re: Questions about Stream/Iterable/Files - and possibly the compiler
On Thu, 05 Nov 2015 14:28:50 +0100, Kevin Rushforth <kevin.rushfo...@oracle.com> wrote: I guess I misunderstood your question. I thought you had a question about a JavaFX API in JDK 8. This isn't the place to discuss other Java APIs. Oh well I see, my fault! I trusted the auto-completion of my email client... and I probably have to convince myself I can't use small fonts as I've been doing for years. Apologies to everyone. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: JDK 1.8.0 33/40, diacritics and file problems
Ok, I thought it was over, but it is not over yet. Many problematic file
names are now correctly handled with explicit normalisation, but I just
got:
Caused by: java.nio.file.InvalidPathException: Malformed input or input
contains unmappable characters: M?sica Antigua Eduardo Paniagua/La Vida
de Mar?a - Cantigas de las Fiestas de Santa Mar?a/1-01 Estrella Del Dia.m4a
at sun.nio.fs.UnixPath.encode(UnixPath.java:147) ~[na:1.8.0_33]
at sun.nio.fs.UnixPath.init(UnixPath.java:71) ~[na:1.8.0_33]
at sun.nio.fs.UnixFileSystem.getPath(UnixFileSystem.java:281)
~[na:1.8.0_33]
at java.nio.file.Paths.get(Paths.java:84) ~[na:1.8.0_33]
It seems that there's nothing new with the previous case:
[localhost:~/Library/Application Support/blueMarine2] fritz% grep Paniagua
repository.n3 | grep Estrella | od -c -t x1
000 \t b m m o : p a t h M ú ** s
09 62 6d 6d 6f 3a 70 61 74 68 20 22 4d c3 ba 73
[localhost:~/Library/Application Support/blueMarine2] fritz% grep Englou
repository.n3 | od -c -t x1
140a C a t h é ** d r a l e E n
61 20 43 61 74 68 c3 a9 64 72 61 6c 65 20 45 6e
I had c3a9 for é, now I have c3ba for ú. Why do I now get this
InvalidPathException?
Thanks.
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u40-b25/sun/nio/fs/UnixPath.java/
118// encodes the given path-string into a sequence of bytes
119private static byte[] encode(UnixFileSystem fs, String input) {
120SoftReferenceCharsetEncoder ref = encoder.get();
121CharsetEncoder ce = (ref != null) ? ref.get() : null;
122if (ce == null) {
123ce = Util.jnuEncoding().newEncoder()
124.onMalformedInput(CodingErrorAction.REPORT)
125.onUnmappableCharacter(CodingErrorAction.REPORT);
126encoder.set(new SoftReferenceCharsetEncoder(ce));
127}
128
129char[] ca = fs.normalizeNativePath(input.toCharArray());
130
131// size output buffer for worse-case size
132byte[] ba = new byte[(int)(ca.length *
(double)ce.maxBytesPerChar())];
133
134// encode
135ByteBuffer bb = ByteBuffer.wrap(ba);
136CharBuffer cb = CharBuffer.wrap(ca);
137ce.reset();
138CoderResult cr = ce.encode(cb, bb, true);
139boolean error;
140if (!cr.isUnderflow()) {
141error = true;
142} else {
143cr = ce.flush(bb);
144error = !cr.isUnderflow();
145}
146if (error) {
147throw new InvalidPathException(input,
148Malformed input or input contains unmappable
characters);
149}
150
151// trim result to actual length if required
152int len = bb.position();
153if (len != ba.length)
154ba = Arrays.copyOf(ba, len);
155
156return ba;
157}
--
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
We make Java work. Everywhere.
http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: JDK 1.8.0 33/40, diacritics and file problems
On Tue, 28 Apr 2015 16:40:36 +0200, Mike Hearn m...@plan99.net wrote: I thought Mac OS X has a standard normalization for unicode filenames. Linux just treats whatever it gets as bytes so it is up to the software creating the file. Am I correct? Looks like you are: https://developer.apple.com/legacy/library/technotes/tn/tn1150.html#UnicodeSubtleties So HFS+ does define a normalization form, which is apparently something very close to but not identical to NFD. Good to know. Thanks for pointing out. It's the kind of documentation I was searching for. So, NFD is the right thing, but it might not work in some cases. I hope they are corner cases not feasible with typical names of music tracks. In any case, it makes sense to have one's own Java application to provide support for getting the files, so names can be processed before they go to the filsystem. I'll probably add a WebDAV interface or such. Thanks. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: JDK 1.8.0 33/40, diacritics and file problems
On Tue, 28 Apr 2015 15:11:55 +0200, Mike Hearn m...@plan99.net wrote: They were rsynced from Mac OS X. I said *original* app. Rsync is not the original app and most likely does not attempt to re-encode or re-normalise Unicode strings. Ok. The original app is iTunes. I feared that. In the end it might be even reasonably doable, if I can take advantage of some preconditions... for instance: is it safe to assume that, given a specific instance of a filesystem, everything is encoded/normalised in the same way? Probably not. Most software that handles unicode does not do code point normalisation. Hence my emphasis on what app created the file name in the first place. Point taken, but in the end I'm using iTunes, while other people could use everything else. If it's up to the original app, this means that any user using any app can generate any encoding/normalisation. So, if I understand, there are no assumptions I can do. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: JDK 1.8.0 33/40, diacritics and file problems
On Mon, 27 Apr 2015 15:13:46 +0200, Mike Hearn m...@plan99.net wrote: Thus this may not be a bug in Java so much as a design problem/oversight with the operating systems themselves. Note that the issue you're running in to is *not* to do with encodings. It's not a UTF-8 vs UTF-16 type issue. Rather, the issue is that Unicode allows visually identical strings to be represented differently at the logical layer, using different sequences of code points. Yes, I understand. You didn't say what app originally saved the files. However, what exact They were rsynced from Mac OS X. Actually I thought it could be related to the piece of software that brought the file on the RPI, but in the end - thinking in general - a user could transfer the files in either way, and I must be able to deal with them. sequence of code points you get on disk for a given piece of human readable text can depend on things as varying as what input method editor the user typed the file name with, precisely what combination of keys they pressed and when, what libraries the app used, and so on. Yes it's a mess. If you encounter such situations frequently then your best bet may be to simply write a little wrapper that tries different normalisations until it finds one that works. I feared that. In the end it might be even reasonably doable, if I can take advantage of some preconditions... for instance: is it safe to assume that, given a specific instance of a filesystem, everything is encoded/normalised in the same way? In this case I could just run a quick test at the start of the application, find once for all the correct normalisation, and then always apply the same. Otherwise, I have to try all the combinations for every file that I open... -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
JDK 1.8.0 33/40, diacritics and file problems
Ok, I've run into many problems in the past with diacritics, as there were some JDK problems, but I supposed they were all fixed today. But perhaps there's something I'm not understanding. I've several files with diacritics in their name, let's say e.g. La Cathédrale Engloutie.m4a. A catalog contains their names, and it has been prepared on Mac OS X, JDK 1.8.0_40 and saved with UTF-8 encoding. The catalog is read, of course specifying UTF-8 as encoding, on the Raspberry PI Rasbian with JDK 1.8.0_33. Everything is correct as I see the proper characters in the UI and logfiles. The problem arises when I try to open a file with diacritics (this doesn't happen with all files with diacritics in their name, only with some): I get an exception because the file name is not found (both with io and nio). Thanks to some suggestions, I made it work by passing the file name through Paths.get(Normalizer.normalize(path.toString(), NFD)). This transforms the initial encoding for the é from c3 a9 (doesn't work) to 65 cc 81. Now, first I don't understand why I have to take care of this. I'm aware that different file systems use different encodings, but I supposed that all the conversions were done by the JVM. BTW, both systems are configured with: LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8 The Java system properties are: file.encoding: UTF-8 file.encoding.pkg: sun.io sun.io.unicode.encoding: UnicodeLittle (ARM) sun.io.unicode.encoding: UnicodeBig (Mac) sun.jnu.encoding: UTF-8 The files on the ARM were rsynced from the Mac. I'm not sure that LC_ALL/LANG/whatever were already set when the rsync was performed. If it's correct that I have to deal with it, is there any official documentation I can reference? BTW, I'm not aware of why the NFD normalisation is the one who works, and not one of the other three. Thanks. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: JavaFX JIRA issues moving to JBS
On Thu, 16 Apr 2015 11:57:10 +0200, Robert Krüger krue...@lesspain.de wrote: Please note that the main criticism is not that it becomes a problem for code contributors but for people submitting qualified bug reports including reproducible test cases, concrete measurements etc. or contribute these kind of things to issues opened by other people by submitting qualified comments thus creating value. Exactly. Resuming my previous points, one of the most valuables sources of bug tracking (when a quality filter has been applied) are developers who strategically use the technology evesomewhere. When talking of general FLOSS (or even non FLOSS, but with public issue tracking) I constantly push people to be active and file issues by themselves (I sometimes support them on how to prepare a good report, hoping that after a bootstrap they become independent). Any obstacle in this path ends up in people working around bugs. Which is a pity, because this means that many bugs aren't fixed, people waste efforts in duplicating workarounds (*) and in the long run the technology might take a reputation of being problematic to use. (*) That's why commenting is important. It's quite frequent that when I find a problem with a technology and google around I end up to an issue tracker and find some people who at least was able to provide an effective workaround that, even though not perfectly, make me able to avoid a blocking point, waiting for an issue to be corrected. This job could be eventually dealt with a properly indexed forum. Adding points to the brainstorming section... what about a public, separate issue tracker to leave in the wild? Perhaps not officially maintained by Oracle, to avoid any criticism. The idea is that in this public, restrictionless Jira it's up to the community to apply the proper policy to keep noise low. From this public instance, selected issues complying with some well defined requirements could be later moved to the official Jira. This would require some involvement by the community (I mean, more than just describing bugs and providing patches: it would have a role in moderating the public instance, and I understand this is definitely much more boring than grokking code), but I think this is somewhat unavoidable if Oracle doesn' want to pay the costs for this activity. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: JavaFX JIRA issues moving to JBS
On Thu, 16 Apr 2015 14:01:03 +0200, Kevin Rushforth kevin.rushfo...@oracle.com wrote: Exactly. This is an OpenJDK policy issue. Dalibor posted the link to the discuss alias that you might send an e-mail to. So, ok, this specific discussion should move there. I subscribed to the ml pointed by Dalibor, all the one involved please do the same, and then let's start there. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: JavaFX JIRA issues moving to JBS
On Wed, 15 Apr 2015 18:31:56 +0200, Ryan Jaeb r...@jaeb.ca wrote: If someone submits a decent quality bug report to the forum, they could be invited to use JBA. ... You could probably even come up with a strategy for letting the community nominate people for JBS invites so the developers wouldn't have to sift through the forums looking for users that would make good JBS participants. Good points. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: JavaFX JIRA issues moving to JBS
On Wed, 15 Apr 2015 17:55:19 +0200, Robert Krüger krue...@lesspain.de wrote: Understandable. IMHO a certain seriousness threshold to reduce the noise makes sense. I was thinking on a score system such as the one at StackOverflow, but I'm not aware of any support of Atlassian. What if you at least had a policy where someone in your team can propose people they know from the mailing list for a while for accounts? I don't think what's needed is to have a completely open system with one-click self-registration but don't draw the line where you draw it now, which means you're missing qualified input from people who are ready to invest qualified time (e.g. to build test cases and good descriptions of issues) but do not submit patches. I would add that having a corporate collective account could probably help. I'm thinking of a case in which there are a couple of dozen developers from the same corporate that could share the same email alias. Even in this case self-subscribing wouldn't be needed, actually it might make sense to have a control process to be sure that the corporate account is official, I mean the corporate is in charge for it. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: JavaFX JIRA issues moving to JBS
I had not realized that ... Just be safe that everybody here is aligned to the focus of the discussion... As I previously said, I think the problem lies with the access policy. From the JBS official page: Account Eligibility OpenJDK Roles, Groups, and Projects are explained in the OpenJDK Bylaws. This JBS guide will use terms defined in the bylaws; the bylaws should be consulted for details. An individual with at least one OpenJDK Project role of Author or higher has sufficient cause to get a JBS account. A JBS account grants an individual general read and write access to issues, including the ability to file new issues, transitioning issues among the states of the workflow, adding comments, changing field values (including adding and removing labels). The holder of a JBS account can also be the assignee of an issue. A user's JBS username is his or her OpenJDK name. The password reset page can be used both to reset a lost password and to establish a an initial password. At the time of launch, self-service account creation is not supported. Users without an account can browse JBS anonymously or use bugs.sun.com to view a time-delayed and simplified snapshot of bug state. Users without an account can also use bugs.sun.com to submit an issue. When such an issue is submitted, a record is created in the Java Incidents (JI) project in JBS; at the time of launch, the JI project is not publicly visible. Issues in the JI project have an identifier like JI-9XX, where the numeric portion corresponds to the bug identifier sent back to the submitter. After an initial triage process, if the incidents needs further review, it can be transferred to be an issue in the JDK project. When such a transfer occurs, the issue gets a new identifier in the JDK project (JDK-8YY) but references to the original JI-9XX number will be redirected. There are a few points to discuss, and sure everybody has his own priority. For me, one of the most important ones is the capability to comment. For instance, today I can go here (issue picked at random) https://javafx-jira.kenai.com/browse/RT-30705 and add a comment, because perhaps I've run into the issue and I have something to add. If I don't have an account, because it's my first time, I can istantly create one at Kenai. I have a few customers using JavaFX (as well as many other FLOSS projects) and sometimes they run into an issue; I encourage them to directly login and report/comment. From what I see, JBS still doesn't support self-creation of accounts. I don't have one, if I remember well, because I don't have any role in OpenJDK projects. For the kind of job I do, that is a consultant focused on Java, perhaps I can ask for one and perhaps Oracle would grant one (to be verified). But I don't think this would apply for a common employee of a corporate that, among other things, also develops in Java; not mentioning that not having the possibility of instantly signing in is not good, and would discourage almost everybody I know. The bridge offered by bugs.sun.com is cumbersome too. In any case, this is completely different from any other FLOSS project around, where access to the issue tracker is immediate and easy. I think this expands the point that some earlier mentioned about being a user vs a developer of OpenJDK. I understand that, being Java so popular, Oracle might fear some kind of massive, low-level posting of issues, that would be expensive to manage. If this is the case, let's discuss it. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: Media API question regarding metadata retrieval
On Wed, 01 Apr 2015 22:50:44 +0200, Scott Palmer swpal...@gmail.com wrote: I seems like a decent compromise to defer to the native platform code that will ultimately be used to process the file anyway. It seems a little heavy, but the alternative is perhaps bloating the JavaFX API. It likely makes more sense to use the MediaInfo project with some JNA bindings (you can probably find either JNI or JNA bindings on the web) if you need access to the metadata: https://mediaarea.net/nn/MediaInfo I keep thinking a pure java port of MediaInfo would be cool... but probably not worth the time :-) There are some pure Java media parsers around; the problem is that one should check whether they are complete, that is whether they support all the kinds of media one needs. For instance, at the moment I'm using Jaudiotagger. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: Questions/possible bugs about JDK 1.8.0 + OpenJFK on the PI 2
On Wed, 25 Mar 2015 21:04:28 +0100, David Hill david.h...@oracle.com wrote: On 3/25/15, 3:28 PM, Fabrizio Giudici wrote: Two possibilities - Did you up the allocated vram ? (I think this might not be a factor on newer Raspbians, they were going to a dynamic split). Does X11 fill the full screen when it runs ? It would be interesting to know what FX thinks the screen is sized at, -Dprism.verbose=true Ok, I think I got it. Looking at /boot/config.txt I saw: # NOOBS Auto-generated Settings: hdmi_force_hotplug=1 config_hdmi_boost=4 overscan_left=24 overscan_right=24 overscan_top=16 overscan_bottom=16 disable_overscan=1 gpu_mem=256 I commented out all the overscan_* and set disable_overscan=0. Launching startx, I see that the graphics covers the full screen (some pixels are clipped out, so X11 would really require some overscan, even though a smaller amount). But now JavaFX covers the full screen. Also for JavaFX there are some pixels clipped out. This is not a problem for me: I think that it's up to the JavaFX application to correct for overscan, by simply putting some space around the true contents. So, the thing now is fine for me. But I think that there is a real bug: JavaFX is not correctly computing the screen area when there's that overscan settings. It's probably a low priority one - maybe it would just make sense to warn people about it. The mouse is ok, it was probably a connection fault. The keyboard navigation of buttons is still not working - still investigating. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: Questions/possible bugs about JDK 1.8.0 + OpenJFK on the PI 2
On Thu, 26 Mar 2015 19:40:41 +0100, Fabrizio Giudici fabrizio.giud...@tidalwave.it wrote: The mouse is ok, it was probably a connection fault. The keyboard navigation of buttons is still not working - still investigating. The keyboard is definitely not working with my app, even with a simple TextField. It does work with Ensemble8 and the same jre. My app works fine in Mac OS X. Sounds tricky... Is there any logging option I can activate to investigate whether keystrokes are just not received, or they get lost somewhere? -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Questions/possible bugs about JDK 1.8.0 + OpenJFK on the PI 2
Hello. I got my PI 2 since a few days and I'd like to develop in JavaFX on it. I've read the January announcement from Oracle about the end of support for JavaFX... sigh. In these days I'm just checking whether the development with JavaFX on the PI 2 is feasable or a pain in the ass. On this purpose, I've prepared a small application with just a couple of screens and testing deployment. First, I'd like to thank a lot those who are working for the OpenJFX port as a patch for the missing Oracle part. Following the simple instructions to patch the Oracle JDK 1.8.0_33 I've been able to build a somewhat working system. Now, the problems. I'm testing with two JDKs: * the one pre-installed in Raspbian: java.version: 1.8.0 + javafx.runtime.version: 8.0.0-b132 * the patched one: java.version: 1.8.0_33 + javafx.runtime.version: 8.0.60-ea (Wed Mar 25 00:04:40 UTC 2015) First problem. It occurs with both JDKs. My application starts at fullscreen, but it isn't really covering the whole screen. It is actually smaller. There's a strip at the right and the bottom side where I can see a few columns/rows of characters from the underlying console. Is there any bug in this area? Workarounds? Second problem. It only happens with the patched JDK. When I run my app from the command line I see: Udev: Failed to write to /sys/class/input/mice/uevent Check that you have permission to access input devices Udev: Failed to write to /sys/class/input/event0/uevent Check that you have permission to access input devices Udev: Failed to write to /sys/class/input/event1/uevent Check that you have permission to access input devices Udev: Failed to write to /sys/class/input/input0/uevent Check that you have permission to access input devices Udev: Failed to write to /sys/class/input/input1/uevent Check that you have permission to access input devices I'm aware that Raspbian requires certain groups for accessing some features. I'm running as the 'fritz' user in the following groups: fritz adm dialout cdrom sudo audio video plugdev games users netdev input pi spi gpio So it seems that there should be any problem. Actually, the problem doesn't occur with the pre-installed JDK. Of course, what's happen is that I can't control my app with neither the keyboard nor the mouse. Third problem, still with the patched JDK. Perhaps it's just a consequence of the second. I tried to run as sudo: while I don't see the error messages, still I can't control the application. Actually I don't even see the mouse pointer. Perhaps is it just this bug: http://stackoverflow.com/questions/26296805/ ? I've seen it with JDK 1.8.0 build 25.0-b70 on my Mac OS X, and disappeared after I've upgraded to 1.8.0_40. Actually at present time I can test some more with the pre-installed JDK, but obviously I'd like to move to the latest available one as soon as possible. Please also let me know how I can help in the investigations. Thanks. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: Questions/possible bugs about JDK 1.8.0 + OpenJFK on the PI 2
On Wed, 25 Mar 2015 19:33:09 +0100, Kevin Rushforth kevin.rushfo...@oracle.com wrote: Jasper just ran the 8u33 + javafx 8u60-ea earlier this week with no problems -- Ensemble8 demo just came up and ran fine. He did mention that he runs as root, so didn't run into the problem you are seeing with accessing /dev. You might try running as root or else changing the permissions. As I wrote, my application runs at full screen (stage.setFullScreen(true)), while Ensemble8 doesn't. Anyway, if I run Ensemble8 and press the maximise button, the window doesn't grow to the whole screen, but leaves some room at the right and bottom border, just like I see my app. Also - I changed Ensemble8 to run at fullscreen as follows: % diff ./src/EnsembleFullScreen/src/ensemble/Ensemble2.java ./src/Ensemble/src/ensemble/Ensemble2.java 124c124 //stage.setTitle(Ensemble); --- stage.setTitle(Ensemble); 138,140c138 //stage.initStyle(StageStyle.UNDECORATED); stage.setFullScreen(true); System.err.println(full screen); --- stage.initStyle(StageStyle.UNDECORATED); Same video problems: it doesn't cover all the screen. I can also see that the upper left corner of the application is off-screen (the whole window seems to be shifted upward and leftward). It's not a monitor overscan problem (at least, not only an overscan problem), since I can see the characters in the underlying console at their right place. What I see is that keyboard navigation and mouse work with Ensemble2 modified at full-screen, so I'll look again at my code about this issue. If you want some more info, or screenshots, let me know. My app is also open source, so I can share the code, but I need to fix a couple of things so it doesn't depend on Maven snapshot artifacts (also, my Hudson is in maintenance and I can't confirm the app can be compiled from the outside world). I'll alter post to oss.sonatype.org the binaries, so if someone wants to try it, just let me know. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: Questions/possible bugs about JDK 1.8.0 + OpenJFK on the PI 2
If somebody wants to try, the binaries zip of my app is here (126M, with embedded jre): https://oss.sonatype.org/content/repositories/snapshots/it/tidalwave/bluemarine2/bluemarine2-linux-armv6-embedded-jre/1.0-ALPHA-1-SNAPSHOT/bluemarine2-linux-armv6-embedded-jre-1.0-ALPHA-1-20150325.201531-2-bin.zip The sources are here (still with possibly troubled snapshots dependencies): https://bitbucket.org/tidalwave/bluemarine2-src/ Changeset from which I build the binaries is 22ccace8a18b -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: Questions/possible bugs about JDK 1.8.0 + OpenJFK on the PI 2
On Wed, 25 Mar 2015 21:04:28 +0100, David Hill david.h...@oracle.com wrote: On 3/25/15, 3:28 PM, Fabrizio Giudici wrote: Two possibilities - Did you up the allocated vram ? (I think this might not be a factor on newer Raspbians, they were going to a dynamic split). Yes. It just didn't work with the standard setting. Does X11 fill the full screen when it runs ? Yes. It covers the same area as the text console. There's quite a thick black border around, but it's perfectly symmetrical and empty. It would be interesting to know what FX thinks the screen is sized at, -Dprism.verbose=true Full log from launch to main screen rendered below (including my own app logging, but it dumps the java properties and could be useful). Prism pipeline init order: es2 sw Using native-based Pisces rasterizer Using dirty region optimizations Using system sized mask for primitives Not forcing power of 2 sizes for textures Using hardware CLAMP_TO_ZERO mode Opting in for HiDPI pixel scaling Prism pipeline name = com.sun.prism.es2.ES2Pipeline Loading ES2 native library ... prism_es2_monocle succeeded. GLFactory using com.sun.prism.es2.MonocleGLFactory (X) Got class = class com.sun.prism.es2.ES2Pipeline Initialized prism pipeline: com.sun.prism.es2.ES2Pipeline Maximum supported texture size: 2048 Non power of two texture support = true Maximum number of vertex attributes = 8 Maximum number of uniform vertex components = 544 Maximum number of uniform fragment components = 544 Maximum number of varying components = 32 Maximum number of texture units usable in a vertex shader = 8 Maximum number of texture units usable in a fragment shader = 8 Graphics Vendor: Broadcom Renderer: VideoCore IV HW Version: OpenGL ES 2.0 vsync: true vpipe: true 20:14:45.509 [JavaFX-Launcher ] INFO it.tidalwave.ui.javafx.JavaFXApplicationWithSplash - init() 20:14:47.310 [X Application Thread] INFO it.tidalwave.ui.javafx.JavaFXApplicationWithSplash - start(javafx.stage.Stage@1e9696b) 20:14:49.113 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - awt.toolkit: sun.awt.X11.XToolkit 20:14:49.115 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - com.sun.javafx.gestures.rotate: true 20:14:49.116 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - com.sun.javafx.gestures.scroll: true 20:14:49.117 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - com.sun.javafx.gestures.zoom: true 20:14:49.118 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - com.sun.javafx.isEmbedded: true 20:14:49.119 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - com.sun.javafx.scene.control.skin.FXVK.cache: true 20:14:49.120 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - doNativeComposite: true 20:14:49.122 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - embedded: monocle 20:14:49.122 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - file.encoding: ANSI_X3.4-1968 20:14:49.123 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - file.encoding.pkg: sun.io 20:14:49.124 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - file.separator: / 20:14:49.125 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - glass.platform: Monocle 20:14:49.126 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - java.awt.graphicsenv: sun.awt.X11GraphicsEnvironment 20:14:49.127 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - java.awt.printerjob: sun.print.PSPrinterJob 20:14:49.128 [pool-2-thread-1 ] DEBUG it.tidalwave.ui.javafx.JavaFXSpringApplication - java.class.path: ./lib/aopalliance-1.0.jar:./lib/aquafx-0.1.jar:./lib/aspectjrt-1.8.1.jar:./lib/aspectjweaver-1.8.1.jar:./lib/bsh-2.0b4.jar:./lib/hamcrest-all-1.3.jar:./lib/it-tidalwave-bluemarine2-application-javafx-1.0-ALPHA-1-SNAPSHOT.jar:./lib/it-tidalwave-bluemarine2-model-1.0-ALPHA-1-SNAPSHOT.jar:./lib/it-tidalwave-bluemarine2-ui-1.0-ALPHA-1-SNAPSHOT.jar:./lib/it-tidalwave-bluemarine2-ui-javafx-1.0-ALPHA-1-SNAPSHOT.jar:./lib/it-tidalwave-messagebus-1.0.21-SNAPSHOT.jar:./lib/it-tidalwave-messagebus-spring-1.0.21-SNAPSHOT.jar:./lib/it-tidalwave-role-1.0.3-SNAPSHOT.jar:./lib/it-tidalwave-role-spring-1.0.45-SNAPSHOT.jar:./lib/it-tidalwave-role-ui-javafx-1.0-ALPHA-1-SNAPSHOT.jar:./lib/it-tidalwave-util-1.12.28-SNAPSHOT.jar:./lib/it-tidalwave-util-java8supplement-1.12-SNAPSHOT.jar:./lib/it-tidalwave-util-logging-1.1.42-SNAPSHOT.jar:./lib/it-tidalwave-util-test-1.0.36-SNAPSHOT.jar:./lib/javax.inject-1.jar:./lib/jcl-over-slf4j-1.7.5.jar:./lib/jcommander-1.27.jar:./lib/jsr305-1.3.7.jar:./lib/junit-4.7.j ar
Re: libjfxmedia.so on armv6hf?
On Tue, 17 Mar 2015 00:27:53 +0100, Kevin Rushforth kevin.rushfo...@oracle.com wrote: Unlikely without help from the community, given that FX itself is no longer supported on linux-arm. We currently have no plan to add such support. Quite annoying stuff. BTW, I've just read http://www.raspberrypi.org/forums/viewtopic.php?f=81t=97367 It's quite curious. I've just ordered a Raspberry Pi 2 and was planning about writing a media center prototype with some ideas in mind. In the past years I did lots of stuff with imaging and media, and was with Swing. I struggled with tons of incomplete features in the imaging and movie APIs, lots of additional libraries in order to have a decent modern UI (with animations and such), because Java didn't offer them out of the box. In the end I quit because it was frustrating to always be forced to fix something at the basics level. I mean, I just wanted to focus on the application. Now, fast forward some years and we have that Java FX, with bells and whistles. I supposed I could at last enjoy writing an app on the RPI without worrying about missing, incomplete, partially unsupported stuff, but I was wrong. It seems that no matter Sun or Oracle, there's a sort of curse preventing the Java ecosystem to fully work on the reference rich UI hardware. Sorry for the rant, nothing against people of course, but that's just my feelings at the moment. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: JavaFX (1.7.0_45) and Applet: problem with layout
On Tue, 16 Sep 2014 11:55:26 +0200, Fabrizio Giudici fabrizio.giud...@tidalwave.it wrote: Hello. A customer submitted me a problem concerning a Java WebStart applet made with JavaFX (JDK 1.7.0_45): the thing works, but at the beginning the rendering in the browser is such that a number of pixels are off the rendered area at the right and bottom borders. The problem happens with Internet Explorer and Firefox on Windows 8, even though by different pixel amounts. Just clicking with the mouse anywhere cause a re-computation of the layout so everything is ok. I can't review all of the code, so I focused on the FXML and worked on it by removing unneeded stuff and making sure that PREFERRED_SIZE is used whenever it makes sense. But the problem is always there. At this point, I think that a reasonable workaround would be to force a layout re-computation just after the initialization... but how am I supposed to do that? On a second instance, I'd like to understand what's wrong. Bump... anyone on this? Thanks. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
JavaFX (1.7.0_45) and Applet: problem with layout
Hello. A customer submitted me a problem concerning a Java WebStart applet made with JavaFX (JDK 1.7.0_45): the thing works, but at the beginning the rendering in the browser is such that a number of pixels are off the rendered area at the right and bottom borders. The problem happens with Internet Explorer and Firefox on Windows 8, even though by different pixel amounts. Just clicking with the mouse anywhere cause a re-computation of the layout so everything is ok. I can't review all of the code, so I focused on the FXML and worked on it by removing unneeded stuff and making sure that PREFERRED_SIZE is used whenever it makes sense. But the problem is always there. At this point, I think that a reasonable workaround would be to force a layout re-computation just after the initialization... but how am I supposed to do that? On a second instance, I'd like to understand what's wrong. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: JavaFX (1.7.0_45) and Applet: problem with layout
On Tue, 16 Sep 2014 11:55:26 +0200, Fabrizio Giudici fabrizio.giud...@tidalwave.it wrote: it by removing unneeded stuff and making sure that PREFERRED_SIZE is Correction: I meant USE_COMPUTED_SIZE. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: OT: Netbeans ported to JFX?
On Thu, 10 Jul 2014 16:23:43 +0200, Jeff Martin j...@reportmill.com wrote: I agree that Oracle should have an in-house apps team to create a few real world apps. Sun's lack of this helped marginalize Java Client and Corporates should only do what concerns their business and AFAIK Oracle's business was not to create real world apps (I mean, with the exception of IDEs or other apps for the management of Oracle apps). A technology owner, usually, when tries to create a real world app only creates a demonstrator of a real world app, which doesn't have any success. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: OT: Netbeans ported to JFX?
On Thu, 10 Jul 2014 16:42:31 +0200, Doug Schaefer dschae...@qnx.com wrote: Fair enough, but neither of them built an IDE using Java that would benefit from JavaFX at the moment. In ant case Microsoft and Apple business is to also to produce applications - they have quite an experience in targeting end-users (Microsoft jokes apart). Oracle doesn't. This doesn't mean that they couldn't. But should they do that, it should be a business decision, which means also to update their business plans, not just a way to push their technology. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: JFXPanel vs. real world usage
On Thu, 24 Oct 2013 19:20:42 +0200, Pedro Duque Vieira pedro.duquevie...@gmail.com wrote: Hi Matthias, I don't see any problems with performance and I've been using this a lot. Best regards, +1 for me. Of course, it depends a lot on the usage and unfortunately I can't comment further because my experience is from a closed-source project of a customer. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: Moving on (forked from Re: JavaOne roundup?)
On Mon, 30 Sep 2013 11:48:10 +0200, Felix Bembrick felix.bembr...@gmail.com wrote: I urge everyone *not* to walk away from JavaFX, at least not yet. As has been pointed out, there were several sessions scheduled for J1 relating to JavaFX on mobiles and tablets that were only cancelled at the very last minute. I see this as a definite positive. To me that says that they truly believed they would be able to have something for those sessions but for whatever reason were not able to get across the finish line. I don't know much about J1, as I've still to catch up. But I noted, in the past weeks, a swept of re-scheduling of bugs (were planned for JDK8, now are for Van Ness (*)). I suppose that might have had some impact. (*) Please, can somebody clarify when Van Ness is expected to happen, including any eventual re-scheduling? Thanks. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: CNET: Google begins barring browser plug-ins from Chrome
On Wed, 25 Sep 2013 09:55:39 +0200, Tom Eugelink t...@tbee.org wrote: Nope, just too busy, period :-) I have an applet that I use for hour registration. It has been working for me for years, and it would be a real bummer if that needs to be rewritten (unnecessary hours). I'd probably consider using a different browser. But I also read in the article that Google did something to the Flash player to make it run on the other API. Maybe Java... From what I understand Java WebStart should still work, just not supporting applet embedded in the page. Applications launched by WebStart should be unaffected. Or am I missing something? -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: Why is almost everything in the API final
On Tue, 03 Sep 2013 07:16:06 +0200, Tom Eugelink t...@tbee.org wrote: AFAIK there was never a framework that used final a lot, so time will tell if the choice was right. Swing and the JDK made it this far. But The NetBeans Platform API does use final a lot for the same rationale we're discussing now. I'm suspecting the choice may have been made motivated more from the perspective of the developers of the framework (a few people) and not as much from the users (many people). That's true, but you're misusing the perspective. Many users would only see some minor impact of extending a class, while the few developers would see the accumulation of a huge number of problems because those minor things are multiplied by the large number of users. It's precisely by putting oneself in the perspective of the developers that 'final' makes sense. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: Why is almost everything in the API final
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 -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: JavaFX Sightings (forked from Re: Can JavaFX do CAD?)
On Wed, 07 Aug 2013 16:54:37 +0200, Mark Fortner phidia...@gmail.com wrote: The showcase sounds like a good idea, but if the goal is to be able to use it to convince people that JavaFX is a viable platform, wouldn't it be better if you could download and try the application (maybe even web start it)? After all, the proof of the pudding is in the eating. Guys, if the application is available, this is a plus, but there's plenty of non-distributable applications. Even better if the application is open source, so people can check it out, but not all applications are open source. When the interview include the developers, who talk also in name of the company, this is very valuable information. So, let's just provide the best information possible, case by case. Rich client apps are strong mostly in the industry, and most of the stuff here is proprietary. Anyway, let's not forget that in most cases decisions about which technology to use are done and/or approved by managers, and they usually don't download and run applications. They are assured if they see a widespread adoption of the technology. Bad or good, they reason in terms of powerpoint slides and diagrams about the market share. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: Can JavaFX do CAD?
On Sat, 27 Jul 2013 09:12:35 +0200, Yennick Trevels yennick.trev...@gmail.com wrote: @John: On the JavaFx community site they have a section with references to real world usecases. http://www.oracle.com/technetwork/java/javafx/community/index.html If that five/six cases are all that is published now, as it's my understanding, it's not the kind of gallery of use cases I've in mind and by far it's not enough. Too few and mostly too simple - I mean, they are really cool applications and they deliver, but you don't see the push the edge stuff you'd like to see. Again, please compare with the NetBeans or Eclipse Platform showcases. Of course, I know that those Platforms are much older and established than JavaFX, so I don't expect the same numbers... but at least one order of magnitude more. Paradoxically, so few showcases of a technology that is around since 2007 might even deliver the opposite message that we want. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Detecting when a TreeItem is no more used
Hello. I have a library which creates a hierarchy of TreeItems out of a data model, and of course the root TreeItem is later attached to a TreeView. I need to know when those TreeItems are no more used, so I can free some resources in the data model. I supposed that TreeItem had a life-cycle method or an event that notifies its destruction, but I seem unable to find it. At the moment it sounds as the solution is rather to watch for the TreeView and detect when it is destroyed, or its root property is changed, and then decide that the previously attached TreeView is no more used. It would be fine for me, but I'm just trying to understand whether this is the simpler, most appropriate approach. Thanks. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: Detecting when a TreeItem is no more used
On Fri, 26 Jul 2013 13:47:50 +0200, Tom Schindl tom.schi...@bestsolution.at wrote: Not sure but what is reused is the TreeCell, the TreeItem is not freed and has to exists as long as you show the tree! TreeItem... i1 = new TreeItem...(); treeView.setRoot(i1); TreeItem... i2 = new TreeItem...(); treeView.setRoot(i2); I'd say that when you change the root to i2, i1 is no more needed, right? -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: Disabling JavaFX minimise/maximise/etc buttons
On Wed, 24 Jul 2013 09:59:07 +0200, Artem Ananiev artem.anan...@oracle.com wrote: On 7/24/2013 12:45 AM, Fabrizio Giudici wrote: On Tue, 23 Jul 2013 22:34:48 +0200, Anthony Petrov anthony.pet...@oracle.com wrote: I don't agree. IMO, it's annoying when I'm able to resize a window freely but unable to maximize it. This just doesn't look logical or convenient. I'm with Werner here. Maximixing a dialog is usually ugly from the aesthetic point of view, but sometimes I'm annoyed by dialogs that are just a bit too narrow for entering a text, or something else (incidentally, e.g. the Java control panel seems to be filled with non-resizable windows designed just to annoy people :-). I'd just like to stretch them a bit. Could you identify the boundary between just making a window larger and maximizing it? I can't. What about Windows 7 snap feature, is it resizing or maximizing? In other words, my understanding is that if a window is resizable, it should be maximizable as well. However, as I wrote in my previous emails, sometimes it's out of Java control: we can say if a window should be resizable or not, and the platform decides if it is minimizable/maximizable or not. Thanks, The boundary is when you feel the look is ugly, thus it's related to the % of size increase. That's why snap is not a problem. Of course I can't tell you a precise threshold, it depends. But it's ok when I just enlarge a window because it lacks the room for say 5-10 characters of input, while I don't like to see a maximized window where there's just a small content and large amounts of empty space. Also: sometimes you want a modal, that is the main window is blocked, but perhaps you need to read something in the main window, that would help to answer to the question of the modal. If the modal is just resizable (and draggable) there's no problem. If the modal has been maximized, you can't. Of course, it's up to the user to avoid maximizing it if it's a problem - there are no showstoppers here. But UI design is all about driving the user in the right direction and minimizing the number of interaction items needed to accomplish a task. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: Disabling JavaFX minimise/maximise/etc buttons
On Wed, 24 Jul 2013 12:52:27 +0200, Anthony Petrov anthony.pet...@oracle.com wrote: Otherwise, it's up to the user to maximize/unmaximize the dialog, or only resize it whenever and however it is needed/convenient at the moment. As I said, to me UI design is also constraining the user in the set of meaningful actions. The more useless freedom you give him, the more damage he will do :-) -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: Disabling JavaFX minimise/maximise/etc buttons
On Tue, 23 Jul 2013 22:34:48 +0200, Anthony Petrov anthony.pet...@oracle.com wrote: I don't agree. IMO, it's annoying when I'm able to resize a window freely but unable to maximize it. This just doesn't look logical or convenient. I'm with Werner here. Maximixing a dialog is usually ugly from the aesthetic point of view, but sometimes I'm annoyed by dialogs that are just a bit too narrow for entering a text, or something else (incidentally, e.g. the Java control panel seems to be filled with non-resizable windows designed just to annoy people :-). I'd just like to stretch them a bit. But I don't know how this stands with the various operating system design guidelines. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
JavaFX app with Spring doesn't terminate on Mac OS X with Cmd-Q
Hello.
I have a JavaFX app that uses Spring to instantiate a number of services
and presentation controllers. I think it's relevant to mention that among
other services there's Jetty, an embedded web server that starts listening
to a socket with its own threads. The Spring ApplicationContext is
initialized in background after init() is called; and it also uses
applicationContext.registerShutdownHook(). When I run the application in
development mode (with Maven, from the terminal) or I launch the Java stub
inside the bundled .app from the terminal (so the process is bound to the
terminal) and I hit Ctrl-C, the application properly quits (with the
Spring Application Context properly shutting down everything). When I
launch the bundled .app and I press Cmd-Q, the window closes, but the
application lingers somewhere (e.g. I see it in running processes). I have
to force quit it. Platform.setImplicitExit(true) doesn't make any
difference.
I expected that Cmd-Q called System.exit() and the Spring
ApplicationContext just had its opportunity to orderly quit thanks to the
shutdown hook. Instead, I see that the ApplicationContext stays alive and
probably the threads started by some services keep the application running.
I've found that this solution works:
stage.setOnCloseRequest(new EventHandlerWindowEvent()
{
@Override
public void handle (final @Nonnull WindowEvent event)
{
applicationContext.close();
}
});
For me it's fine, but I'd like to understand whether this is the correct
behaviour, or I'm doing something wrong, or there's a bug somewhere.
Details: JDK 1.7.0_25 with its embedded JavaFX runtime, Mac OS X 10.8.4.
Sources fully available if needed.
Thanks.
--
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
We make Java work. Everywhere.
http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: JavaFX8 on iPhone! It works!
On Wed, 03 Jul 2013 18:07:01 +0200, Niklas Therning nik...@therning.org wrote: Awesome! Can you please post the build instructions somewhere? I'm not getting a long with gradle at all. :-( Please post some photos too... :-) -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
