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

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

Kiss your Applet good-bye

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

Contents

  Kiss your Applet good-bye Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-08-24 08:37 -0400
    How about 2K and 4K Displays? (Was: Kiss your Applet good-bye) j4n bur53 <janburse@fastmail.fm> - 2016-08-24 16:38 +0200
      Re: How about 2K and 4K Displays? (Was: Kiss your Applet good-bye) j4n bur53 <janburse@fastmail.fm> - 2016-08-24 16:44 +0200
      Re: How about 2K and 4K Displays? (Was: Kiss your Applet good-bye) Roedy Green <inquiry@mindprod.com> - 2016-09-14 15:08 -0700
    Re: Kiss your Applet good-bye Andreas Leitgeb <avl@logic.at> - 2016-08-24 16:57 +0000
      Re: Kiss your Applet good-bye Eric Douglas <e.d.programmer@gmail.com> - 2016-08-24 10:08 -0700
      Re: Kiss your Applet good-bye Arne Vajhøj <arne@vajhoej.dk> - 2016-08-24 20:10 -0400
    Re: Kiss your Applet good-bye Arne Vajhøj <arne@vajhoej.dk> - 2016-08-24 20:06 -0400
      Re: Kiss your Applet good-bye Eric Douglas <e.d.programmer@gmail.com> - 2016-08-25 04:42 -0700
    Re: Kiss your Applet good-bye Roedy Green <inquiry@mindprod.com> - 2016-09-04 23:12 -0700
      Re: Kiss your Applet good-bye Arne Vajhøj <arne@vajhoej.dk> - 2016-09-05 09:02 -0400
        Re: Kiss your Applet good-bye Martin Gregorie <martin@address-in-sig.invalid> - 2016-09-05 21:31 +0000
          Re: Kiss your Applet good-bye Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-09-05 18:18 -0400
            Re: Kiss your Applet good-bye Roedy Green <inquiry@mindprod.com> - 2016-09-06 12:08 -0700
              Re: Kiss your Applet good-bye Eric Douglas <e.d.programmer@gmail.com> - 2016-09-06 13:17 -0700
                Re: Kiss your Applet good-bye Arne Vajhøj <arne@vajhoej.dk> - 2016-09-06 19:27 -0400
              Re: Kiss your Applet good-bye Arne Vajhøj <arne@vajhoej.dk> - 2016-09-06 19:24 -0400
            Re: Kiss your Applet good-bye Martin Gregorie <martin@address-in-sig.invalid> - 2016-09-06 19:58 +0000
              Re: Kiss your Applet good-bye Eric Douglas <e.d.programmer@gmail.com> - 2016-09-06 13:08 -0700
              Re: Kiss your Applet good-bye Eric Douglas <e.d.programmer@gmail.com> - 2016-09-06 13:55 -0700
                Re: Kiss your Applet good-bye Martin Gregorie <martin@address-in-sig.invalid> - 2016-09-06 22:28 +0000
    Re: Kiss your Applet good-bye Eric Douglas <e.d.programmer@gmail.com> - 2016-10-14 12:44 -0700
      Re: Kiss your Applet good-bye Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-10-14 15:52 -0400
        Re: Kiss your Applet good-bye Eric Douglas <e.d.programmer@gmail.com> - 2016-10-14 13:07 -0700
      Re: Kiss your Applet good-bye Tim Slattery <tim@risingdove.com> - 2016-10-15 15:08 -0400
        Re: Kiss your Applet good-bye Eric Douglas <e.d.programmer@gmail.com> - 2017-10-03 13:54 -0700
          Re: Kiss your Applet good-bye Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2017-10-04 07:25 +0800
            Re: Kiss your Applet good-bye Andreas Leitgeb <avl@logic.at> - 2017-10-04 08:09 +0000

Page 1 of 2  [1] 2  Next page →

#35433 — Kiss your Applet good-bye

     It looks like even Oracle has given up on Java in the browser:

http://www.theregister.co.uk/2016/08/24/oracle_reveals_java_applet_api_deprecation_plan/

-- 
esosman@comcast-dot-net.invalid
The Tooth Fairy has gone high-tech, now pays in Bitecoin.

[toc] | [next] | [standalone]

#35435 — How about 2K and 4K Displays? (Was: Kiss your Applet good-bye)

