Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #38117 > unrolled thread

JavaFX disappearing in Java 11

Back to article view | Back to comp.lang.java.programmer

Contents

  JavaFX disappearing in Java 11 Chris Riesbeck <Chris.Riesbeck@gmail.com> - 2018-03-08 13:10 -0600
    Re: JavaFX disappearing in Java 11 Arne Vajhøj <arne@vajhoej.dk> - 2018-03-08 14:15 -0500
      Re: JavaFX disappearing in Java 11 Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2018-03-09 08:30 +0800
        Re: JavaFX disappearing in Java 11 Arne Vajhøj <arne@vajhoej.dk> - 2018-03-08 19:37 -0500
          Re: JavaFX disappearing in Java 11 Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2018-03-09 11:09 +0800
          Re: JavaFX disappearing in Java 11 Eric Douglas <e.d.programmer@gmail.com> - 2018-03-09 05:19 -0800
            Re: JavaFX disappearing in Java 11 Silvio <silvio@internet.com> - 2018-03-10 00:02 +0100
              Re: JavaFX disappearing in Java 11 Arne Vajhøj <arne@vajhoej.dk> - 2018-03-09 19:28 -0500
                Re: JavaFX disappearing in Java 11 Silvio <silvio@internet.com> - 2018-03-10 03:12 +0100
                  Re: JavaFX disappearing in Java 11 Arne Vajhøj <arne@vajhoej.dk> - 2018-03-09 21:28 -0500
                    Re: JavaFX disappearing in Java 11 Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2018-03-10 21:41 +0800
                      Re: JavaFX disappearing in Java 11 Arne Vajhøj <arne@vajhoej.dk> - 2018-03-10 21:09 -0500
                        Re: JavaFX disappearing in Java 11 Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2018-03-11 10:46 +0800
                          Re: JavaFX disappearing in Java 11 Arne Vajhøj <arne@vajhoej.dk> - 2018-03-10 22:39 -0500
            Re: JavaFX disappearing in Java 11 Arne Vajhøj <arne@vajhoej.dk> - 2018-03-09 19:23 -0500
        Re: JavaFX disappearing in Java 11 Ricardo Palomares Martinez <rpm.NOADS@proyectonave.es> - 2018-03-10 19:20 +0100
          Re: JavaFX disappearing in Java 11 Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2018-03-11 10:49 +0800
            Re: JavaFX disappearing in Java 11 Gene Wirchenko <genew@telus.net> - 2018-03-12 15:36 -0700
    Re: JavaFX disappearing in Java 11 Eric Douglas <e.d.programmer@gmail.com> - 2018-03-08 11:49 -0800
      Re: JavaFX disappearing in Java 11 Arne Vajhøj <arne@vajhoej.dk> - 2018-03-08 15:00 -0500
        Re: JavaFX disappearing in Java 11 Eric Douglas <e.d.programmer@gmail.com> - 2018-03-08 12:32 -0800
          Re: JavaFX disappearing in Java 11 Arne Vajhøj <arne@vajhoej.dk> - 2018-03-08 16:51 -0500
            Re: JavaFX disappearing in Java 11 Daniele Futtorovic <da.futt.news@laposte.net> - 2018-03-09 00:57 +0100
              Re: JavaFX disappearing in Java 11 Arne Vajhøj <arne@vajhoej.dk> - 2018-03-08 19:20 -0500
                Re: JavaFX disappearing in Java 11 Arne Vajhøj <arne@vajhoej.dk> - 2018-03-08 19:23 -0500
                  Re: JavaFX disappearing in Java 11 Arne Vajhøj <arne@vajhoej.dk> - 2018-03-08 19:28 -0500
                Re: JavaFX disappearing in Java 11 Martin Gregorie <martin@mydomain.invalid> - 2018-03-09 08:44 +0000
              Re: JavaFX disappearing in Java 11 Silvio <silvio@internet.com> - 2018-03-10 00:03 +0100
                Re: JavaFX disappearing in Java 11 Arne Vajhøj <arne@vajhoej.dk> - 2018-03-09 19:20 -0500
                  Re: JavaFX disappearing in Java 11 Silvio <silvio@internet.com> - 2018-03-10 03:07 +0100
                    Re: JavaFX disappearing in Java 11 Arne Vajhøj <arne@vajhoej.dk> - 2018-03-09 21:32 -0500
                    Re: JavaFX disappearing in Java 11 Daniele Futtorovic <da.futt.news@laposte.net> - 2018-03-10 09:50 +0100
                      Re: JavaFX disappearing in Java 11 Silvio <silvio@internet.com> - 2018-03-10 16:39 +0100
                        Re: JavaFX disappearing in Java 11 Arne Vajhøj <arne@vajhoej.dk> - 2018-03-10 21:06 -0500
                          Re: JavaFX disappearing in Java 11 Eric Douglas <e.d.programmer@gmail.com> - 2018-03-12 06:50 -0700
                            Re: JavaFX disappearing in Java 11 Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2018-03-12 23:41 +0800
                              Re: JavaFX disappearing in Java 11 Eric Douglas <e.d.programmer@gmail.com> - 2018-03-12 09:10 -0700
                                Re: JavaFX disappearing in Java 11 Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2018-03-13 07:33 +0800
                                Re: JavaFX disappearing in Java 11 Arne Vajhøj <arne@vajhoej.dk> - 2018-03-12 20:15 -0400
                                  Re: JavaFX disappearing in Java 11 Eric Douglas <e.d.programmer@gmail.com> - 2018-03-13 05:46 -0700
                                    Re: JavaFX disappearing in Java 11 Arne Vajhøj <arne@vajhoej.dk> - 2018-03-13 09:55 -0400
                                  Re: JavaFX disappearing in Java 11 Eric Douglas <e.d.programmer@gmail.com> - 2018-03-13 06:42 -0700
                                    Re: JavaFX disappearing in Java 11 Arne Vajhøj <arne@vajhoej.dk> - 2018-03-13 09:50 -0400
                                      Re: JavaFX disappearing in Java 11 Eric Douglas <e.d.programmer@gmail.com> - 2018-03-13 06:57 -0700
                                        Re: JavaFX disappearing in Java 11 Arne Vajhøj <arne@vajhoej.dk> - 2018-03-13 10:08 -0400
                                          Re: JavaFX disappearing in Java 11 Eric Douglas <e.d.programmer@gmail.com> - 2018-03-13 07:58 -0700
                                            Re: JavaFX disappearing in Java 11 Arne Vajhøj <arne@vajhoej.dk> - 2018-03-15 12:23 -0400
                                Re: JavaFX disappearing in Java 11 Silvio <silvio@internet.com> - 2018-03-13 02:28 +0100
                                  Re: JavaFX disappearing in Java 11 Martin Gregorie <martin@mydomain.invalid> - 2018-03-13 11:39 +0000
                                    Re: JavaFX disappearing in Java 11 Arne Vajhøj <arne@vajhoej.dk> - 2018-03-13 07:54 -0400
                                      Re: JavaFX disappearing in Java 11 Martin Gregorie <martin@mydomain.invalid> - 2018-03-13 12:45 +0000
                                    Re: JavaFX disappearing in Java 11 Eric Douglas <e.d.programmer@gmail.com> - 2018-03-13 05:42 -0700
                                      Re: JavaFX disappearing in Java 11 Daniele Futtorovic <da.futt.news@laposte.net> - 2018-03-13 23:27 +0100
                                        Re: JavaFX disappearing in Java 11 Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2018-03-14 08:35 +0800
                                          Re: JavaFX disappearing in Java 11 Eric Douglas <e.d.programmer@gmail.com> - 2018-03-14 05:03 -0700
                                        Re: JavaFX disappearing in Java 11 Eric Douglas <e.d.programmer@gmail.com> - 2018-03-14 05:08 -0700
                                          Re: JavaFX disappearing in Java 11 Daniele Futtorovic <da.futt.news@laposte.net> - 2018-03-15 11:50 +0100
                                            Re: JavaFX disappearing in Java 11 Eric Douglas <e.d.programmer@gmail.com> - 2018-03-15 05:47 -0700
                                          Re: JavaFX disappearing in Java 11 Martin Gregorie <martin@mydomain.invalid> - 2018-03-15 12:28 +0000
                                        Re: JavaFX disappearing in Java 11 Eric Douglas <e.d.programmer@gmail.com> - 2018-03-14 12:08 -0700
                          Re: JavaFX disappearing in Java 11 Daniele Futtorovic <da.futt.news@laposte.net> - 2018-03-13 00:58 +0100
                            Re: JavaFX disappearing in Java 11 Arne Vajhøj <arne@vajhoej.dk> - 2018-03-12 20:02 -0400
                      Re: JavaFX disappearing in Java 11 Arne Vajhøj <arne@vajhoej.dk> - 2018-03-10 21:03 -0500
                        Re: JavaFX disappearing in Java 11 Eric Douglas <e.d.programmer@gmail.com> - 2018-03-12 05:45 -0700
                          Re: JavaFX disappearing in Java 11 Arne Vajhøj <arne@vajhoej.dk> - 2018-03-12 20:07 -0400
              Re: JavaFX disappearing in Java 11 Uniqua Lykerd <uniqualykerd@protonmail.com> - 2018-03-29 21:22 -0400
                Re: JavaFX disappearing in Java 11 Daniele Futtorovic <da.futt.news@laposte.net> - 2018-03-30 04:37 +0200
    Re: JavaFX disappearing in Java 11 Gianluca Bonetti <gianluca.bonetti@gmail.com> - 2018-03-11 09:59 -0700
      Re: JavaFX disappearing in Java 11 Arne Vajhøj <arne@vajhoej.dk> - 2018-03-12 20:17 -0400

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#38121

