Re: Gtk4 and Wayland

[Mario Torre]

On Wed, Sep 1, 2021 at 1:18 PM Johan Vos  wrote:
>
> Hi Thiago,
>
> I was thinking (and experimenting) in the same direction, and so far that
> is working good. I don't see disadvantages, but it would be good to find
> out about it before we move forward.
> Maybe the main issue to me is that GTK comes with lots of dependencies. We
> already have that situation today, so it is not going to be worse. But if
> we would use the Wayland protocol on a lower level (with a Wayland-specific
> glass platform, instead of GTK), we could probably reduce the dependencies.
> However, this comes at the price of creating *and maintaining* more
> low-level code.
>
> I've been running GTK3 on Wayland and that works fine too. However, it
> might be better to focus Wayland support for GTK4. I think there won't be
> many installs that have no X11, but only Wayland, and that have GTK3 and no
> GTK4.

I tend to agree with you, I think we should consider this for Wakefield too.

Cheers,
Mario

> - Johan
> - Johan
>
> On Tue, Aug 31, 2021 at 11:03 PM Thiago Milczarek Sayão <
> thiago.sa...@gmail.com> wrote:
>
> > Hi,
> >
> > I did some investigation on gtk4 and wayland.
> >
> > After some research I ended up with the conclusion that the best way is to
> > do a separate gtk4 backend, that would support X11 and Wayland.
> >
> > This would be a good start:
> > https://github.com/openjdk/jfx/pull/77/files
> >
> > Why?
> >
> > Gtk4 moves the decoration to the client side, which is GREAT since knowing
> > the window size with decoration was a real pain.
> >
> > We probably won't want to do all the decoration work, Gtk does that, but on
> > GtkWindow level, not GdkSurface (which replaces GdkWindow).
> >
> > Thus the move to use "more Gtk" (hence "less Gdk") which is exactly what
> > the PR does. It also removes Applet code
> >
> > This is also a good starting point:
> > https://gnome.pages.gitlab.gnome.org/gtk/gtk4/migrating-3to4.html
> >
> > --Thiago.
> >
>


-- 
Mario Torre
Manager, Software Engineering, core OpenJDK
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

Re: Bug: Not on FX application thread exception is inconsistent

[Mario Torre]

Il giorno mar 13 nov 2018 alle ore 16:11 Ty Young
 ha scritto:
>
>
> On 11/12/18 9:12 PM, Brian Hudson wrote:
> > JavaFX like every other modern UI framework is single threaded.
>
>
> Which in itself is fine, running *just* the UI isn't much on modern
> processors. Adding a bunch of API object updates that cause thread
> slowdown to the mix that can cause UI stuttering is, again, asking for
> trouble.

I think you're missing the key point of synchronising different
threads for different tasks. You can do all the processing of your
objects in any thread you want, but the moment they need to update UI
state, this needs to be piped into the UI thread.

>
> And how is TableView, Slider, TextField, etc all working just fine but
> ComboBox freaks out? What's so special about ComboBox? Is there some
> hack I can do to not trigger the exception?

Just luck.

I suggest you to study and learn about concurrent programming and read
some basic tutorials on graphical programming, the issues you are
encountering aren't anything new, most frameworks work the same way.

Cheers,
Mario

-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

Re: The "javafx might not be present" problem

[Mario Torre]

On Fri, Feb 9, 2018 at 3:07 PM, Michael Paus <m...@jugs.org> wrote:
> Am 09.02.18 um 14:49 schrieb Mario Torre:
>>
>> On Fri, Feb 9, 2018 at 2:29 PM, Mark Raynsford <org.open...@io7m.com>
>> wrote:
>>
>>> I suppose what I'm really saying is: When (if ever) can I expect JavaFX
>>> to be present unconditionally with OpenJDK installs? I probably can't
>>> migrate to JavaFX until that day...
>>
>> JavaFX is not part of the Java specifications for the JDK or its
>> runtime, so the presence of the library in any distribution of OpenJDK
>> pretty much depends on the vendor distributing you the binaries.
>>
>> There are some Linux distribution that started packaging a subset of
>> OpenJFX (in most cases few notable missing bits are the audio codecs
>> and the webview). I don't know if the same libraries will be bundled
>> with the GPL binary from Oracle, that's probably a question somebody
>> from Oracle may answer.
>>
>> The only way I can see JavaFX becoming included by default everywhere
>> is if it becomes part of the spec.
>
> In practice this is really a pain point and very bad advertising for JavaFX.
> Who defines that everything Open... can only contain what is included in
> "the spec"?
> Who keeps us from creating a product OpenJDKFX which we define to contain
> OpenJDK + OpenJFX. I'd like to see a complete and open version of Java but
> at the moment everybody seems to restrict themselves to only OpenJDK.
> Even Oracle at their EA download page deliver the open version of the JDK
> without JavaFX which I simply don't understand and which makes this version
> of the JDK completely useless to me.

You already have a complete, compliant and open version of Java. The
Java spec and the TCK define what is and what is not Java, and it
doesn't cover JavaFX.

JavaFX can be included by downstream vendors, but that's entirely up
to them, in that regard is not different than bundling Tomcat or maven
with your JDK.

I agree that would be nice to have everywhere, but again I can't see
that happening until it becomes part of the spec.

Cheers,
Mario

Re: OpenJFX JIRA Location

[Mario Torre]

2018-01-07 18:58 GMT+01:00 Michael Paus :

> And then what?

Robert wanted to contribute some fixes, he presumably has a couple of
bugs that he can report (or perhaps that are already in the bug
database), if the changes are minor, he can start doing that now by
contributing the fixes on the mailing list, as described in details
here:

http://openjdk.java.net/contribute/

Cheers,
Mario

-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

Re: Building OpenJFX.

[Mario Torre]

2017-12-19 23:04 GMT+01:00 Scott Palmer :
> The project should be configured to use the Gradle Wrapper, so the correct 
> version of Gradle is used automatically.

This is not an option for Linux distributions and is not an option for
many people using them. We need to be able to produce a build with an
all local toolchain.

Cheers,
Mario
-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

Re: Innovation again (was Re: Text classes)

[Mario Torre]

2017-12-06 9:40 GMT+01:00 John-Val Rose :
> Yes, I obviously need to know if anything I work on or design is going to
> be accepted or is even wanted by the community as a whole, and as early on
> in the process as possible.  Heck, if I had my way, JavaFX would be used to
> build everything from forms to FPS games and highly complex and performant
> 3D visualizations.  And don't say it can't be done in Java - it can.
> JavaMonkeyEngine can be used to create awesome games (for example).

If I understood correctly the change is big enough to need a JEP.
Generally, you need a JEP for new features, new API and big changes.
You don't need for bug fixes and internal refactoring. So, for
instance, adding a new port to the graphics need a JEP.

It's up to the project maintainer to say whether that should be a JEP
or not, though.

> Plus, I have never "done" a JEP but I believe it's quite a long and
> involved process (?)