Hi,

I would like to say Hello to 2K and 4K Displays,
but this is all still a mess. There are some
announcements around for JDK 9.

Even if you manage to scale your own app, on
Windows 10 I don't know haw to re-scale per
display, is there already a new AWT Event?

So it will basically do some scaling on its own
between different screens. But couldn't yet
test a Mac with Retina.

But if your app uses some system GUI, such as
file chooser this, part might not be scaled
at all only your application.

Bye

P.S.: I still think applets are great, they
are somehow re-appearing on Android, with new
instant link feature.

Eric Sosman schrieb:
>
>      It looks like even Oracle has given up on Java in the browser:
>
> http://www.theregister.co.uk/2016/08/24/oracle_reveals_java_applet_api_deprecation_plan/
>
>

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

#35436 — Re: How about 2K and 4K Displays? (Was: Kiss your Applet good-bye)

j4n bur53 schrieb:
> But if your app uses some system GUI, such as
> file chooser this, part might not be scaled
> at all only your application.

Recent JDK 8 file chooser has slightly improved,
but there are still some unscaled icons.

What I dont like is the 1:1 or 1:2 scaling from
the IntelliJ IDEA.

I have set my 2K display to 175% scaling, and
in the 1:2 scaling the icons are to big.

So I guess the best is gradual scaling of icons,
I did something on top of ImageIcon, works fine.

Bye

P.S.: The Gradual Icons I am currently using
are lacking a cache at the moment.

So they might not be suitable for apps that show
the same Icon multiple times.

The trick is simple:
http://stackoverflow.com/a/39016881/502187

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

#35608 — Re: How about 2K and 4K Displays? (Was: Kiss your Applet good-bye)

On Wed, 24 Aug 2016 16:38:34 +0200, j4n bur53 <janburse@fastmail.fm>
wrote:

>I would like to say Hello to 2K and 4K Displays,

You have to scale based both resolution and physical size of the
display.  If you just used resolution, with a super high res display,
your app would look like a postage stamp.

The the sizing of fonts need to be normalised too.  Different fonts at
the same size are wildly different sizes.  You cannot just exchange
fonts.

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

#35438

Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
>      It looks like even Oracle has given up on Java in the browser:
> http://www.theregister.co.uk/2016/08/24/oracle_reveals_java_applet_api_deprecation_plan/

This is about javaplugin, where Java's window appeared inside
the web page, not (yet?) about jnlp-apps.

Did I understand this correctly?

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

#35439

On Wednesday, August 24, 2016 at 12:57:19 PM UTC-4, Andreas Leitgeb wrote:
> Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
> >      It looks like even Oracle has given up on Java in the browser:
> > http://www.theregister.co.uk/2016/08/24/oracle_reveals_java_applet_api_deprecation_plan/
> 
> This is about javaplugin, where Java's window appeared inside
> the web page, not (yet?) about jnlp-apps.
> 
> Did I understand this correctly?

There is no issue with JNLP.  JNLP can communicate over the web but to do anything on a client machine requires the client to install a JRE and give permission to the author of a set of jars to download and run in that JRE.  Applets actually executed code within the browser, a much easier method for running malicious code.

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

#35446

On 8/24/2016 12:57 PM, Andreas Leitgeb wrote:
> Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
>>      It looks like even Oracle has given up on Java in the browser:
>> http://www.theregister.co.uk/2016/08/24/oracle_reveals_java_applet_api_deprecation_plan/
>
> This is about javaplugin, where Java's window appeared inside
> the web page, not (yet?) about jnlp-apps.
>
> Did I understand this correctly?

I think so.

Anyway the actual action is clearly indicated in the article.

<quote>
Add the @Deprecated(since="9") annotation to the following classes:

     java.applet.AppletStub
     java.applet.Applet
     java.applet.AudioClip
     java.applet.AppletContext
     javax.swing.JApplet
</quote>

so my take is that it only actual applets but including
applets launched via JNLP that will become deprecated.

Arne

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

#35445

On 8/24/2016 8:37 AM, Eric Sosman wrote:
>
>     It looks like even Oracle has given up on Java in the browser:
>
> http://www.theregister.co.uk/2016/08/24/oracle_reveals_java_applet_api_deprecation_plan/

Nothing surprising or unexpected in that.

