Question about what's on topic
Hi. Is it appropriate to post here questions about why a certain API (e.g. in Java8) has been made in a way instead of another? 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 about Stream/Iterable/Files - and possibly the compiler
On Thu, 05 Nov 2015 14:28:50 +0100, Kevin Rushforth 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
Questions about Stream/Iterable/Files - and possibly the compiler
Hello.
My question is for the sake of curiosity, not being related to a real
problem - or, better, the problem - which is tiny - can be fixed with a
simple work around. But I'd like to blog a short post about it and I'd
like to check I have all the context. It stemmed from a class about Java 8
that I recently taught and one of the participants asked about that.
Everything starts from this code chunk that doensnt' compile:
1.
Stream s = IntStream.rangeClosed(1, 10) // just as an
example to quickly create a Stream
.mapToObj(n -> "String #" + n);
Files.write(Paths.get("/tmp/pippo.txt"), s);
error: no suitable method found for write(Path,Stream)
Files.write(Paths.get("/tmp/pippo.txt"), s);
method Files.write(Path,byte[],OpenOption...) is not applicable
(argument mismatch; Stream cannot be converted to byte[])
method Files.write(Path,IterableCharSequence>,Charset,OpenOption...) is not applicable
(argument mismatch; Stream cannot be converted to Iterableextends CharSequence>)
method Files.write(Path,IterableCharSequence>,OpenOption...) is not applicable
(argument mismatch; Stream cannot be converted to Iterableextends CharSequence>)
2. Variation.
Files.write(Paths.get("/tmp/pippo.txt"), (Iterable)s);
This gives:
Exception in thread "main" java.lang.ClassCastException:
java.util.stream.IntPipeline$4 cannot be cast to java.lang.Iterable
at StreamIteratorExample.main(StreamIteratorExample.java:13)
Ok, so far it's the fact described here
http://stackoverflow.com/questions/20129762/why-does-streamt-not-implement-iterablet
on why Stream doesn't implement Iterable.
Question A: Is the answer "because iterator() is usually supposed to be
callable multiple times, while in a Stream it can't" correct?
3. This is the known trick around the problem:
final Iterable i = s::iterator;
Files.write(Paths.get("/tmp/pippo.txt"), i);
It works and I think I understand why (Iterable has the same functional
descriptor of Supplier, which is s::iterator, so they are
compatible in assignment - right?).
4. But at this point putting it into the same line gives compilation error:
Files.write(Paths.get("/tmp/pippo.txt"), s::iterator);
error: no suitable method found for write(Path,s::iterator)
Files.write(Paths.get("/tmp/pippo.txt"), s::iterator);
method Files.write(Path,byte[],OpenOption...) is not applicable
(argument mismatch; Array is not a functional interface)
method Files.write(Path,IterableCharSequence>,Charset,OpenOption...) is not applicable
(argument mismatch; bad return type in method reference
Iterator cannot be converted to Iterator)
method Files.write(Path,IterableCharSequence>,OpenOption...) is not applicable
(argument mismatch; bad return type in method reference
Iterator cannot be converted to Iterator)
5. This at last works:
Files.write(Paths.get("/tmp/pippo.txt"),
(Iterable)s::iterator);
Question B: Why doesn't the compiler autonomously infer that s::iterator
is compatible with Iterable and the cast is needed?
At last, question C: Given all those premises, is there a specific reason
for which Files.write() hasn't been overloaded with a version capable of
accepting a Stream? It would have been the perfect complement of
Files.lines()
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
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.(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) {
120SoftReference 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 SoftReference(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,
148"Malformed 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 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 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 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 14:01:03 +0200, Kevin Rushforth 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 Thu, 16 Apr 2015 11:57:10 +0200, Robert Krüger 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 Wed, 15 Apr 2015 18:31:56 +0200, Ryan Jaeb 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 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: JavaFX JIRA issues moving to JBS
On Wed, 15 Apr 2015 09:49:09 +0200, Tom Eugelink wrote: I do not understand these doubts, JBS is Jira?! https://wiki.openjdk.java.net/display/general/JBS+Overview /The JDK bug system (JBS) ... is a JIRA instance which provides bug tracking for Projects in the OpenJDK/ I think that this is clear to everybody. The point is that Jira is extremely flexible in configuring access policies and two instances can be very different in terms of usability. With Jira/JBS I was referring to the two instances and their currently configured access policies. A few people pointed out in the previous emails about these differences. In other words, consolidating to JBS is fine: but, as many expressed doubts, does it mean that the JavaFX component will be subject to the same configuration of JBS? Or is it possible to have its access policy, as a component, to stay the same? What about having the access policy of JBS more open, such as the current JIRA for OpenJFX? I suppose these are more legal issues, or internal Oracle policy issues, than technical issues. -- 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
While consolidating the issue tracked is a plus, I share the doubts about the usability of JBS vs Jira. Why not going the opposite path :-) that is consolidating everything under Jira? -- 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 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 Thu, 26 Mar 2015 19:40:41 +0100, Fabrizio Giudici 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
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 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
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 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:./lib/
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
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
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: libjfxmedia.so on armv6hf?
On Tue, 17 Mar 2015 01:21:29 +0100, Felix Bembrick wrote: I really admire guys like this and wish that my own personal circumstances enabled me to get involved in a similar way but my main concern is that the "community" required to make JavaFX truly viable on iOS, Android and ARM needs to be about 50-100 times bigger than it currently is. Without an It's my concern too. At this point we're at 20 years of Java, and I lived them from the very beginning. The idea "the community will fix it" is a déjà vu that, unfortunately, says that in the past the thing didn't work many times. This doesn't mean I'm necessarily in a fatalistic mood. When my RPI2 arrives, I'll try the option you and others suggested. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: libjfxmedia.so on armv6hf?
On Tue, 17 Mar 2015 00:27:53 +0100, Kevin Rushforth 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=81&t=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 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
Re: JavaFX (1.7.0_45) and Applet: problem with layout
On Tue, 16 Sep 2014 11:55:26 +0200, Fabrizio Giudici 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
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: OT: Netbeans ported to JFX?
On Thu, 10 Jul 2014 16:42:31 +0200, Doug Schaefer 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: OT: Netbeans ported to JFX?
On Thu, 10 Jul 2014 16:23:43 +0200, Jeff Martin 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: JFXPanel vs. real world usage
On Thu, 24 Oct 2013 19:20:42 +0200, Pedro Duque Vieira 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 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 21:21:00 +0200, David DeHaven wrote: When you click a JNLP link (or button, invoke javascript, whatever...) the browser downloads a JNLP file then runs javaws to open that file. Beyond that there is no involvement with the browser. Exactly what I thought. 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 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 17:49:10 +0200, Richard Bair wrote: Or, when co-bundling the JRE with your app, you can provide whatever workaround you need to your copy of the JRE (just remove final from a few places or whatnot). Of course the cost comes when you need to upgrade to a newer version of FX, but if you gotta resort to one evil or another for the sake of shipping, this one at least leaves you in control. I add that since it has been said that, unlike Spring, JavaFX 2 is more designed for composition in place of inheritance, let's rather focus on verifying that there's a good design in this sense and eventually ask for a better one when needed. I mean, rather than subclassing, perhaps that quick fix can be done by composition? -- 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 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 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 Media issues
On Thu, 08 Aug 2013 22:57:51 +0200, Joe McGlynn wrote: I don't know why FX Media isn't in the FX 8 API docs, but that's clearly an error. Please file a bug on that. In the meantime, you should look at the FX 2 media docs, there isn't a lot of change from FX2 media in FX8. Buffering and streaming (HTTP Live Streaming) are both supported, as is playback from a URL. What is the strategy for codecs? I mean, now we have ImageIO (there is also JAI but it seems basically dead). ImageIO provides many image codecs and there's a SPI that can be used to support more formats. Will it be replaced by FX2 media or co-exist with 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 Sightings (forked from Re: Can JavaFX do CAD?)
On Wed, 07 Aug 2013 16:54:37 +0200, Mark Fortner 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: JavaFX Sightings (forked from Re: Can JavaFX do CAD?)
On Sun, 04 Aug 2013 09:47:41 +0200, Anton Epple wrote: A combination of a page describing an individual application, like the one you linked here, would be one part and -more important- a page that lists *all* the applications with a screenshot and a short description. The latter would be important, because it's a showcase for decision makers who are yet undecided if JavaFX is the right technology. Before that page existed for NB Platform, I had the same discussions I now have for potential JavaFX projects. Developers are in doubt if the technology is mature/performant/secure/whatever enough for their large/unique/graphically demanding/etc. project. After they see the page, they're convinced that it can be done. It's especially useful if you need to convince a team. Typically there's at least one person in favor of a different technology (for JavaFX it's typically GWT) and such a page is a great FUD-killer. +1 -- 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 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
Re: Can JavaFX do CAD?
On Sat, 27 Jul 2013 01:12:26 +0200, Daniel Zwolenski wrote: b) lack of any big or notable players out there actually using it, or at least publicly saying they are using it My only - so far - customer currently using JavaFX has a strong experience with Swing and recently also the NetBeans Platform; I've been their technological consultant for five years and they're pretty used to the idea of prototype-then-evaluate. I adviced about an incremental migration path, and they started using some JavaFX features inside Swing. We've just started the first 100% JavaFX app, which is a prototype that will be turned into a real app later. There's room for either adopting JDK 8 later next year, or using again some Swing stuff in case of necessity, even though I think that it's unlikely. I think that Daniel's point is important: demos are good, but people would like to see other people seriously using a technology in production. For instance, the existence of a large, continuously updated catalog of real world applications using the NetBeans Platform has been very useful for me in giving people the final push and convince them that the technology was viable. So I think Oracle should do the same for JavaFX - (if it doesn't exist, I'm not aware of it). -- 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 Sat, 27 Jul 2013 05:35:37 +0200, Tom Schindl wrote: Correct, but then i1 is not referenced anymore and so GC should free it, not? As I said in my previous email, my TreeItem is bound to resources other than memory and this kind resources must be released synchronously - the GC would usually intervene too late. For instance, the TreeItem might subscribe to events that are used to update its state, and unsubscription must happen when the TreeItem is no more used, otherwise bad things can happen. -- 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 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
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: Pushing OpenJFX to Maven - licensing and other stuff (forked from Re: jfxrt.jar - is it platform specific?)
On Thu, 25 Jul 2013 09:55:33 +0200, Daniel Zwolenski wrote: Including the list. Daniel, I very welcome your initiative and I do hope there are no problems. I hope to see soon all the OpenJDK artifacts published to Maven and I'm available for helping in case it's needed (with the exception of native compilations, for which I'm probably not the best candidate). -- 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 Wed, 24 Jul 2013 17:06:57 +0200, Richard Bair wrote: The scene graph will not support millions of nodes, How many nodes are supported? I'm helping with the prototyping of a software that should render 2D SVG. In the past the need was for relatively complex documents, converted from 2D AutoCAD - the need was to render everything smoothly, zoom in & out, having less than a hundred additional nodes inserted programmatically that require an interaction - animation, context menu, etc. Only the additional nodes needed interaction and editing, the other stuff just to be rendered quickly. In the past we did with Batik+Swing, and it was pretty good in the end - no problems with the performance. Now we're trying a pure JavaFX approach and we're using the tool provided by Toni Eppleton that converts SVG to FXML. In the new project the SVG documents are simpler, still we needed to simplify them (e.g. smoothing some curves - they represent geographic borders) for having a good performance. We didn't measure anything so far - just trying - also because after the smoothing the speed is ok for the new project. But I'm wondering whether a port of the old project with Batik would be feasible. -- 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 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 Wed, 24 Jul 2013 09:59:07 +0200, Artem Ananiev wrote: On 7/24/2013 12:45 AM, Fabrizio Giudici wrote: On Tue, 23 Jul 2013 22:34:48 +0200, Anthony Petrov 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 Tue, 23 Jul 2013 22:34:48 +0200, Anthony Petrov 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
Re: Disabling JavaFX minimise/maximise/etc buttons
On Tue, 23 Jul 2013 13:19:19 +0200, Werner Lehmann wrote: Minimizing a modal dialog does not achieve much because the owning window is still blocked. Unless that window is minimized along. At least Windows usually disables the window decoration buttons of the owning window though. I just tried initOwner() on Mac OS X. The dialog "bounces" in the minimized state off and on; I mean, I see first the Genie effect "out" and the dialog is minimized, and immediately after I see the Genie effect "in" and the dialog is restored. At the very end, the whole application window is pushed back (that is, other application windows get over it). I presume it doesn't make much sense :-) But it actually disables the "full screen" and maximize buttons as expected. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: Thread checks in Glass
On Mon, 22 Jul 2013 11:06:14 +0200, Petr Pchelko wrote: Hello all, This is goodness. Definitely +1, if this approach was followed in Swing since 199X we'd have much less troubles with existing code today. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: JavaFX app with Spring doesn't terminate on Mac OS X with Cmd-Q
On Fri, 05 Jul 2013 12:46:35 +0200, Anthony Petrov wrote: Hi Fabrizio, Cmd-Q (or, rather the implicit exit machinery) does not call System.exit(). All it does when it detects that there's no FX windows open, it terminates the FX Event Thread. This is clearly stated in the javadoc [1]. Ok, I missed the link between Cmd-Q and the rest. The rest depends on the JVM. As long as there are active non-daemon threads running, the JVM won't exit. I suspect that the services you're running create non-daemon threads and they prevent the JVM from exiting. So the solution you came up with (calling applicationContext.close()) looks correct: you tell the background services to shut down, and then the application can terminate as expected. Hope this helps. It makes perfectly sense. Thanks. -- 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 EventHandler()
{
@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 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
Re: openjfx-dev Digest, Vol 19, Issue 73
On Tue, 02 Jul 2013 12:23:10 +0200, Peter Zhelezniakov wrote: I supposed that JavaScript support in WebView is exactly the original one in WebKit. Am I wrong? The engine is the same, but as it interacts with other parts of the browser, it may hit bugs elsewhere. What you're seeing seems to be a bug in processing font metrics. Looks very similar to RT-18883 indeed. Thanks. I did some research in the past days and collected some other issue references - I opened RT-31382 (I see that you just commented on it). -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: WebView and Aloha Editor
On Mon, 01 Jul 2013 21:44:58 +0200, John Smith wrote: Perhaps Fabrizio's selection issues are related to the following issues: https://javafx-jira.kenai.com/browse/RT-18883 Google Docs editing issues https://javafx-jira.kenai.com/browse/RT-11239 Add drawGlyphVector type support to prism graphics It soudns as they are. Given that hopefully somebody is working on that, do you think is it possible to apply some temporary workaround in Aloha? Or I only have to wait for a fix in JavaFX? -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
WebView and Aloha Editor
First, as this is my first post here, cheers to everybody. So far I've been using WebView - other than pure HTML rendering - e.g. in embedding some JavaScript-based legacy application inside a rich desktop application, and it worked fine. It only needed some patches to the JavaScript code (that was some old one, not perfectly portable, written for Firefox). So, my idea was: as soon as I have some JavaScript that works with a WebKit browser, it's going to work with WebView. Now I'm developing a JavaFX application that provides editing features to a CMS. One of the features is the editing of XHTML documents. The HTMLEditor component does a very poor job of rendering, and I want JavaScript support, so I'm trying a WYSIWYG HTML editor made in JavaScript (Aloha Editor) with WebView (and a small embedded webserver under the hood). I supposed there were not major problems, as Aloha works well with WebKit browsers. Instead some surprise came: some things work and some are broken, e.g. selecting a sequence of characters and applying a bold style eats up some parts. I supposed that JavaScript support in WebView is exactly the original one in WebKit. Am I wrong? Thanks. PS After some more analysis, I wonder whether this is related to the font rendering engine. When I do a text selection, I see that the selection box is not precisely placed over the original text, but often it appears with a horizontal shift. I'm not an expert of JavaScript and I don't know how the text manipulation in Aloha works, but I wonder whether a font rendering that is not the original of WebKit can cause harm. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