Well, that doesn't mean you can avoid it ;)

I did work only with the two previous drafts of the JEP, but the
latest draft is a lot quicker (simply file a bug report basically).

The JEP is detailed here:

http://openjdk.java.net/jeps/1
http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

The second link is the current version, the first link is for
reference since this is where the process should be detailed, but
hasn't been merged yet.

Cheers,
Mario
-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

Re: Innovation again (was Re: Text classes)

[Mario Torre]

I think Phil said that, the way to propose such changes is to file a Jep
and discuss it here.

Cheers,
Mario

On Wed 6. Dec 2017 at 09:07, Markus KARG  wrote:

> I think what John actually asked for is whom to send his design upfront at
> the JFX team to get an initial judgement whether it is worth programming
> it, or whether it bears such flaws that it makes not much sense to invest
> any more time. Whether or not that decision is done by an Oracle employee
> or not, he simply needs to know whom to sent his proposal for early review.
>
> -Markus
>
> -Original Message-
> From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf
> Of Philip Race
> Sent: Mittwoch, 6. Dezember 2017 06:50
> To: John-Val Rose
> Cc: openjfx-dev@openjdk.java.net
> Subject: Re: Innovation again (was Re: Text classes)
>
> There needs to be a viable community that is not just Oracle to support
> you here ..
> I think everyone has come to be dependent on Oracle to "be there".
> But if there is a specific community need that Oracle doesn't see as
> essential, then the community should help out.
>
> -phil.
>
> On 12/5/17, 9:27 PM, John-Val Rose wrote:
> > Well, that’s all fine but you didn’t address the issue of working with
> someone within Oracle to get these innovations done.
> >
> > Sure, I could just toil away by myself but clearly it would be better
> all around if there was someone with much more extensive knowledge of
> JavaFX and its internals who was accessible when required.
> >
> > I would assume that a member of the Oracle JavaFX team would be such a
> person. If not, then who?
> >
> >> On 6 Dec 2017, at 15:53, Philip Race  wrote:
> >>
> >> I think looking at it as an Oracle-owned and controlled project maybe
> the first mistake here.
> >> Yes it was closed source and then Oracle controlled, but not any more,
> OCA requirements aside.
> >> It is not even a "java specification". It can be evolved at an API
> level without a JSR.
> >> The JEP process is the main thing to be followed, although we also use
> CSRs too to track API.
> >> Consider it that anyone who is a contributor owns (not the right word
> ?) a piece of it too.
> >> So standing on the project is what matters. Not the company who pays
> you to work on it.
> >>
> >> -phil.
> >>
> >>> On 12/5/17, 8:21 PM, John-Val Rose wrote:
> >>> Phil et. al.,
> >>>
> >>> Whilst I’m not going to be quite as “passionate” as some on this issue
> (although I do understand the frustration), I would like to point out again
> that this is indeed a huge gap and it is critical that it is filled ASAP.
> >>>
> >>> Obviously a solution where every word in a text document is a Node
> would be unworkable so it would need to be architected from the ground up.
> >>>
> >>> I would be happy to work on such as feature, just as I was happy to
> work on implementing WebGL, but my hesitation is concern over the
> assistance and involvement from Oracle.
> >>>
> >>> If I am going to have to spend months working on something without any
> or only minimal involvement from Oracle, only to find at the end that
> Oracle either doesn’t like the design, implementation or something else
> then it is wasted time I’ll never get back.
> >>>
> >>> There are lots of other innovations too that I would like to see in
> JavaFX but I just don’t “feel the enthusiasm” from Oracle.
> >>>
> >>> If there is someone on the JavaFX team who would be willing to work
> with me (at least in some capacity), please have them contact me privately
> via email.
> >>>
> >>> The innovations I could work on and contribute include:
> >>>
> >>> 1. WebGL support in WebView
> >>> 2. Better text support including text documents&   rich text editors
> etc.
> >>> 3. Significant improvements in scene graph rendering speed using
> >>> modern game-engine style structures and algorithms
> >>>
> >>> JavaFX cannot survive without innovation and I am keen to see it
> happen and contribute as much as possible.
> >>>
> >>> Graciously,
> >>>
> >>> John-Val Rose
> >>> Rosethorn Technology
> >>>
>  On 6 Dec 2017, at 11:36, jav...@use.startmail.com wrote:
> 
>  Sorry about all the typos previously.
> 
>  Question- why not use the code in awt ? I am not totally up on what's
> going on with the platforms' native rendering engines ( meaning, I have no
> idea whatsoever) or how they have changed, but golly it sure does still
> work pretty well.
> 
>    At least it seems to me looking at awt that a smallish number of
> things are 1) well defined by the native platofrm and 2) would more or less
> translate directly to an Java API and 3) from those small number of
> building blocks, (Font and Glyph metrics and this kind of thing)   text
> line layout algorithms can be written by ordinary civilians along with all
> the other stuff that goes into a text editor.
> 
>  And yes, everything does look easy when someone else is going to do
> it.
> 
> 
>

Re: OpenJFX Project Lead Resignation

[Mario Torre]

On Thu, Jun 23, 2016 at 6:49 PM, Richard Bair  wrote:
> Hi,
>
> As you know, I’ve been on the periphery of this project for the last several 
> years, my full time employment taking me into a different path from client 
> toolkits. The time has come to pass the torch, and part of that is to send my 
> official resignation so that another may take it up. Truly, the time I spent 
> working on JavaFX was the best so far of my career, and extremely fulfilling. 
> It has been, and continues to be, a true pleasure to see your support and 
> enthusiasm for this project.
>
> I do hereby officially resign as lead of OpenJFX.

Thanks for the hard work, but especially thank you for leading the
Open Sourcing transition!

Cheers,
Mario

Re: Anyone using JMX with JavaFX?

[Mario Torre]

On Tue, Jun 14, 2016 at 12:25 PM, Robert Krüger
 wrote:
> Only regarding the net loss for the community: There are not many places
> where people trying to defend (and make a living off) Java as a viable
> desktop technology can try to get information from Oracle and the questions
> he asks are also the ones we (as an ISV with a Java-based product) would
> ask, so I do regard them as valuable.
>
> Having said that, I understand, however that those things will never get an
> answer here (never have in the past, having asked such questions myself).
>
> Just writing that so Felix does not feel that he's alone with his concerns
> and to add another data point on the Oracle radar that Houston, we do have
> a real problem here and quite a few frustrated Java advocates.

Eh, I thought this thread was finally over...

This mailing list is definitely not the place to discuss such things.

Discussing Oracle plans is something only Oracle can do, so asking
about those on a development mailing lists doesn't work out.

As for more general things, even including adoption of the technology,
that may be more or less related to actual development, there are
other, better, places, for example FOSDEM and JavaOne are just two of
the various conferences that generated great and very useful deal of
discussions over the years.