The browser vendors are dropping support for the required tie in.

Demand for applet based solutions are very close to zero.

Very natural to mark these classes as deprecated.

If they added more prompts "Are you really sure you want to run
this applet?", "Are you really really sure you want to run
this applet?" and "Are you really really really sure you want
to run this applet?" then it would have been a joke.

:-)

Arne

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

#35450

On Wednesday, August 24, 2016 at 8:06:49 PM UTC-4, Arne Vajhøj wrote:
> If they added more prompts "Are you really sure you want to run
> this applet?", "Are you really really sure you want to run
> this applet?" and "Are you really really really sure you want
> to run this applet?" then it would have been a joke.

That is the oldest programmer joke.
Problem: Data is messed up because user clicked something accidentally
Solution: Add more prompts to be sure user knows they're clicking

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

#35539

On Wed, 24 Aug 2016 08:37:07 -0400, Eric Sosman
<esosman@comcast-dot-net.invalid> wrote:

>http://www.theregister.co.uk/2016/08/24/oracle_reveals_java_applet_api_deprecation_plan/
 
I feel betrayed. I have written all kinds of Applets. Now they no
longer work.  Java has been so relentless about the prinicple: Works
once, works forever. Now that have flagrantly violated it.

I can see they don't like having to keep running to stand still with
browser interfaces.  They then should create something browser
independent that might work like PDF independent of the browser to act
as the womb.

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

#35540

On 9/5/2016 2:12 AM, Roedy Green wrote:
> On Wed, 24 Aug 2016 08:37:07 -0400, Eric Sosman
> <esosman@comcast-dot-net.invalid> wrote:
>
>> http://www.theregister.co.uk/2016/08/24/oracle_reveals_java_applet_api_deprecation_plan/
>
> I feel betrayed. I have written all kinds of Applets. Now they no
> longer work.  Java has been so relentless about the prinicple: Works
> once, works forever. Now that have flagrantly violated it.
>
> I can see they don't like having to keep running to stand still with
> browser interfaces.  They then should create something browser
> independent that might work like PDF independent of the browser to act
> as the womb.

Oracle does not have much choice.

The makers of browsers are dropping applet support.

Why maintain something that cannot be used by anyone.

Arne

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

#35541

On Mon, 05 Sep 2016 09:02:16 -0400, Arne Vajhøj wrote:

> On 9/5/2016 2:12 AM, Roedy Green wrote:
>> On Wed, 24 Aug 2016 08:37:07 -0400, Eric Sosman
>> <esosman@comcast-dot-net.invalid> wrote:
>>
>>> http://www.theregister.co.uk/2016/08/24/
oracle_reveals_java_applet_api_deprecation_plan/
>>
>> I feel betrayed. I have written all kinds of Applets. Now they no
>> longer work.  Java has been so relentless about the prinicple: Works
>> once, works forever. Now that have flagrantly violated it.
>>
>> I can see they don't like having to keep running to stand still with
>> browser interfaces.  They then should create something browser
>> independent that might work like PDF independent of the browser to act
>> as the womb.
> 
> Oracle does not have much choice.
> 
> The makers of browsers are dropping applet support.
>
Not only that, but they are steadily dropping support for ANYTHING they 
didn't write, e.g xpdf, even though their internal PDF readers don't work 
as well as the long-standing external equivalents.
  
> Why maintain something that cannot be used by anyone.
>
Because their internal 'solutions' are crap?
  

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

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

#35542

On 9/5/2016 5:31 PM, Martin Gregorie wrote:
> On Mon, 05 Sep 2016 09:02:16 -0400, Arne Vajhøj wrote:
>>
>> Oracle does not have much choice.
>>
>> The makers of browsers are dropping applet support.
>>
> Not only that, but they are steadily dropping support for ANYTHING they
> didn't write, e.g xpdf, even though their internal PDF readers don't work
> as well as the long-standing external equivalents.
>
>> Why maintain something that cannot be used by anyone.
>>
> Because their internal 'solutions' are crap?

     Just a bit more charitably, perhaps it's because they're sick