On Thursday, March 8, 2018 at 3:00:28 PM UTC-5, Arne Vajhøj wrote:
> On 3/8/2018 2:49 PM, Eric Douglas wrote:
> > On Thursday, March 8, 2018 at 2:10:57 PM UTC-5, Chris Riesbeck wrote:
> >> https://www.infoworld.com/article/3261066/java/javafx-will-be-removed-from-the-java-jdk.html
> >>
> >> While I won't miss JavaFX per se, just this morning I changed some code
> >> to use java.util.javafx.Pair.
> >>
> >> I can still use java.util.AbstractMap.SimpleImmutableEntry, or roll my
> >> own, but, jeepers, my timing was off.
> >>
> >> And yes, I've read this great thread on whether a Pair is good idea:
> >>
> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-March/thread.html#3973
> > 
> > Your subject line is misleading.  It's not disappearing, it's being
> > decoupled into it's own module.  I don't yet fully understand Java 9,
> > how to compile, or how the modules are maintained and distributed,
> > but Java FX will very much be a part of Java.
> "broken out into its own separate module" means separate product not
> separate module.
> 
> JavaFX was already put in 8 separate modules in Java 9.
> 
> And later they state:
> 
> "with the faster release schedule being implemented for standard Java 
> and the JDK, JavaFX needs to be on its own pace"
> 
> "JavaFX will be removed from the Java JDK as of JDK 11, which is due in 
> September 2018"
> 
> Arne

I don't understand modules, or Java FX.
I thought Java EE was "removed from the JDK" in Java 9?  You can add a flag to recognize it.
Does Java EE continue to be supported as part of a JDK?
Java FX will continue to be supported, but will require a separate install for the JDK?  What about the JRE?  Do end users need 2 separate installs?
I thought Java FX was supposed to be a replacement for Swing.  The only thing I've done with it is implement the HTML viewer into a Swing app.

