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

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

Java claims WORA

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

Contents

  Java claims WORA owais <awais4you@gmail.com> - 2012-06-20 08:33 -0700
    Re: Java claims WORA Robert Klemme <shortcutter@googlemail.com> - 2012-06-20 09:21 -0700
    Re: Java claims WORA Gene Wirchenko <genew@ocis.net> - 2012-06-20 09:46 -0700
    Re: Java claims WORA Lew <lewbloch@gmail.com> - 2012-06-20 10:47 -0700
      Re: Java claims WORA "Mike Schilling" <mscottschilling@hotmail.com> - 2012-06-24 16:56 -0700
    Re: Java claims WORA Arne Vajhøj <arne@vajhoej.dk> - 2012-06-20 17:02 -0400
      Re: Java claims WORA glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-06-20 21:45 +0000
        Re: Java claims WORA Martin Gregorie <martin@address-in-sig.invalid> - 2012-06-20 22:25 +0000
          Re: Java claims WORA Robert Klemme <shortcutter@googlemail.com> - 2012-06-21 00:57 +0200
            Re: Java claims WORA Roedy Green <see_website@mindprod.com.invalid> - 2012-06-20 16:46 -0700
              Re: Java claims WORA David Lamb <dalamb@cs.queensu.ca> - 2012-06-20 19:56 -0400
        Re: Java claims WORA Arne Vajhøj <arne@vajhoej.dk> - 2012-06-20 19:16 -0400
          Re: Java claims WORA "Mike Schilling" <mscottschilling@hotmail.com> - 2012-06-24 16:58 -0700
    Re: Java claims WORA Roedy Green <see_website@mindprod.com.invalid> - 2012-06-20 16:43 -0700
      Re: Java claims WORA Arne Vajhøj <arne@vajhoej.dk> - 2012-06-20 20:30 -0400
      Re: Java claims WORA Roedy Green <see_website@mindprod.com.invalid> - 2012-06-20 18:37 -0700
        Re: Java claims WORA Arne Vajhøj <arne@vajhoej.dk> - 2012-06-20 21:47 -0400
    Re: Java claims WORA Thomas Richter <thor@math.tu-berlin.de> - 2012-06-22 19:18 +0200
      Re: Java claims WORA "John B. Matthews" <nospam@nospam.invalid> - 2012-06-22 15:59 -0400
        Re: Java claims WORA Roedy Green <see_website@mindprod.com.invalid> - 2012-06-24 04:43 -0700
          Re: Java claims WORA "John B. Matthews" <nospam@nospam.invalid> - 2012-06-24 18:51 -0400
            Re: Java claims WORA Lew <noone@lewscanon.com> - 2012-06-24 23:27 -0700
              Re: Java claims WORA "John B. Matthews" <nospam@nospam.invalid> - 2012-06-26 15:43 -0400
      Re: Java claims WORA Jim Janney <jjanney@shell.xmission.com> - 2012-06-22 18:23 -0600
    Re: Java claims WORA Jan Burse <janburse@fastmail.fm> - 2012-06-22 21:40 +0200
      Re: Java claims WORA David Lamb <dalamb@cs.queensu.ca> - 2012-06-25 09:57 -0400
        Re: Java claims WORA Jan Burse <janburse@fastmail.fm> - 2012-06-25 20:34 +0200
          Re: Java claims WORA Jan Burse <janburse@fastmail.fm> - 2012-06-25 20:44 +0200

Page 2 of 2 — ← Prev page 1 [2]

#15569

In article <u5vdu75uinlmblggdlue7vlbjq64flga8a@4ax.com>,
 Roedy Green <see_website@mindprod.com.invalid> wrote:

> On Fri, 22 Jun 2012 15:59:43 -0400, "John B. Matthews"
> <nospam@nospam.invalid> wrote, quoted or indirectly quoted someone who
> said :
> 
> >I'll second the need for testing, but I've found that using layouts 
> >properly and respecting a component's preferred size greatly reduces 
> >the number of cross-platform problems. There's a recent example 
> >here:
> 
> one of the big problems is when you substitute a font, the characters 
> are not the same size.  I would like to normalize fonts to their true 
> size so that when you substitute fonts, the actual real estate 
> consumed varies only a little.