and tired of getting bad press and bug reports for things they do
not and cannot control.  "Stupid Google!  Your crappy Chrome crashes
whenever I try to run this out-of-date version of Adobe Reader!"
"Stupid Microsoft!  I got a ransomware infection simply by running
a Java applet on your crappy Windows!"  (If you don't believe that
complaints of this sort arise, get directed at the non-involved
party, and lead to all kinds of flamage both on line and in print,
you live in a nicer world than I do.)

     Remember, we *asked* for this kind of problem when we decided
that Component Architecture Is The Way To Go.  Things are fine and
dandy as long as the components play well together -- but then you
get a security fix in Component X that causes Component Y to
misbehave, so you pester Vendor X for a fix and he says "It's Y's
bug," and Y says "We didn't change anything; X is at fault,"
and meanwhile your airplanes are sitting idly on the tarmac ...

     In theory, atomizing every problem into a myriad components
means the components are all small enough to be Done Right.  In
practice, it's not so easy.  I think we're seeing the backlash.

-- 
esosman@comcast-dot-net.invalid
The Tooth Fairy has gone high-tech, now pays in Bitecoin.

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

#35547

On Mon, 5 Sep 2016 18:18:47 -0400, Eric Sosman
<esosman@comcast-dot-net.invalid> wrote:

>     In theory, atomizing every problem into a myriad components
>means the components are all small enough to be Done Right.  In
>practice, it's not so easy.  I think we're seeing the backlash.
 

We have Java Web start which in theory does not have the problems of
Applets, but seems to be on the same deprecation track.

We have JavaScript which behaves differently on each platform, even if
each vendor is responsible for security. 

Surely it should be possible for plugins to run in air tight boxes
using hardware to enforce the isolation. The isolation should be at
least as good as app/os isolation.

Sun had a terrible browser years ago.  Perhaps it could be brought up
to date so Oracle could ensure write once run forever.

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

#35550

On Tuesday, September 6, 2016 at 3:08:30 PM UTC-4, Roedy Green wrote:
> We have Java Web start which in theory does not have the problems of
> Applets, but seems to be on the same deprecation track.

I haven't heard anything about deprecating Webstart.  It is built in to the JRE so it has nothing to do with browsers.  It is a simple way of running a client-server application.  You can specify which jars are needed for the client side and it will check for the latest version every time it runs.  Without that you would have to have your own installer and manually have the clients update, or run your own bootstrap utility to check the versions and download for them.  It has nothing to do with any browser other than providing a link to download the JNLP file to pass to javaws.exe.

Other than the jars and version management you could manually send jars to the client to run the same application with javaw.exe so I see no reason to deprecate. (for client-server this can either use Oracle's built in sockets to talk to another JVM, or apache http web commands to talk to any web service)

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

#35556

On 9/6/2016 4:17 PM, Eric Douglas wrote:
> On Tuesday, September 6, 2016 at 3:08:30 PM UTC-4, Roedy Green
> wrote:
>> We have Java Web start which in theory does not have the problems
>> of Applets, but seems to be on the same deprecation track.
>
> I haven't heard anything about deprecating Webstart.  It is built in
> to the JRE so it has nothing to do with browsers.

I think the confusion that may come from the fact that applets
can be started via JNLP and that applets started via JNLP are
as deprecated as applets tsrated the traditional way.

>                                                   It is a simple way
> of running a client-server application.  You can specify which jars
> are needed for the client side and it will check for the latest
> version every time it runs.  Without that you would have to have your
> own installer and manually have the clients update, or run your own
> bootstrap utility to check the versions and download for them.  It
> has nothing to do with any browser other than providing a link to
> download the JNLP file to pass to javaws.exe.

Yes.

.NET has the same feature called ClickOnce.

Arne

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

#35555

On 9/6/2016 3:08 PM, Roedy Green wrote:
> On Mon, 5 Sep 2016 18:18:47 -0400, Eric Sosman
> <esosman@comcast-dot-net.invalid> wrote:
>>     In theory, atomizing every problem into a myriad components
>> means the components are all small enough to be Done Right.  In
>> practice, it's not so easy.  I think we're seeing the backlash.
>
> We have Java Web start which in theory does not have the problems of
> Applets, but seems to be on the same deprecation track.

I don't think so.

> We have JavaScript which behaves differently on each platform,

That may have been the case 10-15 years ago. Today browsers
are much more standard compliant. And the usage of frameworks
hide remaining issues from the developer.

> Surely it should be possible for plugins to run in air tight boxes
> using hardware to enforce the isolation. The isolation should be at
> least as good as app/os isolation.

If forcing people to use a software plugin in their browser
is a no go today, then requiring users to have some specific
hardware is totally out of the question.

Arne

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

#35548

On Mon, 05 Sep 2016 18:18:47 -0400, Eric Sosman wrote:

> On 9/5/2016 5:31 PM, Martin Gregorie wrote:
>> On Mon, 05 Sep 2016 09:02:16 -0400, Arne Vajhøj wrote:
>>>
>>> Oracle does not have much choice.
>>>
>>> The makers of browsers are dropping applet support.
>>>
>> Not only that, but they are steadily dropping support for ANYTHING they
>> didn't write, e.g xpdf, even though their internal PDF readers don't
>> work as well as the long-standing external equivalents.
>>
>>> Why maintain something that cannot be used by anyone.
>>>
>> Because their internal 'solutions' are crap?
> 
>      Just a bit more charitably, perhaps it's because they're sick
> and tired of getting bad press and bug reports for things they do not
> and cannot control.  "Stupid Google!  Your crappy Chrome crashes
> whenever I try to run this out-of-date version of Adobe Reader!" "Stupid
> Microsoft!  I got a ransomware infection simply by running a Java applet
> on your crappy Windows!"  (If you don't believe that complaints of this
> sort arise, get directed at the non-involved party, and lead to all
> kinds of flamage both on line and in print, you live in a nicer world
> than I do.)
>
What I'm complaining about is that frequently a browser's built-in way of 
displaying a file is the simplest thing they can get away with and in 
many cases this simply isn't adequate for serious use. 