If you care about participating in a constructive manner, you should
check those out, really. There are other channels, too. For instance,
the Adoption Group is a great place to start asking questions. No, not
questions like what Oracle is planning to do with XXX, you won't find
answer for those there, but you'll be directed in how to contribute,
and contribution means also discussing in a constructive manner (this
can also have the form harsh criticism at times, btw, as long as is
not gratuitous).

That said, it has happened in the past, and will certainly happen in
the future, that some questions that touch areas perhaps less round
regarding the actual development like interest is specific means of
integrations or specific issues about adoption, etc... find a place of
discussion here. This is not how generally works, because this is
about development, but it's understandable in a living Community to
also take *some* discussion at that level.

The problem here is another one. First, insisting when somebody have
been asked, politely, to stop, and the second and most important is
the manner of presenting ones idea, by hijacking a purely development
oriented thread with random and totally unclear questions, attempted
sarcasm and just lots of negativity. A thread, btw, that asked the
Community suggestions how to proceed regarding the removal of rather
unused code, so instead of having a constructive participation in a
technically oriented thread, the thread was hijacked with harsh
resentment both on and especially off-list resulting in just a missed
opportunity if you ask me.

Just to conclude, there are just too many layers before our voices can
be heard by who makes decision, if we start off by screaming chances
are that our messages will never go through, instead ranting and
offending only has the effect of lowering ones credibility, so if you
fall on this side, even with the best intentions, your "contributions"
will likely end up nowhere.

Please, let's try to be constructive, there is a place and a time for
everything.

Cheers,
Mario

-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

Re: FTFactory.java: Fonts loaded by Pango are never registered and always return

[Mario Torre]

On Thu, Mar 3, 2016 at 2:48 PM, Maurice  wrote:
> At the moment the embedded environment I'm using is not able to use
> downloaded or external supplied fonts. I've traced through the system and
> found that it looks like it fails in pango.c FcConfigAppFontAddFile, at
> least OSPango.FcConfigAppFontAddFile returns false, thus propagating a null
> all the way up.
>
> Checking the pango.c file I noticed something very interesting:
> JNIEXPORT jboolean JNICALL OS_NATIVE(FcConfigAppFontAddFile)
> (JNIEnv *env, jclass that, jlong arg0, jstring arg1)
> {
> static void *fp = NULL;
> if (!fp) {
> void* handle = dlopen(LIB_FONTCONFIG, RTLD_LAZY);
> if (handle) fp = dlsym(handle, "FcConfigAppFontAddFile");
> }
> jboolean rc = 0;
> if (arg1) {
> const char *text = (*env)->GetStringUTFChars(env, arg1, NULL);
> if (text) {
> //rc = (jboolean)FcConfigAppFontAddFile(arg0, text);
> if (fp) {
> rc = (jboolean)((jboolean (*)(jlong, const char *))fp)(arg0,
> text);
> }
> (*env)->ReleaseStringUTFChars(env, arg1, text);
> }
> }
> return rc;
> }
>
> Yes, you see it correctly! The line that actually should register the font

Pointer to functions make me blind too, but If I'm not reading it
wrong, I think this is not a commented code call, it's meant to tell
what the code below it does (apparently, it made blind also the
author!):

FcConfigAppFontAddFile is dloaded into fp, so this totally
incomprehensible line:

((jboolean (*)(jlong, const char *))fp)(arg0, text);

it's just casting fp to a function that returns a jboolean and takes a
jlong and a const char array as argument, hence it becomes again:

(jboolean)FcConfigAppFontAddFile(arg0, text);

Cheers,
Mario

Re: JEP 283: Enable GTK 3 on Linux

[Mario Torre]

Hi Phil, Kevin,

On Fri, Feb 19, 2016 at 7:10 PM, Phil Race  wrote:
> We had not forgotten that the other JEP was there (as a draft)
> but the new JEP started with a pure FX focus on allowing FX to use either
> GTK2 or GTK3 depending on what you needed.
> It was extended (feature creep) whilst being drafted to include doing the
> same for
> AWT/Swing but the focus was still on interoperability. Making the Swing
> L fully GTK3 based is the later stretch goal whereas the original JEP
> is much more focused on that and also not at all on FX.
> It would be good for Mario to take a look at the new JEP and identify
> any areas in which it falls short of the previous JEP, which would be
> one reason to leave the "old" JEP open for now. Another is that it
> is unclear how much of JEP 283 we will actually be able to deliver for
> JDK 9 and it is written in a way which is intended to allow for that.
> In which case the previous JEP may yet be needed to complete that work,
> so we don't know yet it if it will be completely subsumed by that work.

The fact that you're doing this is an awesome, awesome news! :)

I think there's quite some overlap between my proposal and this JEP. I
admit I didn't do a lot of progress, but I didn't just write the JEP
and forget, so I do have some working code and things start to have
something to look at.

My take on this was to proceed with a fully clean room implementation
and only use cairo+gtk, since there's just too much stuff being
deprecate or removed that doesn't make sense to keep around. I've been
ld-loading all the functions and redefining the types (most as
typedefs to void pointers, sometime copying the enums or constants
values) as I touch them.

The task is not straightforward and unless you have somebody full time
I doubt the GTK3 Laf will be included 9, but since it's entirely
possible to get this done as a pluggable laf in fact anyone can
benefit as soon as it's ready.

A couple of problems that I have are about the choice between gtk2 and
gtk3, I wasn't yet able to properly unload and reload the correct
version reliably, so the idea of the startup switch is very good, it's
also good to coordinate with the javafx team since it's paramount that
OpenJDK and JavaFX load the same library under the hood.

I'll be happy to talk with who is actually doing this work and sync on
my progress and either hand it over or help out myself.

As for keeping the "old" JEP around, I don't think it's needed, but it
depends on how the 283 turns out, perhaps we can retire mine and
revive it if it's needed at a later point, or make it a subtask (like
it has been done with jigsaw) of the main one, I leave this up to you
I don't have problems either way.

One thing, I strongly believe that we should keep GTK2 around for a bit longer.

Cheers,
Mario

Re: Future of JavaFX

[Mario Torre]

2015-12-01 14:03 GMT+01:00 Felix Bembrick :
> Is it really true that *all* of JavaFX is open source?
>
> Even if it is, if I wanted to say take some aspects of the product in a 
> radical new direction, wouldn't someone from Oracle have to approve the 
> changes?
>
> If yes, then only Oracle can bring the big enhancements that are necessary 
> which we know will never happen.

You can always try to propose the changes you want to see, and if it
fails, of course provided you follow the License (GPL + Classpath
Exception), you can take, modify and redistribute the sources as you
see fit.

Btw, as a general note, I always find discussing about how impossible
any contribution is *without* first trying to contribute anything a
real waste of time.

Cheers,
Mario

-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

Re: Future of JavaFX

[Mario Torre]

My humble opinion is that what should happen to stop this FUD once and
for all is that JavaFX becomes finally part of OpenJDK (as in same
codebase and same build infrastructure) and a formal part of the Java
API.

I'm sure this will happen eventually and everything seems to go toward
this goal, but it should move a bit faster.

Cheers,
Mario

