JavaFX disappearing in Java 11

[Chris Riesbeck]

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

[Arne Vajhøj]

On 3/8/2018 2:10 PM, Chris Riesbeck wrote:
> https://www.infoworld.com/article/3261066/java/javafx-will-be-removed-from-the-java-jdk.html

Interesting.

Note though that JavaFX is/was not part of Java - it is/was part of
Oracle Java. Subtle difference.

I hope that JavaFX will stay around.

Arne

[Eric Douglas]

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.

[Arne Vajhøj]

"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

[Eric Douglas]

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.

[Arne Vajhøj]

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

[Daniele Futtorovic]

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.

[Arne Vajhøj]

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

[Arne Vajhøj]

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

[Arne Vajhøj]

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

[Richard Maher]

You're dreamin'

The browser *is* the GUI. Resistance is futile.

As with .NET C#, Java is consigned to server based mvC (capitalization
deliberate) serving up RESTful JSON APIs.

>
> Arne
>

[Arne Vajhøj]

That is the most common model on desktop.

(phones and tablets are slightly different)

I am not dreaming that Java is going to get a comeback
on the desktop.

But one size does not fit all.

Most common != all.

For those that for whatever reasons want a desktop application
and want to write it in Java, then JavaFX is better than Swing
and AWT.

Arne

[Richard Maher]

On 09-Mar-18 8:37 AM, Arne Vajhøj wrote:
> On 3/8/2018 7:30 PM, Richard Maher wrote:
>> On 09-Mar-18 3:15 AM, Arne Vajhøj wrote:
>>> On 3/8/2018 2:10 PM, Chris Riesbeck wrote:
>>>> https://www.infoworld.com/article/3261066/java/javafx-will-be-removed-from-the-java-jdk.html
>>
>> >
>>> Interesting.
>>>
>>> Note though that JavaFX is/was not part of Java - it is/was part of
>>> Oracle Java. Subtle difference.
>>>
>>> I hope that JavaFX will stay around.
>>
>> You're dreamin'
>>
>> The browser *is* the GUI. Resistance is futile.
>>
>> As with .NET C#, Java is consigned to server based mvC (capitalization
>> deliberate) serving up RESTful JSON APIs.
>
> That is the most common model on desktop.
>
> (phones and tablets are slightly different)

Legacy phone and tablet Apps have traditionally been slightly different.

>
> I am not dreaming that Java is going to get a comeback
> on the desktop.

Java *is* the new COBOL.

>
> But one size does not fit all.
>
> Most common != all.
>
> For those that for whatever reasons want a desktop application
> and want to write it in Java, then JavaFX is better than Swing
> and AWT.

Sure, Java will always have a part to pay in mainstream Slot-machines,
ticketing machines, and other esoteric niches.

>
> Arne
>

[Martin Gregorie]

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

[Eric Douglas]

On Thursday, March 8, 2018 at 7:37:15 PM UTC-5, Arne Vajhøj wrote:
> > The browser *is* the GUI. Resistance is futile.
> >
> > As with .NET C#, Java is consigned to server based mvC (capitalization
> > deliberate) serving up RESTful JSON APIs.
>
> That is the most common model on desktop.
>
> (phones and tablets are slightly different)
>
> I am not dreaming that Java is going to get a comeback
> on the desktop.
>
> But one size does not fit all.
>
> Most common != all.
>
> For those that for whatever reasons want a desktop application
> and want to write it in Java, then JavaFX is better than Swing
> and AWT.
>
> Arne

I feel like I need to migrate code to a client server model with the client interface involving web browsers, but I have spent 10 years developing a nice Java Swing API and I'm skeptical the web browser model can do everything my API can do, much less do it efficiently and consistently.

I haven't really gotten into much web coding myself but I think they have gotten better with consistency in recent years. I know 10 years ago no one wanted a web based client because nothing looked much less worked the same across different browsers. These says some are still doing the Java Swing socket model or C# application with remote users logging into VPN but many have adapted browser interfaces.

[Silvio]

Even ten years ago most applications where better of with a web based
client. Since then the browser has become a better and more converged
client and user interface design has changed drastically in a direction
that suits the browser.

I did my last non browser client (Swing) about 14 years ago and native
client (Windows/C++) 20 years ago. Never looked back.