[toc] | [prev] | [next] | [standalone]

#38122

On 3/8/2018 3:32 PM, Eric Douglas wrote:
> On Thursday, March 8, 2018 at 3:00:28 PM UTC-5, Arne Vajhøj wrote:
>> On 3/8/2018 2:49 PM, Eric Douglas wrote:
>>> On Thursday, March 8, 2018 at 2:10:57 PM UTC-5, Chris Riesbeck wrote:
>>>> https://www.infoworld.com/article/3261066/java/javafx-will-be-removed-from-the-java-jdk.html
>>>>
>>>> While I won't miss JavaFX per se, just this morning I changed some code
>>>> to use java.util.javafx.Pair.
>>>>
>>>> I can still use java.util.AbstractMap.SimpleImmutableEntry, or roll my
>>>> own, but, jeepers, my timing was off.
>>>>
>>>> And yes, I've read this great thread on whether a Pair is good idea:
>>>>
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-March/thread.html#3973
>>>
>>> Your subject line is misleading.  It's not disappearing, it's being
>>> decoupled into it's own module.  I don't yet fully understand Java 9,
>>> how to compile, or how the modules are maintained and distributed,
>>> but Java FX will very much be a part of Java.
>> "broken out into its own separate module" means separate product not
>> separate module.
>>
>> JavaFX was already put in 8 separate modules in Java 9.
>>
>> And later they state:
>>
>> "with the faster release schedule being implemented for standard Java
>> and the JDK, JavaFX needs to be on its own pace"
>>
>> "JavaFX will be removed from the Java JDK as of JDK 11, which is due in
>> September 2018"
> 
> I don't understand modules, or Java FX.
> I thought Java EE was "removed from the JDK" in Java 9?  You can add a flag to recognize it.
> Does Java EE continue to be supported as part of a JDK?

Java EE has always been separate on top of Java SE (JDK and JRE).

Well - a few pieces actually went into Java SE, but they are supposedly
also being removed in Java 11.

> Java FX will continue to be supported, but will require a separate install for the JDK?

That is how I read it.

> What about the JRE? 

Not clear to me.

>                      Do end users need 2 separate installs?

For development: yes. For running: not clear to me.

> I thought Java FX was supposed to be a replacement for Swing.

It is.

And pretty nice. IMHO.

Arne

[toc] | [prev] | [next] | [standalone]

#38123

On 2018-03-08 22:51, Arne Vajhøj wrote:
> On 3/8/2018 3:32 PM, Eric Douglas wrote:
>>                      Do end users need 2 separate installs?
> 
> For development: yes. For running: not clear to me.

I can't imagine they would possibly require an additional install for a
user to run JavaFX apps. Especially not when having to install the JRE
is already a hurdle (to Java-on-the-desktop at least) in many places.

Note that they're talking about the JDK in that article, not the JRE.
End users don't (need to) install the JDK.

-- 
DF.

[toc] | [prev] | [next] | [standalone]

#38124

On 3/8/2018 6:57 PM, Daniele Futtorovic wrote:
> On 2018-03-08 22:51, Arne Vajhøj wrote:
>> On 3/8/2018 3:32 PM, Eric Douglas wrote:
>>>                       Do end users need 2 separate installs?
>>
>> For development: yes. For running: not clear to me.
> 
> I can't imagine they would possibly require an additional install for a
> user to run JavaFX apps. Especially not when having to install the JRE
> is already a hurdle (to Java-on-the-desktop at least) in many places.
> 
> Note that they're talking about the JDK in that article, not the JRE.
> End users don't (need to) install the JDK.

Yes. But the same article use the term "module" in a rather
misleading way, so I did not want to assume the article
was 100% correct regarding it being only JDK.

Arne

[toc] | [prev] | [next] | [standalone]

#38125

On 3/8/2018 7:20 PM, Arne Vajhøj wrote:
> On 3/8/2018 6:57 PM, Daniele Futtorovic wrote:
>> On 2018-03-08 22:51, Arne Vajhøj wrote:
>>> On 3/8/2018 3:32 PM, Eric Douglas wrote:
>>>>                       Do end users need 2 separate installs?
>>>
>>> For development: yes. For running: not clear to me.
>>
>> I can't imagine they would possibly require an additional install for a
>> user to run JavaFX apps. Especially not when having to install the JRE
>> is already a hurdle (to Java-on-the-desktop at least) in many places.
>>
>> Note that they're talking about the JDK in that article, not the JRE.
>> End users don't (need to) install the JDK.
> 
> Yes. But the same article use the term "module" in a rather
> misleading way, so I did not want to assume the article
> was 100% correct regarding it being only JDK.

But a bit of googling indicate that indeed may be
only a developer thing.

https://blogs.oracle.com/java-platform-group/the-future-of-javafx-and-other-java-client-roadmap-updates

also says JDK.

And it says:

"With the Java Platform Module System in place since Java SE 9, it now 
more viable to decouple JavaFX from the JDK, in order to make it 
available as a separate download.  This will make it easier for 
developers using JavaFX to have more freedom and flexibility with the 
framework."

So an Oracle SrDir product management also talking about JDK
and developers seems to be a good indication that the runtime
may still be in JRE.

Arne

[toc] | [prev] | [next] | [standalone]

#38126