2015-11-30 17:13 GMT+01:00 Dirk @ Google :
> Hi there,
>
> there has been quite a shake-up in the JavaFX community last week when Shay 
> Almog (Codename One) first responded to a blog of mine 
> (dlemmermann.wordpress.com) with a lot of negative comments regarding JavaFX 
> and its future. He then followed up with a long blog asking the question 
> „Should Oracle Spring-Clean JavaFX“ 
> (https://www.codenameone.com/blog/should-oracle-spring-clean-javafx.html 
> ).
>
> I do understand that it is often a good strategy to not comment on stuff like 
> this because commenting would just draw attention to it, but we have now 
> reached the point where potential customers are questioning the 
> sustainability of a JavaFX-based solution. They are now wondering if JavaFX 
> will still be around in a few years. In my specific case the customer demands 
> an answer from me and my partners within the next week, and if not convincing 
> they will go with something / someone else. We will loose a contract worth 
> around one million dollars because of one blog written by Shay with no 
> follow-up from Oracle.
>
> What is needed is an official statement from Oracle / Oracle employees / 
> JavaFX development team, saying that Oracle is still committed to JavaFX and 
> that it will still be around for a while. Can somebody please do that?
>
> Dirk
>
>



-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

Lunch, dinner, anyone?

[Mario Torre]

Hi all,

Is there going to be a lunch/dinner/breakfast/beer/something like last
year at JavaOne? I didn't see any email on the mailing list (but I've
been a bit off lately so I probably just missed this).

Cheers,
Mario
-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

Re: Off topic: named parameters

[Mario Torre]

On Tue, 2015-04-21 at 09:52 +0200, Tom Eugelink wrote:
 Totally off topic, I apologise, but the subscribers to this list are the type 
 of people who may have the experience I seek.
 
 I've been trying to pitch the concept of named parameters for Java 9, but 
 somehow my JEP is never picked up. I emailed it in twice. Has anyone ever 
 successfully handed in a JEP?
 https://tbeernot.wordpress.com/2013/09/29/the-java-9-named-parameter-pitch/
 
 Tom

Hi Tom,

I personally think this makes the language more verbose with little
benefit, but that's just me maybe.

I don't see your JEP here:

http://openjdk.java.net/jeps/0

You can start off the discussion for a JEP over the mailing list that
more closely matches your change area, if there's no objection, you can
go on and create a bug on the OpenJDK bug database, from there you will
need discussions in order to move the bug to the next state.

A JEP usually means you will need to do the work yourself, unless you
can make such a strong case to get someone to work on the task for you
(one such example, lambdas). In that regard no one will pick up your
JEP, you need to actively push.

Changes, unless minor, will have to be reconfirmed by the JCP committee,
so it may very well be that the JEP will just remain a very complex and
complete proof of concept.

The idea behind the JEP is to have a testbed for new ideas, a place
where there's less overhead to experiment with something, and perhaps
contribute quicker to OpenJDK once proved that the changes are small or
self contained, or really worth it.

Here you can find a bit more information:

http://openjdk.java.net/jeps/1
http://openjdk.java.net/jeps/2

And especially this:

http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

Cheers,
Mario

Re: JavaFX JIRA issues moving to JBS

[Mario Torre]

I think the confusing part of Kevin's mail was the file to bugs.java.com bit.

I think he meant for customers who already file bugs report to the
shipped-with-Oracle idk version of JavaFX, not the same OpenJFX we
discuss here.

OpenJFX bugs will be directed to the JIRA based https://bugs.openjdk.java.net/

Kevin, is that right, did I understand you correctly?

Cheers,
Mario