Ten years ago I could not believe anybody was interested in JavaFX. For
new applications, the non-browser GUI was already dead and the plugins
(Flash and Silverlight) where on their way out. I am stumped people are
still developing Swing clients.

[Silvio]

It's going out. JDK and JRE.

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

[Arne Vajhøj]

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

[Arne Vajhøj]

On 3/9/2018 8:19 AM, Eric Douglas wrote:
> On Thursday, March 8, 2018 at 7:37:15 PM UTC-5, Arne Vajhøj wrote:
>>> The browser *is* the GUI. Resistance is futile.
>>>
>>> As with .NET C#, Java is consigned to server based mvC (capitalization
>>> deliberate) serving up RESTful JSON APIs.
>>
>> That is the most common model on desktop.
>>
>> (phones and tablets are slightly different)
>>
>> I am not dreaming that Java is going to get a comeback
>> on the desktop.
>>
>> But one size does not fit all.
>>
>> Most common != all.
>>
>> For those that for whatever reasons want a desktop application
>> and want to write it in Java, then JavaFX is better than Swing
>> and AWT.
>

> I feel like I need to migrate code to a client server model with the
> client interface involving web browsers, but I have spent 10 years
> developing a nice Java Swing API and I'm skeptical the web browser model
> can do everything my API can do, much less do it efficiently and
> consistently.
>
> I haven't really gotten into much web coding myself but I think they
> have gotten better with consistency in recent years. I know 10 years ago
> no one wanted a web based client because nothing looked much less worked
> the same across different browsers. These says some are still doing the
> Java Swing socket model or C# application with remote users logging into
> VPN but many have adapted browser interfaces.

Most things can be made work as web UI.

But only you knows about your specific GUI.

Arne

[Arne Vajhøj]

On 3/9/2018 6:02 PM, Silvio wrote:
> Ten years ago I could not believe anybody was interested in JavaFX. For
> new applications, the non-browser GUI was already dead and the plugins
> (Flash and Silverlight) where on their way out. I am stumped people are
> still developing Swing clients.

Well - MS is still selling desktop applications for many B$ a year.

And Android and iOS got about 5 million new apps the last 10 years.

A desktop application is getting a rare choice for frontend
for the typical business application.

But declaring anything non-browser dead 10 years ago seem
a bit exaggerated.

Arne

[Silvio]

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.

[Silvio]

Mobile apps are the special case here for now. Since the browser/native
gap is closing fast there as well the same will happen on mobile as on
the desktop.

M$ did not exactly create a lot of new stuff on the desktop did they?
They did some half-hearted attempt at a couple of metro apps and
basically abandoned them. And then they ported the whole Office suite to
the web.

[Arne Vajhøj]

On 3/9/2018 9:12 PM, Silvio wrote:
> On 10-03-18 01:28, Arne Vajhøj wrote:
>> On 3/9/2018 6:02 PM, Silvio wrote:
>>> Ten years ago I could not believe anybody was interested in JavaFX.
>>> For new applications, the non-browser GUI was already dead and the
>>> plugins (Flash and Silverlight) where on their way out. I am stumped
>>> people are still developing Swing clients.
>>
>> Well - MS is still selling desktop applications for many B$ a year.
>>
>> And Android and iOS got about 5 million new apps the last 10 years.
>>
>> A desktop application is getting a rare choice for frontend
>> for the typical business application.
>>
>> But declaring anything non-browser dead 10 years ago seem
>> a bit exaggerated.
>

> Mobile apps are the special case here for now.

It is a special case. But a rather big special case.

> Since the browser/native
> gap is closing fast there as well the same will happen on mobile as on
> the desktop.

Maybe. But so far it has not happened.

> M$ did not exactly create a lot of new stuff on the desktop did they?
> They did some half-hearted attempt at a couple of metro apps and
> basically abandoned them. And then they ported the whole Office suite to
> the web.

MSO is availble in the 365 thing.

But they still make a lot of money on the traditional desktop applications.

Arne

[Arne Vajhøj]

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

[Daniele Futtorovic]

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.

[Richard Maher]