On 3/8/2018 7:23 PM, Arne Vajhøj wrote:
> On 3/8/2018 7:20 PM, Arne Vajhøj wrote:
>> On 3/8/2018 6:57 PM, Daniele Futtorovic wrote:
>>> On 2018-03-08 22:51, Arne Vajhøj wrote:
>>>> On 3/8/2018 3:32 PM, Eric Douglas wrote:
>>>>>                       Do end users need 2 separate installs?
>>>>
>>>> For development: yes. For running: not clear to me.
>>>
>>> I can't imagine they would possibly require an additional install for a
>>> user to run JavaFX apps. Especially not when having to install the JRE
>>> is already a hurdle (to Java-on-the-desktop at least) in many places.
>>>
>>> Note that they're talking about the JDK in that article, not the JRE.
>>> End users don't (need to) install the JDK.
>>
>> Yes. But the same article use the term "module" in a rather
>> misleading way, so I did not want to assume the article
>> was 100% correct regarding it being only JDK.
> 
> But a bit of googling indicate that indeed may be
> only a developer thing.
> 
> https://blogs.oracle.com/java-platform-group/the-future-of-javafx-and-other-java-client-roadmap-updates 
> 
> 
> also says JDK.
> 
> And it says:
> 
> "With the Java Platform Module System in place since Java SE 9, it now 
> more viable to decouple JavaFX from the JDK, in order to make it 
> available as a separate download.  This will make it easier for 
> developers using JavaFX to have more freedom and flexibility with the 
> framework."
> 
> So an Oracle SrDir product management also talking about JDK
> and developers seems to be a good indication that the runtime
> may still be in JRE.

That blog post has a link to:
 
http://www.oracle.com/technetwork/java/javase/javaclientroadmapupdate2018mar-4414431.pdf

Which has more interesting info:

<quote>
Executive Summary:
* The public availability of Java SE 8 updates from Oracle has been 
extended to January 20191. Moreover, Oracle will continue to provide 
consumers with updates for personal (non-corporate) use of Java SE 8 
through at least the end of 2020.
* Oracle will continue to support Java SE 8 Web Start applications for 
public and personal (non-corporate, non-commercial) use to the same 
dates noted above. Oracle encourages developers relying on these 
deployment options for the delivery of applications to consumers to 
migrate to other solutions.
* Oracle will continue to commercially support Java Web Start on Java SE 
8 for commercial use, or when used in conjunction with Oracle products 
that have a Web Start dependency, through at least March 2025.
* As announced in 2015, Applets will continue to be supported in Java SE 
8 until at least March, 2019, pending continued support by browser 
vendors, after which they may be removed at any time.
* JavaFX new fixes will continue to be supported on Java SE 8 through 
March 2022 and removed from Java SE 11.
* Swing and AWT will continue to be supported on Java SE 8 through at 
least March 2025, and on Java SE 11 (18.9 LTS) through at least 
September 2026.
* Oracle has begun conversations with interested parties in the Java 
ecosystem on the stewardship of JavaFX, Swing and AWT beyond the above 
referenced timeframes.
</quote>

It sounds like the entire Java desktop is going to be separated
out long term.

Arne

[toc] | [prev] | [next] | [standalone]

#38130

On Thu, 08 Mar 2018 19:20:39 -0500, Arne Vajhøj wrote:

> Yes. But the same article use the term "module" in a rather misleading
> way, so I did not want to assume the article was 100% correct regarding
> it being only JDK.
>
In this situation might 'module' mean jarfile(s) + javadocs?


-- 
Martin    | martin at
Gregorie  | gregorie dot org

[toc] | [prev] | [next] | [standalone]

#38133

On 09-03-18 00:57, Daniele Futtorovic wrote:
> On 2018-03-08 22:51, Arne Vajhøj wrote:
>> On 3/8/2018 3:32 PM, Eric Douglas wrote:
>>>                       Do end users need 2 separate installs?
>>
>> For development: yes. For running: not clear to me.
> 
> I can't imagine they would possibly require an additional install for a
> user to run JavaFX apps. Especially not when having to install the JRE
> is already a hurdle (to Java-on-the-desktop at least) in many places.
> 
> Note that they're talking about the JDK in that article, not the JRE.
> End users don't (need to) install the JDK.
> 

It's going out. JDK and JRE.

Not that it matters because user want to (or are allowed to) install 
neither of them.

[toc] | [prev] | [next] | [standalone]

#38134

On 3/9/2018 6:03 PM, Silvio wrote:
> On 09-03-18 00:57, Daniele Futtorovic wrote:
>> On 2018-03-08 22:51, Arne Vajhøj wrote:
>>> On 3/8/2018 3:32 PM, Eric Douglas wrote:
>>>>                       Do end users need 2 separate installs?
>>>
>>> For development: yes. For running: not clear to me.
>>
>> I can't imagine they would possibly require an additional install for a
>> user to run JavaFX apps. Especially not when having to install the JRE
>> is already a hurdle (to Java-on-the-desktop at least) in many places.
>>
>> Note that they're talking about the JDK in that article, not the JRE.
>> End users don't (need to) install the JDK.
> 
> It's going out. JDK and JRE.

JavaFX runtime being removed from JRE - has that been
stated anywhere?

Arne

[toc] | [prev] | [next] | [standalone]

#38137

On 10-03-18 01:20, Arne Vajhøj wrote:
> On 3/9/2018 6:03 PM, Silvio wrote:
>> On 09-03-18 00:57, Daniele Futtorovic wrote:
>>> On 2018-03-08 22:51, Arne Vajhøj wrote:
>>>> On 3/8/2018 3:32 PM, Eric Douglas wrote:
>>>>>                       Do end users need 2 separate installs?
>>>>
>>>> For development: yes. For running: not clear to me.
>>>
>>> I can't imagine they would possibly require an additional install for a
>>> user to run JavaFX apps. Especially not when having to install the JRE
>>> is already a hurdle (to Java-on-the-desktop at least) in many places.
>>>
>>> Note that they're talking about the JDK in that article, not the JRE.
>>> End users don't (need to) install the JDK.
>>
>> It's going out. JDK and JRE.
> 
> JavaFX runtime being removed from JRE - has that been
> stated anywhere?
> 
> Arne
> 

Nowhere, other than JDK has always been a superset of JRE.

Why on earth would they drop it from the JDK and leave it in the JRE? 
That makes no sense at all. Existing install will keep running on old 
JREs and new install can simply pull in the extra package.

