🚀 go-pugleaf

Michel Tourn wrote:

> More precisely, given the application description that I will give
> next, I would like to know whether java for this task (porting Mac
> software to PC):
> 
> - is appropriate.

To be honest, I do not know that much about Java, but all I have seen
really does NOT impress me. So far only VERY samll routines 
are working - or have you seen a REAL Programm?

Also interpreters and esp. debuggers are very much in the beta (if at
all) status on most platforms. 

We will start a big multiplatform development now, and we have decided
not to use Java - as there is not that much there to use.

Michel Tourn <tourn@dma.epfl.ch> wrote:
[snip]
>Since we still add features, we want to keep as much code in common
>as possible for both platforms. The old-fashioned (but reasonable)
>solution is to use a (more or less multiplatform) API framework. The
>new solution is, guess what... java.
[snip]
>So, before we trash some C++ framework solution in favour of java, I
>would like to hear good reasons of doing so or not.

>More precisely, given the application description that I will give
>next, I would like to know whether java for this task (porting Mac
>software to PC):

>- is appropriate. 
>- is worth the effort. (compared to the C++ framework solution)
[snip]

Hi Michel,

My general feeling about Java is that, yes, it *will be* a good
platform independent GUI framework one day. It is now quite a good
language, and there are some nice IDEs appearing for it now
(Symantec's Cafe springs to mind), and for OO app programming it is a
reasonably good fit. 

However, the GUI framework may be a little limiting today. There are
much better GUI frameworks around, although they don't generally try
to do all (any?) of the non-GUI stuff (container classes, network
stuff etc.) The Java AWT could do with some more form-oriented GUI
objects.

Remember, too, that it is still a Version 1.0 language! This is not to
be under-estimated!

Good luck with your choice, and drop in on the Platform Independent
GUI FAQ (PIGUI FAQ) for a list of some other frameworks. See:

    http://www.zeta.org.au/~rosko/pigui.htm

Cheers,
------------------------------------------------------------------
Ross McKay        | snail: GPO Box 562, Sydney NSW 2001 Australia
Soft Technologies | email: mailto:rosko@zeta.org.au
Sydney, Australia |   URL: http://www.zeta.org.au/~rosko
------------------------------------------------------------------
The opinions expressed are my own, not those of Soft Technologies.
    "The beatings will continue, until staff morale improves."

In article <3171A3EA.3F27@dma.epfl.ch>, Michel Tourn <tourn@dma.epfl.ch> writes:

> So, before we trash some C++ framework solution in favour of java, I
> would like to hear good reasons of doing so or not.
> . . .
> F. Java, its IDEs, its AWT, its available class libraries  will be
> appropriate for this task, but not now. 
> A. When ?

The inadequacy of AWT would be compelling for me.  Sun has committed
to adding a few gadgets, but I have seen nothing from them, or from
anyone else, that AWT or some other toolkit will ever be capable of
serious application development.  That is not to say that it won't
happen--just that I see no plans right now, so I'd be very wary of
spending development time betting on some future change in AWT.

Sun's current attitude about AWT offers little hope.  They seem to
think that they can achieve portability by making AWT a subset of the
functionality of existing GUIs; but that attitude is backwards.  To be
truly portable, it must be a superset of existing GUIs, emulating those
functions specific to each on the others in a portable way, and letting
developers query the system for its capabilities in a portable way.

There is never any excuse to sacrifice functionality for portability.
Ever.  Users demand--and rightly so--that they be able to take full
advantage of every dollar they've spent on their hardware and software,
and if they hear "well, we could do that but it wouldn't be portable"
from a vendor, they'll go to a vendor that will do it non-portably.
As a developer, if I can earn 10 cents more by writing a non-portable
program, I will, without the slightest twinge of guilt.

The only way to ensure portability, therefore, is the ensure that a
portable program is capable of doing everything the software needs 
to do, and AWT doesn't even come close.  The glaring omissions for
me are things like right-button popup menus, native video support
(for example, being able to query the system for its color capabilities
and things like monitor gamma, and then optimizing my diplay for it),
portable virtual keys for things like arrow and cut/paste, better
font metrics, and about 1000 more system properties.

Just one man's rant.  Thanks for the soapbox :-)

I love these sorts of discussions - take this not as an official policy
statement from Symantec, but rather "Will's ramblings..."

In article <Dq0rq5.9sz@unify.com>, lee@Unify.com (Lee Crocker) wrote:

> Sun's current attitude about AWT offers little hope.  They seem to
> think that they can achieve portability by making AWT a subset of the
> functionality of existing GUIs; but that attitude is backwards.  To be
> truly portable, it must be a superset of existing GUIs, emulating those
> functions specific to each on the others in a portable way, and letting
> developers query the system for its capabilities in a portable way.

Well, I completely disagree.  ;)