On 10-Mar-18 10:28 AM, Arne Vajhøj wrote:
> On 3/9/2018 9:12 PM, Silvio wrote:
>> On 10-03-18 01:28, Arne Vajhøj wrote:
>>> On 3/9/2018 6:02 PM, Silvio wrote:
>>>> Ten years ago I could not believe anybody was interested in JavaFX.
>>>> For new applications, the non-browser GUI was already dead and the
>>>> plugins (Flash and Silverlight) where on their way out. I am stumped
>>>> people are still developing Swing clients.
>>>
>>> Well - MS is still selling desktop applications for many B$ a year.
>>>
>>> And Android and iOS got about 5 million new apps the last 10 years.
>>>
>>> A desktop application is getting a rare choice for frontend
>>> for the typical business application.
>>>
>>> But declaring anything non-browser dead 10 years ago seem
>>> a bit exaggerated.
>>
>> Mobile apps are the special case here for now.
>
> It is a special case. But a rather big special case.
>
>>                                                Since the
>> browser/native gap is closing fast there as well the same will happen
>> on mobile as on the desktop.
>
> Maybe. But so far it has not happened.

Phonegap/Cordova would disappear overnight if W3C wasn't stacked full of
incompetent lefty social warriors who get their jobs because their
companies contribute financially or are members.

They have NO deliverables, NO KPIs, and can't tell their development
arse from their elbow :-(

For 2 years they've had the solution to Background Geolocation and still
nothing. Arrrgh!

https://github.com/w3c/ServiceWorker/issues/745

[Silvio]

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.

[Ricardo Palomares Martinez]

El 09/03/18 a las 01:30, Richard Maher escribió:

> On 09-Mar-18 3:15 AM, Arne Vajhøj wrote:
>> On 3/8/2018 2:10 PM, Chris Riesbeck wrote:
>>> https://www.infoworld.com/article/3261066/java/javafx-will-be-removed-from-the-java-jdk.html
>>
>>
>>
>> Interesting.
>>
>> Note though that JavaFX is/was not part of Java - it is/was part of
>> Oracle Java. Subtle difference.
>>
>> I hope that JavaFX will stay around.
>
> You're dreamin'
>
> The browser *is* the GUI. Resistance is futile.

Browser will *never* be my GUI. It is a GUI inside of a GUI, and that
does not work for anyone using extensively keyboard shortcuts like me.
It is a perfect solution for short interactions like online banking
(I'd never install a mobile app for online banking instead using a
browser), but with the only, partial, exception of Google Docs (which
do not use actual browser controls for the most part), I yet have to
find a web application that I find as usable as a desktop application.

[Arne Vajhøj]

On 3/10/2018 3:50 AM, Daniele Futtorovic wrote:
> 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.

MS is still doing desktop applications. And selling for billions of dollars.

> 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 think Python would be the about the same as Java.

Django, Plone, Zope etc..

Arne

[Arne Vajhøj]

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

[Arne Vajhøj]

On 3/10/2018 8:41 AM, Richard Maher wrote:
> On 10-Mar-18 10:28 AM, Arne Vajhøj wrote:
>> On 3/9/2018 9:12 PM, Silvio wrote:
>>>                                                Since the
>>> browser/native gap is closing fast there as well the same will happen
>>> on mobile as on the desktop.
>>
>> Maybe. But so far it has not happened.
>
> Phonegap/Cordova would disappear overnight if W3C wasn't stacked full of
> incompetent lefty social warriors who get their jobs because their
> companies contribute financially or are members.

Are you saying that you don't like them>

:-)

Phone and tablet are more than PhoneGap/Cordova and similar HTML 5 based
toolkits.

Objective-C or Swift on iPhone.

Java on Android.

C# on both via Xamarin.

Arne

[Richard Maher]

HTLM5, CSS3, Javascript *everywhere*

>
> Arne

[Richard Maher]

Please try to keep up with the technology. Specifically Web Apps and
ServiceWorkers. You might like your command line interface on your CRT
but that is hardly the point.

[Arne Vajhøj]

Yes.

And if it work for you and you like it then it is great.

Not everybody likes it.

Arne

[Gianluca Bonetti]

Il giorno giovedì 8 marzo 2018 20:10:57 UTC+1, Chris Riesbeck ha scritto:
> 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

Hi

There is still OpenJFX
https://wiki.openjdk.java.net/display/OpenJFX/Main

Bye
gl

[Eric Douglas]

On Saturday, March 10, 2018 at 9:03:56 PM UTC-5, Arne Vajhøj wrote:
> MS is still doing desktop applications. And selling for billions of dollars.
>