[toc] | [prev] | [next] | [standalone]

#38140

On 3/9/2018 9:07 PM, Silvio wrote:
> On 10-03-18 01:20, Arne Vajhøj wrote:
>> On 3/9/2018 6:03 PM, Silvio wrote:
>>> On 09-03-18 00:57, Daniele Futtorovic wrote:
>>>> On 2018-03-08 22:51, Arne Vajhøj wrote:
>>>>> On 3/8/2018 3:32 PM, Eric Douglas wrote:
>>>>>>                       Do end users need 2 separate installs?
>>>>>
>>>>> For development: yes. For running: not clear to me.
>>>>
>>>> I can't imagine they would possibly require an additional install for a
>>>> user to run JavaFX apps. Especially not when having to install the JRE
>>>> is already a hurdle (to Java-on-the-desktop at least) in many places.
>>>>
>>>> Note that they're talking about the JDK in that article, not the JRE.
>>>> End users don't (need to) install the JDK.
>>>
>>> It's going out. JDK and JRE.
>>
>> JavaFX runtime being removed from JRE - has that been
>> stated anywhere?
> 
> Nowhere, other than JDK has always been a superset of JRE.
> 
> Why on earth would they drop it from the JDK and leave it in the JRE? 
> That makes no sense at all. Existing install will keep running on old 
> JREs and new install can simply pull in the extra package.

Remember that JavaFX development was added to JDK in Java 8, but
JavaFX runtime was added in Java 7 update 6, so there are a bit
of precedence for having runtime available but not the development
kit.

That does not prove that Java 11 will be similar. It just indicate
that it is a possibility.

Arne

[toc] | [prev] | [next] | [standalone]

#38141

On 2018-03-10 03:07, Silvio wrote:
>> JavaFX runtime being removed from JRE - has that been
>> stated anywhere?
>>
> Nowhere, other than JDK has always been a superset of JRE.

That's like saying the Java developers are a superset of the Java users.
A tenuous proposition.

> Why on earth would they drop it from the JDK and leave it in the JRE?

Allegedly, because they're moving to a more structured release schedule
for the JDK. Cf. <https://www.youtube.com/watch?v=x7pkWlost64>.

Yeah, I don't see why in itself that would be a pertinent reason to
remove JavaFX from the JDK, either. That's clearly a spin. It's a fair
bet that going forward, Oracle is going to focus on where they make
their biggest returns with Java, namely server and associated web-y
techs, and focus less, and eventually not at all, on the desktop.

But to conclude from that that JavaFX itself is going to disappear, or
that desktop GUIs altogether are a thing of the past, is going too far.
Browser-based apps are not a panacea. They offer a huge advantage in
that they strongly impose MVC separations, which overall improves
applications' flexibility and potential reach -- especially as can be
more agnostic regarding where and over which transports they run, which
has been a consistent development in recent years. But they also have
inherent drawbacks -- overhead, third-party dependence and security come
to mind. To illustrate, if you use a desktop app for your online
banking, you have to trust your OS and your bank. If you use a
browser-based app, you have to trust your OS, your bank /and/ the
browser (recent developments have shown that one has to include the
hardware manufacturer in that list). I for one wouldn't be surprised if,
once the current trends have run their course and imposed more stringent
standards of application structuring, there'd eventually be some extent
of a move away from the browser.

You mention elsewhere in the thread that M$ is moving away from desktop
apps. Well, yeah, they've moved away from making apps _themselves_. Good
thing too; M$ is an OS manufacturer. They've only ever made apps in
order to sell their OS -- whether they realised it or not. At the same
time, as part of making their OS, they've invested lots of efforts into
enabling /others/ to make desktop apps for their desktop OS. And they've
been very successful at it: creating desktop apps for Windoze was and is
easy and accessible to everyone. That's more than can be said of Apple,
for instance.

Lastly, I believe there's some extent of professional bias at play here.
As Java devs, we might be led to believe that all app development is on
the 'net, because that's the jobs we get offered. I wonder whether for
instance a Python dev might have a radically different take on the matter.

-- 
DF.

[toc] | [prev] | [next] | [standalone]

#38143

On 10-03-18 09:50, Daniele Futtorovic wrote:
> On 2018-03-10 03:07, Silvio wrote:
>>> JavaFX runtime being removed from JRE - has that been
>>> stated anywhere?
>>>
>> Nowhere, other than JDK has always been a superset of JRE.
> 
> That's like saying the Java developers are a superset of the Java users.
> A tenuous proposition.
> 
>> Why on earth would they drop it from the JDK and leave it in the JRE?
> 
> Allegedly, because they're moving to a more structured release schedule
> for the JDK. Cf. <https://www.youtube.com/watch?v=x7pkWlost64>.
> 
> Yeah, I don't see why in itself that would be a pertinent reason to
> remove JavaFX from the JDK, either. That's clearly a spin. It's a fair
> bet that going forward, Oracle is going to focus on where they make
> their biggest returns with Java, namely server and associated web-y
> techs, and focus less, and eventually not at all, on the desktop.
> 
> But to conclude from that that JavaFX itself is going to disappear, or
> that desktop GUIs altogether are a thing of the past, is going too far.
> Browser-based apps are not a panacea. They offer a huge advantage in
> that they strongly impose MVC separations, which overall improves
> applications' flexibility and potential reach -- especially as can be
> more agnostic regarding where and over which transports they run, which
> has been a consistent development in recent years. But they also have
> inherent drawbacks -- overhead, third-party dependence and security come
> to mind. To illustrate, if you use a desktop app for your online
> banking, you have to trust your OS and your bank. If you use a
> browser-based app, you have to trust your OS, your bank /and/ the
> browser (recent developments have shown that one has to include the
> hardware manufacturer in that list). I for one wouldn't be surprised if,
> once the current trends have run their course and imposed more stringent
> standards of application structuring, there'd eventually be some extent
> of a move away from the browser.
> 
> You mention elsewhere in the thread that M$ is moving away from desktop
> apps. Well, yeah, they've moved away from making apps _themselves_. Good
> thing too; M$ is an OS manufacturer. They've only ever made apps in
> order to sell their OS -- whether they realised it or not. At the same
> time, as part of making their OS, they've invested lots of efforts into
> enabling /others/ to make desktop apps for their desktop OS. And they've
> been very successful at it: creating desktop apps for Windoze was and is
> easy and accessible to everyone. That's more than can be said of Apple,
> for instance.
> 
> Lastly, I believe there's some extent of professional bias at play here.
> As Java devs, we might be led to believe that all app development is on
> the 'net, because that's the jobs we get offered. I wonder whether for
> instance a Python dev might have a radically different take on the matter.
> 