There was a certain project some time ago which attempted to pull off
exactly what you're describing.  It was called Bedrock, and more money
than you can possibly imagine was blown on it (this was before my time -
it has since metamorphed into ODF).  The scope of what you're talking
about is *massive*.  

Consider for a moment that the Mac has QuickDraw GX, drag & drop between
applications, QuickDraw3D, QuickTime, Open Transport (AppleTalk & TCP/IP),
Apple Guide, AppleScript/AppleEvents, OpenDoc, etc, etc, etc.  To do a Mac
app "right" and retain full crossplatform compatibility, you'd have to
implement all of these technologies on Windows.  You'd never ship such a
framework.

There is no reason that a developer couldn't build an application with
Java which checked at runtime what kind of machine it ran on and did
conditional branching depending on the results.  The Java application (you
probably wouldn't want to do this with an applet) could load native
libraries and make native system calls.

> There is never any excuse to sacrifice functionality for portability.
> Ever.  Users demand--and rightly so--that they be able to take full
> advantage of every dollar they've spent on their hardware and software,
> and if they hear "well, we could do that but it wouldn't be portable"
> from a vendor, they'll go to a vendor that will do it non-portably.

You're thinking in terms of commercial shrinkwrapped software.  The
current implementation of the AWT is quite adequate for Web page applets
(the primary attraction) and inhouse custom application development (most
likely deployed as client apps via the web).  I'll gloss over
nontraditional boxes such as the Pippin or Newton.

As a reallife example of this, I wrote a small application for internal
use to generate UserIDs and passwords for our secure server.  It's just a
small console app.  I used to build two versions, a Mac version and a PC
version.  From the high level language perspective, there's absolutely no
reason for having to build two versions - this app doesn't do *anything*
that really requires multiple builds beyond the simple incompatibility of
the x86 and the 680x0.  With Java, I just build it once and can post it to
a web server behind the firewall.

As an aside, before Java, this would be a classic argument against having
Macs (or Windows boxes or Unix boxes, depending on where you stand) in
your group - too much work to support muliple platforms.  With Java, I can
use my Mac, you can use your Windows box, and the guy down the hall can
use his Linux box.

> The only way to ensure portability, therefore, is the ensure that a
> portable program is capable of doing everything the software needs 
> to do, and AWT doesn't even come close.  The glaring omissions for
> me are things like right-button popup menus, native video support
> (for example, being able to query the system for its color capabilities
> and things like monitor gamma, and then optimizing my diplay for it),
> portable virtual keys for things like arrow and cut/paste, better
> font metrics, and about 1000 more system properties.

Actually, you can check for right mouse button clicks (see snippet below).

The other "glaring omission" is exactly what I was referring to earlier. 
I would hazard that less than one in a hundred developers are going to
care about the monitor gamma for display optimization.  Is this something
that is really *vital* to be in a crossplatform framework?  In a word,
NO.  If your application requires this sort of detail, develop a native
interface and hook into that.

The next year will be defined not just by which OS is superior, but which
has the best implementation of Java.  I wouldn't be suprised to see future
OS reviews include Java benchmarks.  The nirvana we are shooting for is to
let each user select the OS they prefer (for OS specific features and
applications), but to not be hampered by a lack of the mundane apps they
are required to use.

My 2 cents.

-Will


from D'Arcy Smith, one of our Java engineers...

/*** Begin snippet ***/
//    the following was "stolen" off of DejaNews... (sorry don't know who to 
//     give credit to):
     
//      This is how I distinguish mouse button clicks:
     
      public boolean handleEvent(Event evt) {
     
        switch(evt.id) {
     
      case Event.MOUSE_DOWN:
       if (evt.modifiers == evt.CTRL_MASK) {
        System.out.println("Right button pressed");
       } else {
        if (evt.modifiers == evt.ALT_MASK) {
         System.out.println("Middle btn pressed");
        } else {
         System.out.println("Left button pressed");
        }
       }
       return true;
      }
         }
          return super.handleEvent(evt);
     }