2015-04-15 10:08 GMT+02:00 Mario Torre neugens.limasoftw...@gmail.com:
 2015-04-15 8:32 GMT+02:00 Tobias Bley t...@ultramixer.com:
 Hi,

 in my opinion it’s definitely no good news to move from JIRA to JBS. While 
 Jira is a very good and popular bug tracking system, the JDK JBS is a pain. 
 With JBS the community efforts will decrease. It’s too complicated to be 
 part of the Java community if you are forced to first sign a commitment… 
 It’s a step backward :( Like other decisions like stop of SceneBuilder 
 builds, no official mobile ports and so on. Sorry, I’m very disappointed of 
 the current strategy of Oracle.

 JBS for OpenJDK *is* JIRA:

 https://bugs.openjdk.java.net/

 I still hope that I am wrong…

 Best regards,
 Tobi


 Am 15.04.2015 um 00:20 schrieb Kevin Rushforth kevin.rushfo...@oracle.com:

 As most of you are aware, JavaFX uses its own JIRA bug tracker [1]. The JDK 
 Bug System [2] (JBS) is the JIRA bug tracker used by the OpenJDK Community. 
 With the OpenJFX Project being a part of this Community, it is time for us 
 to move away from our separate bug tracker and make use of JBS. This will 
 allow us to leverage the greater infrastructure investments being made and 
 lessen the burden of having to maintain our own infrastructure, and 
 consolidates all JDK bugs in one place. The target date for this transition 
 is the second half of May.

 The issues currently in the RT project in JavaFX JIRA will be folded into 
 the JDK project in JBS. Details will follow on the mapping, but here are 
 the highlights:

 - A new javafx component will be created in the JDK project
 - Most existing JavaFX JIRA components will be sub-components of the 
 javafx component
 - The mapping from existing RT-n bug ID to new JDK-mmm bug ID 
 will be maintained by JBS such that searching for RT-n will take you to 
 the right JDK-mmm bug.

 A JBS account will be needed to directly report new bugs or comment on 
 existing bugs. Most application developers will file new JavaFX bugs at 
 bugs.java.com [3] just like other JDK bugs. The requirement to get a JBS 
 account [4] is to have a role of Author or higher in an OpenJDK Project 
 (e.g., jdk9 or openjfx).

 Our advice to those of you actively involved and participating in the 
 OpenJFX Project is to consider joining the OpenJDK as a Contributor [5] by 
 signing the Oracle Contributor Agreement (OCA) [6]. This is a necessary 
 first step in contributing to any OpenJDK Project, including OpenJFX. It 
 allows you to provide patches that we might accept for OpenJFX, and is also 
 a step along the path to becoming an Author. The general guideline [7] is 
 that the Author role may be requested by a Project Contributor who has 
 contributed two non-trivial patches that have been accepted and pushed.

 As part of this transition, we will enable anonymous viewing of bugs (no 
 need to login just to look at a bug) and they will be easily searchable 
 online.

 We apologize for the inconvenience caused to OpenJFX Participants by this 
 upcoming change to the bug database write access policy. We really 
 appreciate your commitment to improving and growing the JavaFX technology.

 -- Kevin


 [1] https://javafx-jira.kenai.com/
 [2] https://bugs.openjdk.java.net/
 [4] https://wiki.openjdk.java.net/display/general/JBS+Overview
 [3] http://bugs.java.com/
 [5] http://openjdk.java.net/contribute/
 [6] http://www.oracle.com/technetwork/oca-405177.pdf
 [7] http://openjdk.java.net/projects/#project-author





 --
 pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
 Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

 Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
 Proud GNU Classpath developer: http://www.classpath.org/
 OpenJDK: http://openjdk.java.net/projects/caciocavallo/

 Please, support open standards:
 http://endsoftpatents.org/



-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

Re: JavaFX JIRA issues moving to JBS

[Mario Torre]

2015-04-15 0:20 GMT+02:00 Kevin Rushforth kevin.rushfo...@oracle.com:

 As part of this transition, we will enable anonymous viewing of bugs (no
 need to login just to look at a bug) and they will be easily searchable
 online.

Great news!

Cheers,
Mario

-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

Re: Linux (centos), openjdk 8, openjfx and netbeans 8

[Mario Torre]

Hi Anton,

This is new to me, I think OpenJDK 8 does *not* contain OpenJFX (or JavaFX).

You are probably referring to the Oracle closed JDK.

Cheers,
Mario
Il 24/nov/2014 08:49 Anton V. Tarasov anton.tara...@oracle.com ha
scritto:

 Hello Alexander,

 On 22.11.2014 17:42, Александр Свиридов wrote:

 Hello everybody.
 I installed at centos 6.4 openjdk 8, netbeans 8 and build openjfx (via
 gradle). The only thing I can't uderstand is how to make netbeans work with
 built openjfx sdk. As openjdx sdk is in folder /temp while jdk is in
 /usr/lib/jvm/java-8... I can't undertand how to add openjfx to netbeans as
 everywhere people say that jfx is already in jdk.
 So, what now should I do to make all these work together?


 openjdk8 sdk contains the openjfx sdk binaries. So, you don't need to
 change the classpath in order to compile or run your jfx application.
 Simply add your jdk as a Java Platform.

 In case you want to try your own openjfx build with openjdk in netbeans,
 you can do the following.

 In the Project Propertiesdialog of your project, select Libraries and
 add jfxrt.jar to the Compile-time and Run-time libraries. Please, find
 jfxrt.jar in the artifacts of your openjfx workspace:

   openjfx/artifacts/sdk/rt/lib/ext/jfxrt.jar

 Also, you can find the netbeans projects of the openjfx source tree under
 the following dir:

   openjfx/rt/netbeans

 Regards,
 Anton.

Re: Swing Dev Possible new project: OpenJDK LaF

[Mario Torre]

On Thu, 2014-08-28 at 12:04 +0200, Mario Torre wrote:
 On Wed, 2014-08-27 at 17:03 +0100, Martijn Verburg wrote:
  I think a move to GTK 3 would eliminate a class of java/Linux desktop
  issues we run across today. My concern would be the long term maintenance
  of this piece...

Given no further comments on this thread, I went ahead and created a
draft JEP proposal:

https://bugs.openjdk.java.net/browse/JDK-8065658

I would appreciate if you could comment on this and help me out moving
forward.

Please, ensure that all the replies happen to be on the swing-dev
mailing list.

Thanks!
Mario

Re: Why would most FontAwesome icons work but not one?

[Mario Torre]

On Fri, 2014-10-10 at 16:27 +0200, Mike Hearn wrote:
 I'm using FontAwesomeFX in my app (thanks for that guys!) and it works
 brilliantly  except for one icon (THUMB_TACK), that is being set as a
 graphic in a listview. It works fine on MacOS but renders only a box on
 Windows. The icon shows fine in the fontawesome website.
 
 The only explanation for this I can think of is that something is going
 wrong deep inside the Windows specific text rendering pipeline. Other FA
 icons work, so, I'm puzzled as to why that one might be different.
 
 Does this sort of thing ring any bells? I'm unsure where to begin the
 debugging process.

I've noticed this with some icons, double check that the font file
you're using in FontAwesomeFX does actually contain the icon,
FontAwesome seems to add new icons even in minor releases.

Cheers,
Mario

Re: Possible new project: OpenJDK LaF

[Mario Torre]

On Wed, 2014-08-27 at 17:03 +0100, Martijn Verburg wrote:
 I think a move to GTK 3 would eliminate a class of java/Linux desktop
 issues we run across today. My concern would be the long term maintenance
 of this piece...

Yeah, long term maintenance will surely be some overhead, like anything
that is added to the jdk.

The way I would target the development is to try to respect the common
denominator that works in the most important Linux distribution in their
long term support releases (Ubuntu LTS, RHEL 7 and derivatives, etc...).

Those distributions have very long term support so it should not be a
big problem with moving gtk version. For other variants, where gtk may
be more of a moving target, we need to count on users of those system to
help out, and we need to talk with gtk maintainers to ensure there's a
compatible set of features we need. Eclipse and Mozilla have the same
problem and from time to time it comes back to byte them, but that's the
way it is unfortunately.

I think we should also ensure that the look and feel can be swapped out
without harm, for example, avoiding that if the Gnome team ends up
rewriting things for the fun of it again, and gtk4 comes out, we can
just deploy the gtk3 version of the laf, together with the gtk2 and with
whatever the future gives us without it interfere (that is, if is not
used, it's like dead code, no classes loaded, no code touched at
runtime, nothing).

That basically means a very self contained look and feel, which is great
because it could be eventually used even on older JDK without troubles
as a plugin. Also, I don't thing I would like to make this the default
theme (which will be forever Metal) and not even the default native
theme, but having some way to configure a system wide default would be
neat (I think there's already some flags to drive the selection of the
default native theme, never really tried out how this works though). 

Cheers,
Mario

 On Wednesday, 27 August 2014, Mario Torre neug...@redhat.com wrote:
 
  Hi all,
 
  First of all, sorry for cross posting... I would like to kindly ask to
  direct all the replies to this thread to the discuss alias if
  possible.
 
  Is a bit of time I'm playing with the idea of implementing a proper GTK3
  look and feel for OpenJDK, something to make the jdk look a bit more
  modern and also take it as an opportunity to solve some of the issues
  the GTK2 laf has, including some related bugs like this:
 
  http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=729
 
  I mentored a Summer of Code project last year where we produced a more
  or less working and complete implementation. It was a student project
  and the efforts to make it well abstracted and tested are really as
  close as making a new implementation, however it was great to show that
  we could have a basic and functional implementation in less than a month
  of work, the new GTK3 library looks way nicer!
 
  At the same time, since Swing will be [very] gradually replaced by
  JavaFX, I think it would be awesome to have a JavaFX based look and
  feel, something I started to play with last year as well but then put on
  hold because of tons of other things to do:
 
  https://neugens.wordpress.com/2013/07/21/javafx-look-and-feel-for-swing/
 
  Recently I was convinced though that we should move forward with the
  Java laf: Swing has still lots to say, and JavaFX is not yet as
  integrated with OpenJDK as it should be (especially in Linux
  distribution, although is more popular within the OSX and Windows
  communities), but before I move forward (and get to propose a JEP for
  this) I would like some early feedback and gather some ideas/potential
  interest :)
 
  Another possible implementation would be based on QT, which is even
  cross platform by itself.
 
  So to recap, what are your feelings about an official OpenJDK look and
  feel collection?
 
  Cheers,
  Mario
 
 
 
 