I agree with a lot of what you say. It is not all black and white. But 
the advantage for web based clients I see is not from the perspective of 
a developer. Distribution and installation of apps is a major pain. 
Release cycles become shorter and shorter and upgrading installed 
software is an even bigger pain. I have apps on my phone that are 
upgraded more often than I use them. This all goes away with web 
applications. Zero install/upgrade and a more consistent client 
experience are user advantages. Let's not even start about DLL hell, 
registry creep, viruses etc.

[toc] | [prev] | [next] | [standalone]

#38146

On 3/10/2018 10:39 AM, Silvio wrote:
> I agree with a lot of what you say. It is not all black and white. But 
> the advantage for web based clients I see is not from the perspective of 
> a developer. Distribution and installation of apps is a major pain. 
> Release cycles become shorter and shorter and upgrading installed 
> software is an even bigger pain. I have apps on my phone that are 
> upgraded more often than I use them. This all goes away with web 
> applications. Zero install/upgrade and a more consistent client 
> experience are user advantages. Let's not even start about DLL hell, 
> registry creep, viruses etc.

Deployment is a big advantage of web application and a major reason
why they are so popular.

A problem that has been attempted solved for fat client applications
via "app stores" and sand-boxing models. With success for phones and
tablets. Without success for desktop computers.

Arne

[toc] | [prev] | [next] | [standalone]

#38154

On Saturday, March 10, 2018 at 9:06:54 PM UTC-5, Arne Vajhøj wrote:
> 
> Deployment is a big advantage of web application and a major reason
> why they are so popular.
> 
> A problem that has been attempted solved for fat client applications
> via "app stores" and sand-boxing models. With success for phones and
> tablets. Without success for desktop computers.
> 
> Arne

Web "deployment" is relatively simple.  If you can write code that will run in any browser, it will run on any device, a PC, a Mac, an Android tablet or phone, an iOS tablet or phone, or a Linux machine (though I think the percentage of users running Linux as the client is relatively small).  They should already have a web browser and should not have to install anything.  Probably the most annoying part of coding is adjusting the look for various screen sizes.

Java deployment over the web using webstart is almost as simple, and cleaner because you don't have to worry about a browser window and should get a consistent look and feel, but it does require a JRE install and only works on Windows, Mac OS, or Linux.

App store deployment is cleaner for mobile as again you're running standalone, not inside some browser window.  It does require an install, and does allow you to prompt for permission to do things you can't do in a browser.  This was tedious trying to code in Android then re-code for iOS but there are IDEs that can translate for you now.  Banks are advertising on tv they have apps now to click a button to freeze a credit card.  I don't know if you'd need to run these programs on desktop or how easily they translate to Windows Store (Apple Store for Mac OS?).

I currently run a hybrid app, with the new part of the application running in Swing GUI, and the old part running the old style character window (some old timers still prefer the character windows).  I've spent at least 10 years rewriting it in Swing myself, with a second programmer on the job I've had to train (each one helps for a couple years before the good ones move on for more money), so I'm not quick to jump on a rewrite to web code for an in-house application.  We got some Surface Pro tablets to run it mobile within the building, as there aren't many tablets running Windows Pro and we need the domain login.  We are concerned with security risks making the ERP application run outside the building.

[toc] | [prev] | [next] | [standalone]

#38155

On 12-Mar-18 9:50 PM, Eric Douglas wrote:
> On Saturday, March 10, 2018 at 9:06:54 PM UTC-5, Arne Vajhøj wrote:
>> 
>> Deployment is a big advantage of web application and a major
>> reason why they are so popular.
>> 
>> A problem that has been attempted solved for fat client
>> applications via "app stores" and sand-boxing models. With success
>> for phones and tablets. Without success for desktop computers.
>> 
>> Arne
> 
> Web "deployment" is relatively simple.  If you can write code that
> will run in any browser, it will run on any device, a PC, a Mac, an
> Android tablet or phone, an iOS tablet or phone, or a Linux machine
> (though I think the percentage of users running Linux as the client
> is relatively small).  They should already have a web browser and
> should not have to install anything.  Probably the most annoying part
> of coding is adjusting the look for various screen sizes.

IMHO Only for tiny devices such as watches. Linear scalability for 
phones/tablets, and desktops works. God bless CSS display: flex; et al.

> 
> Java deployment over the web using webstart is almost as simple, and
> cleaner because you don't have to worry about a browser window and
> should get a consistent look and feel, 

Please educate yourself about the the display property in Web App 
manifests.

> but it does require a JRE
> install and only works on Windows, Mac OS, or Linux.

Who is installing a JRE on their client these days??? That Oracle 
Dickhead who made Applets so difficult to activate should be shot!

> 
> App store deployment is cleaner for mobile as again you're running
> standalone, not inside some browser window.  It does require an
> install, and does allow you to prompt for permission to do things you
> can't do in a browser.  