I don't know how many desktop applications MS makes these days. I know there's Office 365 which I picture as a web app but does have the option to install as a desktop app, I normally just use Google Docs. I know they use the Windows Store, as Halo Wars is a Windows Store install. I don't know what language they're in but MS has a few games they develop for desktop as well as their xbox.

[Eric Douglas]

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.

[Richard Maher]

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.

[Eric Douglas]

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.

[Gene Wirchenko]

On Sun, 11 Mar 2018 10:49:41 +0800, Richard Maher
<maher_rj...@hotmail.com> wrote:

>On 11-Mar-18 2:20 AM, Ricardo Palomares Martinez wrote:
>> El 09/03/18 a las 01:30, Richard Maher escribió:

[snip]

>>> The browser *is* the GUI. Resistance is futile.

No,it is not.

>> Browser will *never* be my GUI. It is a GUI inside of a GUI, and that
>> does not work for anyone using extensively keyboard shortcuts like me.
>> It is a perfect solution for short interactions like online banking
>> (I'd never install a mobile app for online banking instead using a
>> browser), but with the only, partial, exception of Google Docs (which
>> do not use actual browser controls for the most part), I yet have to
>> find a web application that I find as usable as a desktop application.
>>
>
>Please try to keep up with the technology. Specifically Web Apps and
>ServiceWorkers. You might like your command line interface on your CRT
>but that is hardly the point.

Maybe, the technology should be more workable.

I was at a job fair last week, and at one company's booth, I had
to enter my information using a touch screen. It was very slow. A
desktop system has a keyboard that just works. Bad interfaces are
very bad. They waste a lot of time, but one sure is busy!

Mr. Polamares did not mention CLIs. Just one level of GUI is
quite enough. It is a toss-up as to whether a GUI is better than a
CLI; it depends on the area, and it depends on QOI.

Sincerely,

Gene Wirchenko

[Richard Maher]

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.
>

[Daniele Futtorovic]

On 2018-03-11 03:06, Arne Vajhøj wrote:
> 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.

I don't think you can directly compare the situations on the mobile and
on the desktop, respectively. Given how limited access the user has to
them, for practical intents and purposes, mobiles are more akin to thin
clients. And sure, for those, webapps certainly make a lot of sense (the
brower then essentially being a virtualization client).

>> 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.

Have you guys ever heard of Steam (tm)?

--
DF.

[Arne Vajhøj]

True - that is a success.

But certainly a very specific market.

Arne

[Arne Vajhøj]

On 3/12/2018 8:45 AM, Eric Douglas wrote:
> On Saturday, March 10, 2018 at 9:03:56 PM UTC-5, Arne Vajhøj wrote:
>> MS is still doing desktop applications. And selling for billions of dollars.
>
> I don't know how many desktop applications MS makes these days. I
> know there's Office 365 which I picture as a web app but does have
> the option to install as a desktop app, I normally just use Google
> Docs.

MS Office is still very much alive. Latest version is 2016. Both
Windows and Mac.

Arne

[Arne Vajhøj]

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

[Arne Vajhøj]

On 3/11/2018 12:59 PM, Gianluca Bonetti wrote:
> Il giorno giovedì 8 marzo 2018 20:10:57 UTC+1, Chris Riesbeck ha scritto:
>> 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
>

> There is still OpenJFX
> https://wiki.openjdk.java.net/display/OpenJFX/Main

From the announcement:

<quote>
Oracle fully open sourced JavaFX through “OpenJFX” in 2011, and
continues to contribute to its open-source development.

...

Consequently:
* Oracle will continue to support JavaFX new fixes for Java SE 8 until 2022.
* Having open sourced JavaFX and related tools, Oracle is working with
interested third parties to make it easier to build and maintain JavaFX
as a separately distributable open-source module.
<quote>

Arne

[Silvio]

On 12-03-18 17:10, 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.
> 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.
>

You always have to accommodate for different screen sizes if an
application may be used on different types of devices or if you want to
allow users to work with smaller windows sizes (remember cascade/tile?).

Making a responsive HTML+CSS client using ems and a tine set of media
queries makes that infinitely simpler than any other technique I have
ever used. Pixel based windows layouts where very hard to behave like
what we would now call responsive (I have done it for about ten years).
Using Swing layouts was even worse (remember GirdBagLayout? That sucked
big time).