I must demur: a typical JComponent, such as JLabel, goes to considerable 
lengths to calculate its preferred size using the metrics of the 
selected Font. As long as you

- don't veto the calculation,
- don't preclude resizing,
- do use a LayoutManager, and
- do pack() the enclosing Container

the chosen Font is irrelevant. If the Font must be changed dynamically, 
revalidate() and repaint() should suffice.

> Another would be a guaranteed to render all glyphs, even if it means 
> substituting from some other font.  Failing that at telling the 
> truth. Java claims to render a glyph when all it does in render some 
> generic glyph.

Font substitution shouldn't cause a problem. Missing glyphs and 
mendacious canDisplay() are annoying, but the metrics are typically 
reliable.

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

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

#15574

John B. Matthews wrote:
> Roedy Green wrote:
>> John B. Matthews wrote, quoted or indirectly quoted someone who said :
>>> I'll second the need for testing, but I've found that using layouts
>>> properly and respecting a component's preferred size greatly reduces
>>> the number of cross-platform problems. There's a recent example
>>> here:
>>
>> one of the big problems is when you substitute a font, the characters
>> are not the same size.  I would like to normalize fonts to their true
>> size so that when you substitute fonts, the actual real estate
>> consumed varies only a little.
>
> I must demur: a typical JComponent, such as JLabel, goes to considerable
> lengths to calculate its preferred size using the metrics of the
> selected Font. As long as you
>
> - don't veto the calculation,
> - don't preclude resizing,
> - do use a LayoutManager, and
> - do pack() the enclosing Container
>
> the chosen Font is irrelevant. If the Font must be changed dynamically,
> revalidate() and repaint() should suffice.
>
>> Another would be a guaranteed to render all glyphs, even if it means
>> substituting from some other font.  Failing that at telling the
>> truth. Java claims to render a glyph when all it does in render some
>> generic glyph.
>
> Font substitution shouldn't cause a problem. Missing glyphs and
> mendacious canDisplay() are annoying, but the metrics are typically
> reliable.

Depends on what problem you care about, and what constitutes relevance.

You might not be happy with a screen that doubles its width to accommodate a 
font, for design reasons.

Sure, Swing handles the technical details of resizing, and layouts do wonders 
to work around variances in fonts and so forth, but that's all technical 
problems and solutions and relevance.

Design problems and solutions and relevance revolve around what looks right 
and works for the program's purpose, i.e., the user's purpose. Roedy's wish 
for fonts that squish instead of windows that widen is not uncommon nor 
unreasonable, from a design perspective. You might prefer the data entry box 
not get smaller to make room for a longer prompt.

So technical dimension, no problem, design dimension, eh, depends on the 
design and what changes it can withstand.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

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

#15605

In article <js90cn$m5o$1@news.albasani.net>, Lew <noone@lewscanon.com> 
wrote:

> John B. Matthews wrote:
> > Roedy Green wrote:
> >> John B. Matthews wrote, quoted or indirectly quoted someone who said :
> >>> I'll second the need for testing, but I've found that using 
> >>> layouts properly and respecting a component's preferred size 
> >>> greatly reduces the number of cross-platform problems. There's a 
> >>> recent example here:
> >>
> >> one of the big problems is when you substitute a font, the 
> >> characters are not the same size.  I would like to normalize fonts 
> >> to their true size so that when you substitute fonts, the actual 
> >> real estate consumed varies only a little.
> >
> > I must demur: a typical JComponent, such as JLabel, goes to 
> > considerable lengths to calculate its preferred size using the 
> > metrics of the selected Font. As long as you
> >
> > - don't veto the calculation,
> > - don't preclude resizing,
> > - do use a LayoutManager, and
> > - do pack() the enclosing Container
> >
> > the chosen Font is irrelevant. If the Font must be changed dynamically,
> > revalidate() and repaint() should suffice.
> >
> >> Another would be a guaranteed to render all glyphs, even if it 
> >> means substituting from some other font.  Failing that at telling 
> >> the truth. Java claims to render a glyph when all it does in 
> >> render some generic glyph.
> >
> > Font substitution shouldn't cause a problem. Missing glyphs and 
> > mendacious canDisplay() are annoying, but the metrics are typically 
> > reliable.
> 
> Depends on what problem you care about, and what constitutes relevance.
> 
> You might not be happy with a screen that doubles its width to 
> accommodate a font, for design reasons.
> 
> Sure, Swing handles the technical details of resizing, and layouts do 
> wonders to work around variances in fonts and so forth, but that's 
> all technical problems and solutions and relevance.
> 
> Design problems and solutions and relevance revolve around what looks 
> right and works for the program's purpose, i.e., the user's purpose. 
> Roedy's wish for fonts that squish instead of windows that widen is 
> not uncommon nor unreasonable, from a design perspective. You might 
> prefer the data entry box not get smaller to make room for a longer 
> prompt.
> 
> So technical dimension, no problem, design dimension, eh, depends on 
> the design and what changes it can withstand.

This is a valuable distinction. The physical font selected for a given 
family may not _double_ the width, but localization might come close. As 
a practical matter, I sometimes relegate the full text to a tool tip, 
leaving a digest in the label. Size variants can be handy, too:

<http://docs.oracle.com/javase/tutorial/uiswing/lookandfeel/size.html>

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

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

#15535

Thomas Richter <thor@math.tu-berlin.de> writes:

> Am 20.06.2012 17:33, schrieb owais:
>> Java claims WORA (write once and run anywhere). Do you agree with this statement that all java programs can be run anywhere (all platforms)? Can you identify a scenario where this claim may not hold true?
>
> Java is more like WOTA for me - write once, test everywhere. It's
> quite acceptable for simple programs, but as soon as it gets more
> complex than this, there are subtle differences between Java
> installations on Windows and Linux, and from version to version. I've
> seen cases where Java does not size windows correctly on one version,
> but not on others for reasons that are not clear to me, where input
> focus handling was slightly different and inconsistent, where refresh
> handling and the order of requests is slightly different, where window
> placement may or may not work... In theory, Java is very nice for
> running everywhere, but you still need to test and need to tweak a bit
> to get it working consistently.

A few years ago I was assigned the task of getting a Swing-based
program, developed under Windows, to run under Linux.  At the time it
represented perhaps 30 to 40 programmer-years of work: not large by some
standards but not trivial either.  Part of the build process included a
small set of unit tests and a much larger set of what amounted to
integration tests to load the program and run it through its paces:
these were originally written using jfcUnit but had evolved to the point
that no actual jfcUnit code was still in use.  These tests normally took
somewhat over an hour to run.

It took me a few days to get the program to the point where you could
run and use it under Linux.  There were some custom DLLs written in C++
that had to be recompiled, and a few odd things like Unicode constants
in the source code that needed to be replaced with their hex versions.
But I was never able to get the integration tests to pass, or even to
fail in the same places consistently.  There was an issue with dialogs
that wouldn't go away -- I verified that the code to close them was
running and as far as Java was concerned they seemed to be gone, but you
could still see them on the screen.  Also various random-seeming null
pointer exceptions and such-like.  After I'd been working on it for
about four weeks management decided they didn't want it that much and
abandoned the effort.

The point here isn't that it can't be done.  With enough time and
support from management I could have found and fixed the problems, or we
could have found someone who else who could.  (I'm happy to say that
sending it to customers without passing the tests first was never on the
table.)  But it certainly wasn't automatic.  If you intend to deploy to
multiple platforms my advice would be to test on each platform right
from the start.

-- 
Jim Janney

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

#15520