I like that simple permissions model but, quite rightly, some point out 
that asking for all permissions up from without any context as to what 
they will be used for leads the user to make an uninformed decision as 
useless as "Do you agree to the Ts and Cs?".

For better or worse the Web has opted for only asking for Geolocation 
access when it is needed or only asking for microphone access after the 
user has clicked a button for record.

I'm not suffering from conviction either way.

BTW There's not much left that you "can't do in a browser". Background 
Geolocation a notable exception due to a whole cabal of reasons. Cheif 
among them Jerk bloody Archibald.

[toc] | [prev] | [next] | [standalone]

#38156

On Monday, March 12, 2018 at 11:41:11 AM UTC-4, Richard Maher wrote:
> > 
> > Web "deployment" is relatively simple.  If you can write code that
> > will run in any browser, it will run on any device, a PC, a Mac, an
> > Android tablet or phone, an iOS tablet or phone, or a Linux machine
> > (though I think the percentage of users running Linux as the client
> > is relatively small).  They should already have a web browser and
> > should not have to install anything.  Probably the most annoying part
> > of coding is adjusting the look for various screen sizes.
> 
> IMHO Only for tiny devices such as watches. Linear scalability for 
> phones/tablets, and desktops works. God bless CSS display: flex; et al.
> 
You do have to write different code to allow different screen sizes.
For instance pull up www.philadelphiaeagles.com.  If I open this in my desktop browser it does look horrible if I shrink my window too small.  If  I open this in my iPhone it is a completely different site. (it redirects from www. to m.)  My company's web site was horrible on mobile for a long time.  They've outsourced that to a company that is rewriting it so the mobile looks better now, just loads slow as I believe the image file sizes are too big.

> > 
> > Java deployment over the web using webstart is almost as simple, and
> > cleaner because you don't have to worry about a browser window and
> > should get a consistent look and feel, 
> 
> Please educate yourself about the the display property in Web App 
> manifests.
> 
I don't know about that, or where I could find a good example of a web app site, just that any site I view in the browser (ie safari on my phone) still has the URL bar at the top and navigation buttons at the bottom.

> > but it does require a JRE
> > install and only works on Windows, Mac OS, or Linux.
> 
> Who is installing a JRE on their client these days??? That Oracle 
> Dickhead who made Applets so difficult to activate should be shot!
> 
Applets are dead, we're talking webstart.

> > 
> > App store deployment is cleaner for mobile as again you're running
> > standalone, not inside some browser window.  It does require an
> > install, and does allow you to prompt for permission to do things you
> > can't do in a browser.  
> 
> I like that simple permissions model but, quite rightly, some point out 
> that asking for all permissions up from without any context as to what 
> they will be used for leads the user to make an uninformed decision as 
> useless as "Do you agree to the Ts and Cs?".
> 
> For better or worse the Web has opted for only asking for Geolocation 
> access when it is needed or only asking for microphone access after the 
> user has clicked a button for record.
> 
> I'm not suffering from conviction either way.
> 
> BTW There's not much left that you "can't do in a browser". Background 
> Geolocation a notable exception due to a whole cabal of reasons. Cheif 
> among them Jerk bloody Archibald.

There have been some apps overusing the prompt, requesting permission to do things like access the camera they shouldn't need to do.  Agreed it's probably a better model if it can ask permissions in the middle of an app if you click the 'snap a photo' button then it asks do you want to give this app permission to the camera and it gives you the 3 choices 1) yes right now, 2) no, or 3) yes and never ask again for this app.
I know one thing I've heard doesn't work well in web code is accessing the client file system.

[toc] | [prev] | [next] | [standalone]

#38158

On 13-Mar-18 12:10 AM, Eric Douglas wrote:
> On Monday, March 12, 2018 at 11:41:11 AM UTC-4, Richard Maher wrote:
>>> 
>>> Web "deployment" is relatively simple.  If you can write code
>>> that will run in any browser, it will run on any device, a PC, a
>>> Mac, an Android tablet or phone, an iOS tablet or phone, or a
>>> Linux machine (though I think the percentage of users running
>>> Linux as the client is relatively small).  They should already
>>> have a web browser and should not have to install anything.
>>> Probably the most annoying part of coding is adjusting the look
>>> for various screen sizes.
>> 
>> IMHO Only for tiny devices such as watches. Linear scalability for 
>> phones/tablets, and desktops works. God bless CSS display: flex; et
>> al.
>> 
> You do have to write different code to allow different screen sizes.

Bollocks! No you don't! OK your CSS will have some: -

	
	@media only screen
	and (min-device-width : 320px)
	and (max-device-width : 480px) {
		body {
			font-size: 8px;
		}
		div.wrapper
		{
			font-size: 8px;
		}		
		div.polo
		{
			font-size: 8px;
		}		
		div.textHolder
		{
			font-size: 16px;
		}
		div#alarm
		{
			font-size: 8px;
		}
		div#radar
		{
			font-size: 8px;
		}
		div#speaker
		{
			font-size: 8px;
		}
	}

Size everything else with EMs.

And your header may have some of these: -

	<link rel="apple-touch-startup-image"
		  media="(device-width: 320px)"
		  href="icon1-320x460.png">

But different layout for mobile/tablet/desktop is only one option not a
requirement.


> For instance pull up www.philadelphiaeagles.com.  If I open this in
> my desktop browser it does look horrible if I shrink my window too
> small.  If  I open this in my iPhone it is a completely different
> site. (it redirects from www. to m.)  My company's web site was
> horrible on mobile for a long time.  They've outsourced that to a
> company that is rewriting it so the mobile looks better now, just
> loads slow as I believe the image file sizes are too big.

Again, especially with new larger mobiles, scaling of well designed GUIs 
works great.