Possible new project: OpenJDK LaF

[Mario Torre]

Hi all,

First of all, sorry for cross posting... I would like to kindly ask to
direct all the replies to this thread to the discuss alias if
possible.

Is a bit of time I'm playing with the idea of implementing a proper GTK3
look and feel for OpenJDK, something to make the jdk look a bit more
modern and also take it as an opportunity to solve some of the issues
the GTK2 laf has, including some related bugs like this:

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=729

I mentored a Summer of Code project last year where we produced a more
or less working and complete implementation. It was a student project
and the efforts to make it well abstracted and tested are really as
close as making a new implementation, however it was great to show that
we could have a basic and functional implementation in less than a month
of work, the new GTK3 library looks way nicer!

At the same time, since Swing will be [very] gradually replaced by
JavaFX, I think it would be awesome to have a JavaFX based look and
feel, something I started to play with last year as well but then put on
hold because of tons of other things to do:

https://neugens.wordpress.com/2013/07/21/javafx-look-and-feel-for-swing/

Recently I was convinced though that we should move forward with the
Java laf: Swing has still lots to say, and JavaFX is not yet as
integrated with OpenJDK as it should be (especially in Linux
distribution, although is more popular within the OSX and Windows
communities), but before I move forward (and get to propose a JEP for
this) I would like some early feedback and gather some ideas/potential
interest :)

Another possible implementation would be based on QT, which is even
cross platform by itself.

So to recap, what are your feelings about an official OpenJDK look and
feel collection?

Cheers,
Mario

Re: accessibility

[Mario Torre]

It would probably make sense to try doing this together rather than
waiting for things to happen, this way you could use this wonderful
workforce that your community is!

Can you maybe point to bugs and/or share with us specific issues (and
pain points) yet unresolved?

Cheers,
Mario

2013/12/16 Stephen F Northover steve.x.northo...@oracle.com:
 Hi Michael,

 Accessibility has been on and off the radar for OpenJFX for quite a while
 now.  Some preliminary work was done, but a final implementation and API was
 never reached.  Further, the people who were working on it either left the
 company or left to work some place else.  The thing that makes accessibility
 difficult is that it is platform specific, has a big API and touches many
 different component areas.  If you think about it, in the case of a visually
 impaired user, accessibility is presenting a widget system to be navigated
 that is independent of any output.

 Although nothing is official, we are looking to deliver accessibility in
 JDK9.  If something is ready earlier, it is possible that it could appear in
 an earlier release.

 Thanks for being so patient with us.

 Steve


 On 2013-12-15 7:15 AM, Michał Zegan wrote:

 Hello,

 I have the following question:
 Does javafx support or plan to support accessibility?
 Another question is: if it is planned, then for what release?






-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

IcedRobot: www.icedrobot.org
Proud GNU Classpath developer: http://www.classpath.org/
Read About us at: http://planet.classpath.org
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

Re: Scene Builder is now open source!

[Mario Torre]

On Tue, 2013-12-03 at 16:04 +0100, Simon Vienot wrote:
 Hello OpenJFXers !
 
 We're very happy to announce that Scene Builder is now open source, as a 
 part of the OpenJFX project.
 The whole Scene Builder functionality is available, including the SB Kit 
 API as well as the standalone SB application.
 The only part of the product which remains closed is the native 
 packaging/installer code.
 SB code is available in rt/apps/scenebuilder/ under the terms of a 
 BSD-style license, similar to JavaFX samples.
 
 You are all welcome to contribute.
 
 Thanks,
 -Simon.

Yuhu!

This is the best news since... well, since last best news ;)

You guys are really getting us used to that!

Congratulations!

Cheers,
Mario

Re: HEADS-UP: switching to gradle 1.8 for next week's build

[Mario Torre]

Hi Kevin,

Ok, so this should be the last change at least until the beginning of JFX9,
that's a good news.

Thanks,
Mario


2013/11/20 Kevin Rushforth kevin.rushfo...@oracle.com

  Hi Mario,

 We don't upgrade our build environment lightly or frequently, and this
 will be the last such upgrade for FX 8, since we are hitting rampdown phase
 2 in less than two weeks.

 Ordinarily, you should expect to receive more notice for these sort of
 changes, and they should be done as part of a milestone build or similar.

 -- Kevin



 Mario Torre wrote:


 2013/11/20 Kevin Rushforth kevin.rushfo...@oracle.com

 All,

 Primarily to fix https://javafx-jira.kenai.com/browse/RT-34171 we are
 upgrading our build environment for JavaFX 8 from gradle 1.4 to gradle 1.8.
 This will be done prior to next week's build for b118. I've been running
 gradle 1.8 for almost two weeks with no issues, and I know other have as
 well. We are doing final testing of the b117 bundles (a build of the b117
 sources using gradle-1.8 will be compared with the gradle-1.4-built
 production).

 It will continue to be buildable with gradle 1.4 unless / until someone
 pushes a change requiring 1.8, but all developers are encouraged to upgrade
 to gradle 1.8 at their earliest convenient.

 Let me know if you have any questions or concerns.

 -- Kevin



  Hi Kevin,

  Are you planning to upgrade the build often? If not, what are the plans
 and schedule for such updates?

  It is a real problem for Linux distribution to have a constantly moving
 build tool, making packaging of JavaFX next to impossible.

 Cheers,
  Mario

 --
 pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
 Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

 IcedRobot: www.icedrobot.org
 Proud GNU Classpath developer: http://www.classpath.org/
 Read About us at: http://planet.classpath.org
 OpenJDK: http://openjdk.java.net/projects/caciocavallo/

 Please, support open standards:
 http://endsoftpatents.org/




-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

IcedRobot: www.icedrobot.org
Proud GNU Classpath developer: http://www.classpath.org/
Read About us at: http://planet.classpath.org
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

Re: JMX is now open source

[Mario Torre]

This is awesome!

Cheers,
Mario
Il 30/ott/2013 23:06 Kevin Rushforth kevin.rushfo...@oracle.com ha
scritto:

 The JMX tooling code is now open-source in modules/jmx. This means that we
 really are down to just the following optional pieces that will remain
 closed: VP6, T2K, and deploy.

 -- Kevin

Re: Media is now opensource

[Mario Torre]

Great news!

What's the current state at this point? What is still missing?

Cheers,
Mario
Il 18/ott/2013 18:37 Kirill Kirichenko kirill.kiriche...@oracle.com ha
scritto:

 Hello OpenJFXers !
 We're happy to announce that Media part of JavaFX is now open source.
 Opensourcing touched all Media component except ON2 FLV demuxer and VP6
 decoder. The decoder will remain closed.

 You're all welcome to contribute.

 Thanks,
 K

Re: JNI and C++ exceptions

[Mario Torre]