owais schrieb:
> Java claims WORA (write once and run anywhere). Do you agree
> with this statement that all java programs can be run anywhere
> (all platforms)? Can you identify a scenario where this claim
> may not hold true?

Java has different degrees of WORA. For example one might
distinguish between headless Java and Java with a GUI.

Headless Java has a broader WORA. If you accept that WORA
also includes transforming bytecode, then via DEX you can
run Java on an Android platforms.

Java with a GUI has a narrower WORA. If you opt for Swing
then you have a good portability on platforms such as Windows,
Mac and Linux. SWT would be an alternative for Swing.

But for Android you would need to rewrite the GUI. But then
with an Android GUI you can cover tablets, phones etc..
which isn't bad.

An Architecture that works for both Swing (or SWT) and Android
would look as follows:

+---------------+
+ Swing GUI     |
+---------------+-+---------------+
                   | Headless Part |
+---------------+-+---------------+
| Android GUI   |
+---------------+

There are a couple of design patterns that help you with doing
the above. For the headless part you have WORA, but you need
to build two apps on top of it, a .jar (for Swing) and
an .apk (for Android).

The above recently worked for me.

Bye

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

#15578

On 22/06/2012 3:40 PM, Jan Burse wrote:
> An Architecture that works for both Swing (or SWT) and Android
> would look as follows:
>
> +---------------+
> + Swing GUI |
> +---------------+-+---------------+
>                   | Headless Part |
> +---------------+-+---------------+
> | Android GUI |
> +---------------+

I was hoping to develop some notes for doing that to pass along to 
upper-year undegrads. Do you have any suggestions / guidelines / 
tutorials you could point to?

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

#15583

David Lamb schrieb:
> I was hoping to develop some notes for doing that to pass along to
> upper-year undegrads. Do you have any suggestions / guidelines /
> tutorials you could point to?

If you can place business delegates into the headless part,
then you are practically done. You only need two different
clients, a Swing client and an Android client.

http://java.sun.com/blueprints/corej2eepatterns/Patterns/BusinessDelegate.html

The above would allow to build a Swing client and an Android
client that differ considerably, for example that implement
different workflow and/or different GUI layout.

If you want some common support so that a certain similarity
of the Swing client and the Android is assured, you might want to
look into the MVC pattern for example.

http://java.sun.com/blueprints/patterns/MVC-detailed.html

The result would then be something else:

+---------------+
+ Swing View    |
+---------------+-+----------------+ +---------------+
                   | GUI Controller |-| Headless Part |
+---------------+-+----------------+ +---------------+
| Android View  |
+---------------+

But I didn't follow the above architecture, since I was expecting
to implement a different layout and/or workflow for the Android
client, compared to the Swing client that was already there.

But manually programmatically by mirroring Swing code in the
Android code in many places I have now a similar layout and/or
workflow. But it is not enforced and changing the layout and/or
workflow accross both clients is now a double effort.

Bye

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

#15585

Jan Burse schrieb:
>
> http://java.sun.com/blueprints/corej2eepatterns/Patterns/BusinessDelegate.html
>
>
> The above would allow to build a Swing client and an Android
> client that differ considerably, for example that implement
> different workflow and/or different GUI layout.

Oops, I just see the above pattern is a little bit over
the top, it more addresses lose coupling of client and
business services. But I guess it is not forbidden to also
tightly couple them. You still get the reuse benefit.

In my present case the client and the business services
form one tier. A business servivce might spawn to other
tiers. But client and business services are bundled
together for deloyment.

Practically one can approach this as follows:

Create Project I for the Business Services,
-------------------------------------------
you can compile the result into business.jar

Create Project II for the Swing Client,
-------------------------------------------
this project will use the library business.jar,
and produce swingclient.jar. To execute the
result both business.jar and swingclient.jar
will be in the class path. But you can also
merge them.

Create Project III for the Android Client,
-------------------------------------------
same idea as for the Swing Client, but you
need to additionally run your results to
some Android tool chains. And have some
Android emulator and/or device available
for testing.

Have fun

Bye

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web