> 
>>> 
>>> Java deployment over the web using webstart is almost as simple,
>>> and cleaner because you don't have to worry about a browser
>>> window and should get a consistent look and feel,
>> 
>> Please educate yourself about the the display property in Web App 
>> manifests.
>> 
> I don't know about that, or where I could find a good example of a
> web app site, just that any site I view in the browser (ie safari on
> my phone) still has the URL bar at the top and navigation buttons at
> the bottom.

That is because you are happy to wallow in your ignorance. First thing 
off the web: -
https://deanhume.com/home/blogpost/5-awesome-progressive-web-apps-worth-exploring/10153

> 
>>> but it does require a JRE install and only works on Windows, Mac
>>> OS, or Linux.
>> 
>> Who is installing a JRE on their client these days??? That Oracle 
>> Dickhead who made Applets so difficult to activate should be shot!
>> 
> Applets are dead, we're talking webstart.

Webstart is also dead.

> 
>>> 
>>> App store deployment is cleaner for mobile as again you're
>>> running standalone, not inside some browser window.  It does
>>> require an install, and does allow you to prompt for permission
>>> to do things you can't do in a browser.
>> 
>> I like that simple permissions model but, quite rightly, some point
>> out that asking for all permissions up from without any context as
>> to what they will be used for leads the user to make an uninformed
>> decision as useless as "Do you agree to the Ts and Cs?".
>> 
>> For better or worse the Web has opted for only asking for
>> Geolocation access when it is needed or only asking for microphone
>> access after the user has clicked a button for record.
>> 
>> I'm not suffering from conviction either way.
>> 
>> BTW There's not much left that you "can't do in a browser".
>> Background Geolocation a notable exception due to a whole cabal of
>> reasons. Cheif among them Jerk bloody Archibald.
> 
> There have been some apps overusing the prompt, requesting permission
> to do things like access the camera they shouldn't need to do.
> Agreed it's probably a better model if it can ask permissions in the
> middle of an app if you click the 'snap a photo' button then it asks
> do you want to give this app permission to the camera and it gives
> you the 3 choices 1) yes right now, 2) no, or 3) yes and never ask
> again for this app. I know one thing I've heard doesn't work well in
> web code is accessing the client file system.

Possibly, I've never done it.
> 

[toc] | [prev] | [next] | [standalone]

#38162

On 3/12/2018 12:10 PM, Eric Douglas wrote:
> On Monday, March 12, 2018 at 11:41:11 AM UTC-4, Richard Maher wrote:
>>> but it does require a JRE
>>> install and only works on Windows, Mac OS, or Linux.
>>
>> Who is installing a JRE on their client these days??? That Oracle
>> Dickhead who made Applets so difficult to activate should be shot!
>>
> Applets are dead, we're talking webstart.

Well -according to the announcement that triggered this thread, then
Java Web Start is dead as well.

<quote>
Consequently:
* Oracle will extend support for Web Start in Java SE 8 from March, 
2019, through at least March 2025.
* Oracle products that have dependencies on Web Start will remain on 
Java SE 8 and continue with the support timelines as indicated by those 
products.
* Oracle will not include Java Web Start in Java SE 11 (18.9 LTS) and later.
* Oracle will begin encouraging application developers and users to 
transition away from Java Web Start and encourage non-commercial 
consumers to remove any unused or non-supported Oracle JRE installations 
from their desktops.
* Developers who deploy desktop applications to individual consumers 
(eg, games, personal banking, or other B2C applications) will need to 
transition to other deployment technologies such as the jlink and/or 
third party packaging and deployment solutions before the end of 2020.
* Application developers who target applications for internal data 
processing, business, commercial, or production purposes, will either 
need to seek commercial license with Oracle, or transition to other 
deployment technologies by January 2019.
</quote>

Arne

[toc] | [prev] | [next] | [standalone]

#38169

On Monday, March 12, 2018 at 8:15:14 PM UTC-4, Arne Vajhøj wrote:
> On 3/12/2018 12:10 PM, Eric Douglas wrote:
> > On Monday, March 12, 2018 at 11:41:11 AM UTC-4, Richard Maher wrote:
> >>> but it does require a JRE
> >>> install and only works on Windows, Mac OS, or Linux.
> >>
> >> Who is installing a JRE on their client these days??? That Oracle
> >> Dickhead who made Applets so difficult to activate should be shot!
> >>
> > Applets are dead, we're talking webstart.
> 
> Well -according to the announcement that triggered this thread, then
> Java Web Start is dead as well.
> 
> <quote>
> Consequently:
> * Oracle will extend support for Web Start in Java SE 8 from March, 
> 2019, through at least March 2025.
> * Oracle products that have dependencies on Web Start will remain on 
> Java SE 8 and continue with the support timelines as indicated by those 
> products.
> * Oracle will not include Java Web Start in Java SE 11 (18.9 LTS) and later.
> * Oracle will begin encouraging application developers and users to 
> transition away from Java Web Start and encourage non-commercial 
> consumers to remove any unused or non-supported Oracle JRE installations 
> from their desktops.
> * Developers who deploy desktop applications to individual consumers 
> (eg, games, personal banking, or other B2C applications) will need to 
> transition to other deployment technologies such as the jlink and/or 
> third party packaging and deployment solutions before the end of 2020.
> * Application developers who target applications for internal data 
> processing, business, commercial, or production purposes, will either 
> need to seek commercial license with Oracle, or transition to other 
> deployment technologies by January 2019.
> </quote>
> 
> Arne

Webstart just makes sense.  They just click a link to a JNLP which downloads the jars they need for the client side classes and starts the client JVM.  We then create a client-server application from this by opening a socket connection to a server running JVM.

This change doesn't make sense, though so far I'm not making sense of Java 9.  I tried to compile my project in 9 and it complained I had multiple dependencies with the same class names, in different packages.  These are in 3rd party jars so I don't know how to fix that.  Is there a new technology that does what webstart does?  I'm not clear what they're saying about jlink.

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web