Our web applications come with CSS templates and a "Style design" GUI
that let's users configure their own fonts, colors, backgrounds, widths,
margins etc. for various user interface elements into named "themes".
They can then apply those to various end user interfaces like
questionnaires, dashboards (with SVG graphics) and application interfaces.
The responsive CSS core takes care of everything. This is almost
impossible to do using any other GUI mechanism. Hell, even Linux
desktops are styled with CSS nowadays. If only there was some HTML in
there we could really build a gorgeous desktop.

>>>
>>> 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.
>

You must be looking at some very poorly designed websites. There are
plenty of them around.

>>> 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 just as dead. At least Applets had their use once. Webstart
was a horrible idea to start with and never took off.

>>>
>>> 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.
>

You describe how accessing features like Geolocation works in browsers.

Accessing user file systems is very much overdone in business
applications. In the end people resort to using shared network locations
to be able to collaborate (which is then poorly supported by the same
applications).
Proper up/download can be implemented very conveniently in a browser.
Sharing resources like documents and media files can be supported much
easier and infinitely more secure.

In some areas desktop applications have actual advantages. But these
advantages are decreasing and web applications are closing in. Web
applications have huge advantages in many other areas. Desktop
applications can only partially keep up by using Citrix-like setups.

Part of the mobile app hausse is caused by nitwit decision makers who
believe the hype that every B2C company, web shop, television show or
pop concert needs it's own app. Doing that instead of a properly
designed web site is counter productive and sooner or later people will
start to realize that.

Google is already moving tablets away from Android and towards ChromeOS.
That is a good decision. Many mobile apps turn a tablet into a clumsy
big smartphone.

[Martin Gregorie]

On Tue, 13 Mar 2018 02:28:38 +0100, Silvio wrote:

> You always have to accommodate for different screen sizes if an
> application may be used on different types of devices or if you want to
> allow users to work with smaller windows sizes (remember cascade/tile?).
>

That is easy enough in Swing. Call JFrame.getToolkit() and use the toolkit
to find the screen size. Provided that your code expresses component
dimensions as %age of screen size then scaling a window layout becomes
automatic. I do this as a matter of course and my Java Apps work on a
variety of screens ranging from SVGA to 1600x900 without any fuss or
bother.

> Using Swing layouts was even worse (remember GirdBagLayout? That sucked
> big time).
>

GridBagLayout has *always* sucked IMO.

For the sort of layouts I generally use, i.e. paint a screen rather like
we used to do with one of the 4GLs (Sculptor, DBase, etc), I prefer
Riverlayout to any other layout manager I've tried. It was originated by
Datadosen and was at www.datadosen.se/riverlayout but that site is now
rearranged and the link is broken. I have source if you want it.

Or you could try MigLayout, http://www.miglayout.com/ - I haven't used
it but it gets quite a lot of nice mentions and its documentation looks
well thought out and clear.


--
Martin | martin at
Gregorie | gregorie dot org

[Arne Vajhøj]

On 3/13/2018 7:39 AM, Martin Gregorie wrote:
> For the sort of layouts I generally use, i.e. paint a screen rather like
> we used to do with one of the 4GLs (Sculptor, DBase, etc), I prefer
> Riverlayout to any other layout manager I've tried. It was originated by
> Datadosen and was at www.datadosen.se/riverlayout but that site is now
> rearranged and the link is broken. I have source if you want it.

It looks like it is on GitHub:

https://github.com/Deses/RiverLayout

Arne

[Eric Douglas]

On Tuesday, March 13, 2018 at 7:39:21 AM UTC-4, Martin Gregorie wrote:
> That is easy enough in Swing. Call JFrame.getToolkit() and use the toolkit
> to find the screen size. Provided that your code expresses component
> dimensions as %age of screen size then scaling a window layout becomes
> automatic. I do this as a matter of course and my Java Apps work on a
> variety of screens ranging from SVGA to 1600x900 without any fuss or
> bother.
>
> > Using Swing layouts was even worse (remember GirdBagLayout? That sucked
> > big time).
> >
> GridBagLayout has *always* sucked IMO.
>

I believe GridBagLayout is the one layout I have in a test class which looked like the most flexible one. For our application I use null layout and set all controls with fixed size and location with non-resizable windows, requiring a minimum resolution to run it. I find if we give users too much flexibility they just mess themselves up. When we used to use Office 2000 they had an Office toolbar docked to the top of the desktop. One user managed to run Word and undocked it's toolbar and dragged it under the Office toolbar and called IT to find it.