Hmm, honestly, this is quite surprising, since afaik in JNI you only
need to check for Java type exceptions if the methods return anything
but a successful condition (that is, in JNI calls obviously), with the
specification requiring that exceptions should be deferred and
explicitly handled in code. Adding a native (C++ specific in this
case) exception to the library would hardly be correct, and in fact
I'm sure it's not:

http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/design.html


With C++, the extra level of indirection and the interface pointer
argument disappear from the source code. However, the underlying
mechanism is exactly the same as with C. In C++, JNI functions are
defined as inline member functions that expand to their C
counterparts.


This means the C and C++ APIs are speficied to be the same, to behave
the same, etc... If it were allowed to throw a native exception in C++
you would end up with two different APIs, which is hardly acceptable.

In my opinion this is a bug in this specific vendor platform, not in
JavaFX (or in OpenJDK), and we should not care about that.

Cheers,
Mario

2013/9/27 Artem Ananiev artem.anan...@oracle.com:
 Hi,

 here is a short question. In some JDK implementations (e.g. IBM's), JNI may
 throw C++ exceptions. For example, env-NewByteArray() throws bad_alloc.
 Right now in JDK/JavaFX native code we don't protect against that. Should
 we? An anti-pattern that some source scanning tools warn about is

 type obj = new type();
 if (!obj) {
   // handle that
 }
 env-SomeJNICall();

 If SomeJNICall() throws an exception, obj will never be deleted.
 Protection against bad_alloc doesn't make much sense, since we're out of
 memory anyway and will unlikely be able to recover, but what about other
 exceptions?

 Thanks,

 Artem



-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

IcedRobot: www.icedrobot.org
Proud GNU Classpath developer: http://www.classpath.org/
Read About us at: http://planet.classpath.org
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

Re: Why is almost everything in the API final

[Mario Torre]

On Tue, 2013-09-03 at 10:19 -0500, David Ray wrote:
 Final methods more so take the control out of the hands of the many 
 developers, and places it in the hands of the API designers.
 If there is an issue, and demands are high - would we rather 
 
 A. Report the issue and wait for the original API designer's development 
 process to acknowledge, repair, and release a fix?
 
 -or-
 
 B. Report the issue to begin the above process, and improvise a workable 
 workaround that let's a developer continue on with their work?
 
 I too observed the advantages of being able to do this in SWING countless 
 times…
 
 Just a thought…
 

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

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

Cheers,
Mario

Re: Java Deployment (was Re: JavaFX 8 Progress)

[Mario Torre]

Hi Mark,

NetX is the component used by IcedTea-web, the open replacement for the JDK
plugin. Is not formally part of OpenJDK, but Linux distribution use this,
and us also compatible at least on Windows.

OpenJDK itself doesn't have a plugin component.

OpenJFX should work with IcedTea in theory, but I think the code does some
assumption on what is available on the platform, so probably there is still
some work to do to ensure perfect compliance.

Cheers,
Mario
Il giorno 20/lug/2013 19:27, Mark Fortner phidia...@gmail.com ha
scritto:

 Coincidentally, I was upgrading my ubuntu box recently and noticed that it
 installed NetX (an open source JNLP alternative by default).
 http://jnlp.sourceforge.net/netx/index.html

 I'm not sure what the status is and how this fits into the openjdk vision
 of the world.

 Cheers,

 Mark



 On Thu, Jul 18, 2013 at 11:41 PM, John C. Turnbull
 ozem...@ozemail.com.auwrote:

  What's the performance like?
 
  What version of Java does it support?
 
  Is it a subset of the JRE or complete?
 
  -Original Message-
  From: openjfx-dev-boun...@openjdk.java.net
  [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Sven Reimers
  Sent: Friday, 19 July 2013 15:01
  To: Daniel Zwolenski
  Cc: openjfx-dev@openjdk.java.net; mike.ehrenberg@barchart.comEhrenberg;
  JeremyJongsma
  Subject: Re: Java Deployment (was Re: JavaFX 8 Progress)
 
  A Java Runtime on top of JavaScript -
  http://wiki.apidesign.org/wiki/Bck2Brwsr
 
  -Sven
 
 
  On Fri, Jul 19, 2013 at 12:37 AM, Daniel Zwolenski zon...@gmail.com
  wrote:
 
   Yes this is another option, basically running it on a server and then
   rendering on the client. JavaFX could be extended to do this.
  
   Another alternative is a 'java runtime' built on top of jscript
   (similar idea to the runtime being built for mobile, like robovm). In
   this cases jfx would run 100% in the browser on top of jscript.
  
   Another option is a runtime built for the native elements of each
  browser.
   Eg a runtime running on chrome's native interface, etc.
  
   All of the above would require a lot of work before being ready to use
   and likely would have some tradeoffs in terms of features or
   performance. The options I listed in the last email are in my opinion
   more achievable in the short term and generally give decent results.
  
   Right now, if you want to deploy jfx my pick suggestion would be
   completely avoid any of the oracle solutions and just pay the licence
   fee for install4j. Although I'd not seen jwrapper until just now and
   it could do with some looking into too.
  
   On 19/07/2013, at 8:10 AM, Mario Torre
   neugens.limasoftw...@gmail.com
   wrote:
  
For Swing you can actually use CacioWeb, works quite well. Zero
   deployment, no VM needed, no plugin, just an HTML 5 capable browser.
   
Doesn't work with JavaFX unfortunately.
   
Cheers,
Mario
   
Il giorno 19/lug/2013 00:03, Daniel Zwolenski zon...@gmail.com
ha
   scritto:

 There are definitely credible alternatives. The problem is
 currently
   the alternatives are not implemented well enough so web still ends up
   a contender just by being the only one able to stand up.

 And for the record I build both public facing apps and back-office
   apps and web deploy does not work well for either. I stopped using jfx
   because of deployment. I now build only webapps because of deployment.

 Credible alternatives:

 1. Native bundlers, but we need:
 - auto updating so people can easily release patch updates
 - smaller co-bundled jre's so that the initial download and
 install is
   smooth and quick
 - better build tools to make this easier to integrate into a
 standard
   build process, with some solution for cross-platform build support or
   to at least minimize the pain

 2. App stores:
 - ready to go right now for Mac but we don't have the tools and I
   think we need everything fully open sourced for licensing reasons
   (hard to
   say)
 - need to either pick one of the unofficial win app stores for
   pre-win8 support (there's a few), or build our own app store
 - we just need tools for building and deploying to app stores (not
   that hard) and cut down jre sizes again (app stores are an extension
   of cobundling approach).

 3. Self-hosted 'app store' for corporate settings. install a
 small,
   native client on the machine that allows that user to download and
   install apps from your private server, with auto-updating, etc
 - we need to build one, not that hard, maybe a month or two of
 work to
   get a first working version out. I would have built one by now but
   because jfx packaging tools are so bad I've burnt up all my spare time
   just putting wrappers around these to get the most basic of maven
 plugins
  to work.

 All of the above could have been implemented by now if there was
 just
   a little bit

Re: Java Deployment (was Re: JavaFX 8 Progress)

[Mario Torre]

For Swing you can actually use CacioWeb, works quite well. Zero deployment,
no VM needed, no plugin, just an HTML 5 capable browser.

Doesn't work with JavaFX unfortunately.

Cheers,
Mario

Il giorno 19/lug/2013 00:03, Daniel Zwolenski zon...@gmail.com ha
scritto:

 There are definitely credible alternatives. The problem is currently the
alternatives are not implemented well enough so web still ends up a
contender just by being the only one able to stand up.

 And for the record I build both public facing apps and back-office apps
and web deploy does not work well for either. I stopped using jfx because
of deployment. I now build only webapps because of deployment.

 Credible alternatives:

 1. Native bundlers, but we need:
 - auto updating so people can easily release patch updates
 - smaller co-bundled jre's so that the initial download and install is
smooth and quick
 - better build tools to make this easier to integrate into a standard
build process, with some solution for cross-platform build support or to at
least minimize the pain

 2. App stores:
 - ready to go right now for Mac but we don't have the tools and I think
we need everything fully open sourced for licensing reasons (hard to say)
 - need to either pick one of the unofficial win app stores for pre-win8
support (there's a few), or build our own app store
 - we just need tools for building and deploying to app stores (not that
hard) and cut down jre sizes again (app stores are an extension of
cobundling approach).

 3. Self-hosted 'app store' for corporate settings. install a small,
native client on the machine that allows that user to download and install
apps from your private server, with auto-updating, etc
 - we need to build one, not that hard, maybe a month or two of work to
get a first working version out. I would have built one by now but because
jfx packaging tools are so bad I've burnt up all my spare time just putting
wrappers around these to get the most basic of maven plugins to work.

 All of the above could have been implemented by now if there was just a
little bit of love in this area. One resource ticking away would have been
enough to get something going. As it stands there has been zero, nada, zip
changes into anything other than web/security deployment efforts over the
last year. J8 due next year (!) will not include any of the above, or even
any simple improvements to deployment approaches other than web, to the
best of my knowledge.



 On 19/07/2013, at 7:30 AM, Mark Fortner phidia...@gmail.com wrote:

  I've heard the webstart is broke, don't fix it, move on song before
from a number of people.  What I haven't heard is a credible solution to
solving the very real problem of keeping an app up-to-date in a corporate
setting.  For the most part, I agree that if you're in the business of
selling commercial software, selling and distributing through an app store
probably makes sense for you. Although I wouldn't relish having to build on
all of those platforms.
 
  However, posting proprietary apps to external OS-specific app stores
doesn't really work for anyone in a corporate setting.  Neither does making
a user re-install an application every time you post a bug fix.  In
addition, many corporations limit the privileges they give users.
 
  Cheers,
 
  Mark
 
 

Re: [API Review]: Node validation

[Mario Torre]

On Mon, 2013-07-08 at 14:20 +0200, Martin Sladecek wrote:
 The plan is to have a final validate() method.
 Anyway, does anybody have a better suggestion? The validate should do 
 both CSS and layout and I would like to avoid method name that's too 
 descriptive (like validateLayoutAndCSS()) if possible.
 I think the most important thing about the method is that it validates 
 the bounds/metrics of the Node, so maybe validateBounds() ?

What about simply doLayout()?

It seems to me that layouting is strictly correlated to CSS, and
doLayout seems a pretty descriptive name for that purpose.

Cheers,
Mario

Gradle build, one step forward, two backward :)

[Mario Torre]

Hi all!

I tried to compile JavaFX with the gradle build, and here are my
results, with different settings:

 1. *** Closed Everything ***

JAVA_HOME=/closed/jdk-8-ea-96/
BINARY_STUB=/closed/jdk-8-ea-96/jre/lib/ext/jfxrt.jar

[neugens@galactica rt]$ gradle jfxrt
 Loading
...

:jfxrtLinux
:jfxrt

BUILD SUCCESSFUL

Running an Hello World with the same configuration, but removing the
closed jfxrt.jar still fails:

Caused by: java.lang.NullPointerException
at
com.sun.javafx.font.PrismFontLoader.loadFont(PrismFontLoader.java:220)
at javafx.scene.text.Font.init(Font.java:318)
at javafx.scene.text.Font.getDefault(Font.java:85)
at javafx.scene.CssStyleHelper.clinit(CssStyleHelper.java:1329)

:(

Was't the font code open sourced?


 2. ***  OpenJDK with closed jfxrt.jar ***

The OpenJDK build fails before getting anywhere, which is very
surprising to me:

JAVA_HOME=/open/jdk-8/
BINARY_STUB=/closed/jdk-8-ea-96/jre/lib/ext/jfxrt.jar

[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on
artifact cache (/home/neugens/.gradle/caches/artifacts-23).
[org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter]
Finished executing task ':graphics:compileJava'
[ERROR] [org.gradle.BuildExceptionReporter] FAILURE: Build failed with
an exception.
* What went wrong:
Could not resolve all dependencies for configuration
':graphics:compile'.
 Could not find :plugin:.
Required by: rt:graphics:unspecified
* Exception is:
org.gradle.api.artifacts.ResolveException: Could not resolve all
dependencies for configuration ':graphics:compile'.
at
org.gradle.api.internal.artifacts.ivyservice.DefaultLenientConfiguration.rethrowFailure(DefaultLenientConfiguration.java:52)
at
org.gradle.api.internal.artifacts.ivyservice.DefaultResolvedConfiguration.rethrowFailure(DefaultResolvedConfiguration.java:36)

Any help here would be great... I don't see why OpenJDK is not able to
build OpenJFX, even having the closed jar in the path.

3. *** Closed JDK with openjfxrt.jar ***

This fails. I expected this, but the build goes very far it seems:

public final class AudioClipBuilder implements
javafx.util.Builderjavafx.scene.media.AudioClip
[...]

symbol:   class WebEvent
location: class WebEngineBuilder
error: cannot find symbol
[...]

4. ***  OpenJDK with just created open jfxrt.jar ***

Well, you guessed this fails too... I wonder how the iOS people got
their code working at all... Is there any secret repository you guys are
using?

5. *** Running OpenJDK with closed jfxrt.jar ***

This is even nicer:

Graphics Device initialization failed for :  es2, sw
Error initializing QuantumRenderer: no suitable pipeline found
java.lang.RuntimeException: java.lang.RuntimeException: Error
initializing QuantumRenderer: no suitable pipeline found
[...]
Caused by: java.lang.RuntimeException: No toolkit found
at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:213)
at
com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:181)
at
com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:637)
at
com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:345)
at
com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:304)

I think the OpenJDK build (2.) and running closed jfrt.jar + OpenJDK
(5.) are the most serious issues at the moment.

I remember that running closed jfx with OpenJDK used to work, but maybe
I'm wrong.

Any plans to address that, or hints where I can start looking to help
out?

Cheers,
Mario