For instance, the new Vivaldi browser, written by the original Opera 
developers, is potentially very good and quite a bit faster than Firefox, 
but in practise is almost unusable because you can only view files with 
the builtin tools. Its PDF viewer is woeful: doesn't provide any way to 
skip to a given page and is incapable of dealing with very long PDFs such 
as the NASA Columbia or the Dutch MH17 crash reports, respectively 248 
and 279 pages. In both cases it stalls when asked to load these PDFs. 
OTOH, other browsers, e.d Firefox or Pale Moon, don't have a built-in PDF 
viewer but DO let you choose to use evince, xpdf or to nominate another 
application. 
  


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

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

#35549

On Tuesday, September 6, 2016 at 3:58:48 PM UTC-4, Martin Gregorie wrote:
> For instance, the new Vivaldi browser, written by the original Opera 
> developers, is potentially very good and quite a bit faster than Firefox, 
> but in practise is almost unusable because you can only view files with 
> the builtin tools. Its PDF viewer is woeful: doesn't provide any way to 
> skip to a given page and is incapable of dealing with very long PDFs such 
> as the NASA Columbia or the Dutch MH17 crash reports, respectively 248 
> and 279 pages. In both cases it stalls when asked to load these PDFs. 
> OTOH, other browsers, e.d Firefox or Pale Moon, don't have a built-in PDF 
> viewer but DO let you choose to use evince, xpdf or to nominate another 
> application. 

The built in Chrome PDF viewer I believe struggled when it first came out.  It currently doesn't seem to have any problem displaying this 585 page PDF.
http://govinfo.library.unt.edu/911/report/911Report.pdf

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

#35552

On Tuesday, September 6, 2016 at 3:58:48 PM UTC-4, Martin Gregorie wrote:
> For instance, the new Vivaldi browser, written by the original Opera 
> developers, is potentially very good and quite a bit faster than Firefox, 
> but in practise is almost unusable because you can only view files with 
> the builtin tools. Its PDF viewer is woeful: doesn't provide any way to 
> skip to a given page and is incapable of dealing with very long PDFs such 
> as the NASA Columbia or the Dutch MH17 crash reports, respectively 248 
> and 279 pages. In both cases it stalls when asked to load these PDFs. 
> OTOH, other browsers, e.d Firefox or Pale Moon, don't have a built-in PDF 
> viewer but DO let you choose to use evince, xpdf or to nominate another 
> application. 

I found your Dutch crash report, again no problem displaying in Chrome.
https://www.onderzoeksraad.nl/uploads/phase-docs/1006/debcd724fe7breport-mh17-crash.pdf

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web