Keeping things simple and standard really helps. If we let users assign their own custom colors to controls they would mess themselves up, or get confused looking at someone else's screen, so we color controls and all colors are hard coded and meaningful. A red control has an error, a yellow control is a required field, a blue control has a special inquiry function.

[Martin Gregorie]

Thanks for that.

I tried a few searches, but they didn't appear to find it - only outdated
links to Datadosen and a mass of irrelevant artsy-craftsy hits.

[Eric Douglas]

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.

[Eric Douglas]

On Monday, March 12, 2018 at 8:15:14 PM UTC-4, Arne Vajhøj wrote:

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

Of course being declared "dead" doesn't mean it doesn't work.
Some things are dead because the dependency disappeared. Browsers are dropping support for Flash so it will soon be officially dead, unless you keep your users running an old browser. Browsers killed the applets but JNLP shouldn't require browsers to support it even over the internet, though we're only using it to run a client server app within the local network.
We still login to a government vendor portal using activeX.

[Arne Vajhøj]

On 3/13/2018 9:42 AM, Eric Douglas wrote:
> On Monday, March 12, 2018 at 8:15:14 PM UTC-4, Arne Vajhøj wrote:
>> Well -according to the announcement that triggered this thread, then
>> Java Web Start is dead as well.
>
> Of course being declared "dead" doesn't mean it doesn't work.

"Oracle will not include Java Web Start in Java SE 11 (18.9 LTS) and later."

Arne

[Arne Vajhøj]

On 3/13/2018 8:46 AM, Eric Douglas wrote:
> 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.

It is not urgent.

"Oracle will extend support for Web Start in Java SE 8 from March, 2019,
through at least March 2025."

> Is there a new technology that does what webstart does? I'm not clear
> what they're saying about jlink.

jlink is packing a custom install.

I don't see it as a direct replacement of JWS.

Arne

[Eric Douglas]

On Tuesday, March 13, 2018 at 9:50:52 AM UTC-4, Arne Vajhøj wrote:
> "Oracle will not include Java Web Start in Java SE 11 (18.9 LTS) and later."
>
> Arne

Not include means it's a separate download or there will be no existing version that works with 11? If the latter, than webstart users just can't allow Java newer than 10 (or 8?) until an equivalent alternative is available.

Again I'm not sure what that article was referring to, "will need to

transition to other deployment technologies such as the jlink and/or

third party packaging and deployment solutions" but if they're replacing javaws for some reason there should be some way to do what it does.

[Arne Vajhøj]

On 3/13/2018 9:57 AM, Eric Douglas wrote:
> On Tuesday, March 13, 2018 at 9:50:52 AM UTC-4, Arne Vajhøj wrote:
>> "Oracle will not include Java Web Start in Java SE 11 (18.9 LTS) and later."
>

> Not include means it's a separate download or there will be no
> existing version that works with 11?

The wording later in the text seem to indicate the latter.

From Oracle. Maybe an open source project will evolve to fill the gap.
"Maybe".

> If the latter, than webstart users
> just can't allow Java newer than 10 (or 8?) until an equivalent
> alternative is available.

8 and 11 are LTS.

9 and 10 are not LTS.

So 8 may be best.

Arne

[Eric Douglas]

On Tuesday, March 13, 2018 at 10:08:52 AM UTC-4, Arne Vajhøj wrote:
>
> From Oracle. Maybe an open source project will evolve to fill the gap.
> "Maybe".
>

So, what does webstart do?

1) Verifies a specific version of Java is installed. Is there another easy way to do this?

2) Delivers an app, copying jars, and verifying publisher. How do other delivery services work ie Steam?
I bought a computer last year which came with 5 games. They all require a login to a digital service, which you connect to each time you run the game and it downloads any updates before you start.

3) Checks your OS <resources os="Windows">. Normally everyone runs Windows so this is not an issue. We do have one user with a Mac but they don't run our application on it.

4) Displays a splash screen. The JNLP splash disappears anyway as soon as it gets into the initial class, and our application requires some loading before it displays the first window, so we already have a custom splash window to cover this time.

5) Runs the application. Isn't there another (platform independent) way to execute the client command of javaw.exe and pass the corresponding arguments as specified in the <application-desc main-class=> tag?