/*** End snippet ***/

---
Will Iverson,  Symantec Corporation
Macintosh Developer Relations - wiverson@bedford.symantec.com
As Will Rogers would have said, "There is no such thing as a free variable"

lee@Unify.com (Lee Crocker) wrote:

>Sun's current attitude about AWT offers little hope.  They seem to
>think that they can achieve portability by making AWT a subset of the
>functionality of existing GUIs; but that attitude is backwards.  To be
>truly portable, it must be a superset of existing GUIs, emulating those
>functions specific to each on the others in a portable way, and letting
>developers query the system for its capabilities in a portable way.

This is a tricky one.  Traditionally multi-platform systems have either
gone the way of "largest common subset" or "emulated superset", both
methods have their pro's and con's.  I expect that in the case of Java, the
largest common subset was the quickest and easiest way to get Java into the
hands of developers on as many platforms as possible.  If they'd gone the
other way we'd all still be playing with console-mode apps at present.

Having said that I'd have to agree that the present AWT is sadly lacking -
but it is adequate for the point on the learning curve that many new Java
recruits are at.

Let's face it, Java has a way to go yet before its ready for the big-time
and here's hoping that we see an alternative (Sun-approved or sourced)
user-interface class library soon.

>There is never any excuse to sacrifice functionality for portability.
>Ever.  Users demand--and rightly so--that they be able to take full
>advantage of every dollar they've spent on their hardware and software,
>and if they hear "well, we could do that but it wouldn't be portable"
>from a vendor, they'll go to a vendor that will do it non-portably.

In a production environment that is true - but as I mentioined above,
nobody really believes that Java is ready for production-quality
development yet - or if they do then they may get a few surprises :-)

>As a developer, if I can earn 10 cents more by writing a non-portable
>program, I will, without the slightest twinge of guilt.

I think that the goal of total platform independence is a laudable one and
given the choice I'd opt for a Java solution every time.  Why should I be
tied to one platform when by using the right tool I can have a much wider
choice.  If the client has performance concerns then they can throw more
silicon at the problem.  Silicon is still a *lot* cheaper than programmer
hours and the price disparity will only widen in the future.

>The only way to ensure portability, therefore, is the ensure that a
>portable program is capable of doing everything the software needs 
>to do, and AWT doesn't even come close.  The glaring omissions for
>me are things like right-button popup menus, native video support
>(for example, being able to query the system for its color capabilities
>and things like monitor gamma, and then optimizing my diplay for it),
>portable virtual keys for things like arrow and cut/paste, better
>font metrics, and about 1000 more system properties.

It's the eternal tradeoff of complexity versus functionality.  I think
you'll find that most developers will settle for less than 100%
functionality if it means that their job is easier and the results are
acceptable.  Look at the proliferation of tools such as high-level database
languages which are imensely powerful but at the same time force the user
into very narrow design choices in many areas.  Most programmers are more
than happy to accept the limitations in return for the greatly enhanced
productivity or they'd be writing in C/C++.

Give the customer the choice between a $100 application that's a 90% fit
and a $10,000 application that's a 100% fit and 99 times out of 100 you'll
sell the $100 app.  Of course there's always room for that $10,000 app and
there will always be a job for those who create them, but I think it's
important to realise where the mainstream markets lie.

>Just one man's rant.  Thanks for the soapbox :-)

My turn over... next please!  :-)

--------------------------------------------------------------
Aardvark - an weekly net-magazine taking a look at the 
internet in NZ and around the world.
http://www.voyager.co.nz/~bsimpson/aardvark.htm