[Daniele Futtorovic]

On 2018-03-13 13:42, Eric Douglas wrote:
> For our application I use null layout and set all controls with fixed size and location with non-resizable windows, requiring a minimum resolution to run it.

Are you for real?

--
DF.

[Richard Maher]

:-)

I'd love to see an orientation change on his phone!

[Eric Douglas]

On Tuesday, March 13, 2018 at 8:35:14 PM UTC-4, Richard Maher wrote:
> I'd love to see an orientation change on his phone!

It's a Swing application, doesn't run on a phone..

[Eric Douglas]

On Tuesday, March 13, 2018 at 6:27:52 PM UTC-4, Daniele Futtorovic wrote:
> > For our application I use null layout and set all controls with fixed size and location with non-resizable windows, requiring a minimum resolution to run it.
>
> Are you for real?
>
> --
> DF.

It is simpler for the users and the developer, as we've converted over an old character based system which was much more limiting. It used to be just 25 rows and 80 columns of text, everything printed to a specific x,y and keyboard navigation through one field at a time. Have you tried rewriting an entire application (sales order, purchase order, inventory management, MRP) by yourself? I am currently the entire IT department. I've had one person helping over the years, people I've trained, we've gone through a few and the good ones leave for better paying jobs. You sound like a whipper snapper who grew up with tablets. Don't criticize what you don't know.

[Eric Douglas]

On Tuesday, March 13, 2018 at 6:27:52 PM UTC-4, Daniele Futtorovic wrote:

I actually write JFrame windows just for testing. My API is just the Swing controls, which go on a window generated by the API of the hybrid language we use, which puts everything in a fixed x,y with a fixed width,height.

http://documentation.basis.com/BASISHelp/WebHelp/winmethods3/bbjwindow_addwrappedjcomponent.htm

[Daniele Futtorovic]

On 2018-03-14 13:08, Eric Douglas wrote:
> On Tuesday, March 13, 2018 at 6:27:52 PM UTC-4, Daniele Futtorovic wrote:
>>> For our application I use null layout and set all controls with fixed size and location with non-resizable windows, requiring a minimum resolution to run it.
>>
>> Are you for real?
>>
>

> It is simpler for the users and the developer, as we've converted over an old character based system which was much more limiting. It used to be just 25 rows and 80 columns of text, everything printed to a specific x,y and keyboard navigation through one field at a time. Have you tried rewriting an entire application (sales order, purchase order, inventory management, MRP) by yourself? I am currently the entire IT department. I've had one person helping over the years, people I've trained, we've gone through a few and the good ones leave for better paying jobs. You sound like a whipper snapper who grew up with tablets. Don't criticize what you don't know.

I know those work conditions well enough to relate. Yes, I have at least
once tried to rewrite a legacy application by myself; tried long enough
to decide that it wasn't going to do it, and have managed to avoid it
since. Lucky me, I guess.

Pardon my reaction; I guess it was too impulsive. It's just that... I'm
stumped. I understand that UIs don't have to be shiny to be useful, but
I'm just shuddering at the thought of creating a UI using absolute
coordinates. I don't understand it. Even if the resulting UI were good
enough for whichever work is concerned, using, say, fixed dimension
widgets and letting a basic layout manager take care of them would seem
so much less of a hassle than specifying it all by hand.

I understand that there are, more often than not, idiosyncrasies lurking
beneath the surface in our line of work, compelling choices which to the
uninformed observer will seem obtuse. I'm not excluding that it might be
the case in your situation, and you have my sympathies if it does. It's
just that... well, you have been a prolific contributor to this group in
the recent past, and one that quite regularly presents situations or
advocates solutions that are, let's say, unorthodox. As such, I have at
times been wondering whether you were spinning for the sake of spin. Not
that I would blame you if you did, mind you; just that I would stop
listening. In that sense, my earlier question wasn't rhetorical -- I'm
genuinely wondering whether you're for real. If you tell me, yes, then
that's good enough for me.

--
DF.

[Martin Gregorie]

On Wed, 14 Mar 2018 05:08:15 -0700, Eric Douglas wrote:

> It is simpler for the users and the developer, as we've converted over
> an old character based system which was much more limiting. It used to
> be just 25 rows and 80 columns of text, everything printed to a specific
> x,y and keyboard navigation through one field at a time. Have you tried
> rewriting an entire application (sales order, purchase order, inventory
> management, MRP) by yourself? I am currently the entire IT department.
> I've had one person helping over the years, people I've trained, we've
> gone through a few and the good ones leave for better paying jobs. You
> sound like a whipper snapper who grew up with tablets. Don't criticize
> what you don't know.

I solved that problem another way: wrote a version of Curses in Java that
can be used with any Java program needing a 24x80 display instead of awt,
Swing, etc.

[Eric Douglas]

On Thursday, March 15, 2018 at 6:51:23 AM UTC-4, Daniele Futtorovic wrote:
> Pardon my reaction; I guess it was too impulsive. It's just that... I'm
> stumped. I understand that UIs don't have to be shiny to be useful, but
> I'm just shuddering at the thought of creating a UI using absolute
> coordinates. I don't understand it. Even if the resulting UI were good
> enough for whichever work is concerned, using, say, fixed dimension
> widgets and letting a basic layout manager take care of them would seem
> so much less of a hassle than specifying it all by hand.
>

It is no doubt unconventional but I think it makes sense once you see the where, the how, the why. I am currently still using a 3rd party API for windows/frames, putting in all the 'widget' controls using custom Swing. I have a main menu which is Java based. Some menu options kick off a new Java session, some still run the old character based windows because I don't have a mass conversion tool or the manpower to convert them all. A fixed x/y/w/h is not difficult since I hard coded standard fonts for consistency.

The API is a hybrid so the old code which is Business BASIC syntax (Java wasn't invented when we started) still works and we can create and use Java objects and methods directly. Our first big goal with Java was just to make newer looking screens which were laid out the same as the old screens to ease the transition for users who were used to the old screens. My second big goal was to invent new screen designs which could do everything the old screens did and more with less user interaction.

[Arne Vajhøj]

On 3/13/2018 10:58 AM, Eric Douglas wrote:
> So, what does webstart do?
>
> 1) Verifies a specific version of Java is installed. Is there
> another easy way to do this?
>
> 2) Delivers an app, copying jars, and verifying publisher. How do
> other delivery services work ie Steam? I bought a computer last year
> which came with 5 games. They all require a login to a digital
> service, which you connect to each time you run the game and it
> downloads any updates before you start.
>
> 3) Checks your OS <resources os="Windows">. Normally everyone runs
> Windows so this is not an issue. We do have one user with a Mac but
> they don't run our application on it.
>
> 4) Displays a splash screen. The JNLP splash disappears anyway as
> soon as it gets into the initial class, and our application requires
> some loading before it displays the first window, so we already have
> a custom splash window to cover this time.
>
> 5) Runs the application. Isn't there another (platform independent)
> way to execute the client command of javaw.exe and pass the
> corresponding arguments as specified in the <application-desc
> main-class=> tag?

Java Web Start is not that unique.

.NET click once did the same thing.

Various app stores does something similar.

Somebody already mentioned Steam.

The only thing that made Java Web Start unique was that it
shipped with Java.

Arne

[Uniqua Lykerd]

Daniele Futtorovic <da.fut...@laposte.net> Wrote in message:
> 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.
>

I'm building GUI apps based on JavaFX (and have been considering
Codename One as a replacement).

Installation is rather straightforward with Java 8, if you pack
your own classes plus JRE into a single executable. Decoupling
JavaFX is no different than adding other 3rd-party
libraries.

--


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

[Daniele Futtorovic]

On 2018-03-30 03:22, Uniqua Lykerd wrote:
> Daniele Futtorovic <da.fut...@laposte.net> Wrote in message:
>> 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.
>>
>

> I'm building GUI apps based on JavaFX (and have been considering
> Codename One as a replacement).
>
> Installation is rather straightforward with Java 8, if you pack
> your own classes plus JRE into a single executable. Decoupling
> JavaFX is no different than adding other 3rd-party
> libraries.

You gonna bundle the whole JRE into your installer? Pulling in
platform-specific things? Will you have to distribute an update on every
JRE update? And, how many floppies in that going to require!?

Perhaps you mean just pulling in a potentially-decoupled JavaFX part of
the JRE? But which will still have platform-specific stuff? And still
require you to publish updates to your app in order to leverage
improvements in the framework?

That does not sound like a Good Thing to me. And very contrary to the
whole idea of a JVM.

--
DF.