AFC vs. IFC
Weicong Wang
Could anyone give me more information about MS AFC and netscape IFC? I
think that IFC is little buggy while AFC has more bugs. But which we
should use?
--
======================================================
Wang Weicong Rutgers, the State Univ. of New Jersey
------------------------------------------------------
CAIP Center, PO Box 1390
Piscataway , NJ 08855-1390
------------------------------------------------------
Tel: (O) 908-445-0659/0660 (H) 908-878-2734
http://www.caip.rutgers.edu/~weicong
------------------------------------------------------
Peter van der Linden
Weicong Wang <wei...@caip.rutgers.edu> wrote:
>Could anyone give me more information about MS AFC and netscape IFC? I
>think that IFC is little buggy while AFC has more bugs. But which we
>should use?
Since much of IFC is going into the AWT for JDK 1.2, IFC is the one
to use.
--
---
Peter van der Linden
Java Programmers FAQ ---> http://www.best.com/~pvdl
Chance favors the prepared mind.
James P. White
Weicong Wang wrote:
>
> Could anyone give me more information about MS AFC and netscape IFC? I
> think that IFC is little buggy while AFC has more bugs. But which we
> should use?
I am not aware of any substantial bugs in IFC. It was released 1.0 in
January and has been extremely stable. IFC 1.1 has been out for more
than a month and is also very reliable (and is fully compatible with IFC
1.0 applications). The big problems have been in the buggy JDK 1.1.x
implementations, which affect all Java applications, not just IFC.
I was at a demonstration of AFC last night put on by Brad Merrill, Java
Evangelist for Microsoft. AFC is not anywhere close to being as good as
IFC, and they don't have anything like Constructor. But of course that
will change as time goes on. An important point to know is that the
current AFC API will change substantially with the next beta.
If you want to build great applications now, then use IFC.
If you don't need to start serious development for another 4 to 6
months, then you should wait and compare AFC and JFC (Java Foundation
Classes, which will be part of JDK 1.2 and are based on IFC). The first
public alpha/beta of JFC will be available next month.
jim
-----------------------------------------------------------------------
James P. White Netscape DevEdge Champion for IFC
Director of Technology Adventure Online Gaming http://www.gameworld.com
Developers of Gameworld -- Live Action Role-Playing and Strategic Games
j...@pagesmiths.com Pagesmiths' home is http://www.pagesmiths.com
James P. White
Matt Landau wrote:
>
> In article <5oc3fe$7cv$1...@engnews2.Eng.Sun.COM>, lin...@positive.eng.sun.com (Peter van der Linden) wrote:
> >Weicong Wang <wei...@caip.rutgers.edu> wrote:
> >>Could anyone give me more information about MS AFC and netscape IFC? I
> >>think that IFC is little buggy while AFC has more bugs. But which we
> >>should use?
> >
> >to use.
Sun's position is "We cannot in good conscience recommend using IFC in
preparation for JFC. Either use AWT or wait for JFC."
> Except that Microsoft has announced that they're not going to ship JFC with
> any of their products. So the world gets to split into the "applets that work
> with Netscape and Sun browsers vs applets that work with Microsoft browsers"
> camps, or every user gets to figure out how to download and install the GUI
> class library for the "other" browser. Lovely.
Well, that is not an exception. It is another reason to use IFC since
it is *far* better than AFC is already shipped with Navigator 4. AFC is
at least 4 to 6 months from being competitive with IFC. If they put AFC
in IE 4, then AFC is going to suffer because it will not be nearly
complete.
But the point is well made that Microsoft may not fully support JDK 1.2,
and especially JFC. I have said as much to the JavaSoft people, but
they are committed to the path they are on. IFC is 100% Pure Java,
demonstrating that there is no reason to make all of JFC core to Java.
They should just make the fixes to AWT that are required, such as the
drag and drop that was promised for 1.1.
The distribution problem cannot, and will not, be solved by all class
libraries being shipped with all browsers. The problem is solved by
using trusted push systems such as Castanet, Netcaster, and whatever
Microsoft is calling their thing.
Matt Landau
In article <5oc3fe$7cv$1...@engnews2.Eng.Sun.COM>, lin...@positive.eng.sun.com (Peter van der Linden) wrote:
>Weicong Wang <wei...@caip.rutgers.edu> wrote:
>>Could anyone give me more information about MS AFC and netscape IFC? I
>>think that IFC is little buggy while AFC has more bugs. But which we
>>should use?
>
>Since much of IFC is going into the AWT for JDK 1.2, IFC is the one
>to use.
Except that Microsoft has announced that they're not going to ship JFC with
any of their products. So the world gets to split into the "applets that work
with Netscape and Sun browsers vs applets that work with Microsoft browsers"
camps, or every user gets to figure out how to download and install the GUI
class library for the "other" browser. Lovely.
--
Matt Landau mla...@ziplink.net
Waiting for a flash of enlightenment in all this blood and thunder.
Bryan Althaus
James P. White (j...@pagesmiths.com) wrote:
: Matt Landau wrote:
: >
: > >Weicong Wang <wei...@caip.rutgers.edu> wrote:
: > >>Could anyone give me more information about MS AFC and netscape IFC? I
: > >>think that IFC is little buggy while AFC has more bugs. But which we
: > >>should use?
: > >
: > >Since much of IFC is going into the AWT for JDK 1.2, IFC is the one
: > >to use.
: Sun's position is "We cannot in good conscience recommend using IFC in
: preparation for JFC. Either use AWT or wait for JFC."
: > Except that Microsoft has announced that they're not going to ship JFC with
: > any of their products. So the world gets to split into the "applets that work
: > with Netscape and Sun browsers vs applets that work with Microsoft browsers"
: > camps, or every user gets to figure out how to download and install the GUI
: > class library for the "other" browser. Lovely.
: Well, that is not an exception. It is another reason to use IFC since
: it is *far* better than AFC is already shipped with Navigator 4. AFC is
: at least 4 to 6 months from being competitive with IFC. If they put AFC
: in IE 4, then AFC is going to suffer because it will not be nearly
: complete.
:
: But the point is well made that Microsoft may not fully support JDK 1.2,
: and especially JFC.
From what I understand, that would break the licensing agreement with
Javasoft for the JDK which Microsoft has signed. MS must support all
API's that ship with the JDK.
James P. White
Yes it would, and MS is already saying they will break it by not
supporting JNI in JDK 1.1. I expect that reality will force a new
contract more like WIP, which Microsoft and Netscape just signed with
W3C for HTML (& HTTP?), within the next year or so. From all signs (and
domestic and international votes), the only people happy with Sun's
stewardship of Java is Sun.
Carl Laurence Gonsalves
In article <5oc3fe$7cv$1...@engnews2.Eng.Sun.COM>,
Peter van der Linden <lin...@positive.eng.sun.com> wrote:
>Weicong Wang <wei...@caip.rutgers.edu> wrote:
>>Could anyone give me more information about MS AFC and netscape IFC? I
>>think that IFC is little buggy while AFC has more bugs. But which we
>>should use?
>
>Since much of IFC is going into the AWT for JDK 1.2, IFC is the one
>to use.
That would be JFC, not IFC. While JFC is related to IFC, it's not going to
be compatible with IFC. (Netscape has stated that they will provide some
sort of "migration tools" to convert IFC code into JFC code)
--
Carl Laurence Gonsalves | "Any sufficiently advanced technology is
clgo...@kami.com | indistinguishable from magic."
| -Arthur C. Clarke
http://www.undergrad.math.uwaterloo.ca/~clgonsal/
eng...@quiknet.com
I believe that JFC will become part of the JDK. If that is the case and
Microsoft decides not to ship with JFC then they are in violation of the
contract with Javasoft or Sun.
Anyways, if they decide not to ship with JFC then they are not standard.
If this is the case then this is a good reason to boycott their
technology.
Matt Landau wrote:
>
> In article <5oc3fe$7cv$1...@engnews2.Eng.Sun.COM>, lin...@positive.eng.sun.com (Peter van der Linden) wrote:
> >Weicong Wang <wei...@caip.rutgers.edu> wrote:
> >>Could anyone give me more information about MS AFC and netscape IFC? I
> >>think that IFC is little buggy while AFC has more bugs. But which we
> >>should use?
> >
> >Since much of IFC is going into the AWT for JDK 1.2, IFC is the one
> >to use.
>
> Except that Microsoft has announced that they're not going to ship JFC with
> any of their products. So the world gets to split into the "applets that work
> with Netscape and Sun browsers vs applets that work with Microsoft browsers"
> camps, or every user gets to figure out how to download and install the GUI
> class library for the "other" browser. Lovely.
>
M Thornton Optrak
In article <5oc3fe$7cv$1...@engnews2.Eng.Sun.COM>,
lin...@positive.eng.sun.com (Peter van der Linden) wrote:
> Since much of IFC is going into the AWT for JDK 1.2, IFC is the one
> to use.
Unless of course you expect most of your users to be running MS IE. In
which case, judging by current comments, the dilemma remains. Currently it
seems that AFC may work with most JVMs but it is unclear whether JFC will
work with the MS JVM.
Btw slagging off MS (or Sun) is not a useful response to this dilemma ---
it may make you feel better, but doesn't help our decision.
Mark Thornton
Peter van der Linden
M Thornton Optrak <mth...@cix.compulink.co.uk> wrote:
>Btw slagging off MS (or Sun) is not a useful response to this dilemma ---
>it may make you feel better, but doesn't help our decision.
Since the entire text of my response to the original question was this...
> Since much of IFC is going into the AWT for JDK 1.2, IFC is the one
> to use.
... I have no idea what your criticism refers to.
--
Peter van der Linden
Java Programmer's FAQ ---> http://www.best.com/~pvdl
You can't run a superconducting supercollider without smashing a few atoms.
D'Arcy Smith
Matt Landau wrote:
> >Since much of IFC is going into the AWT for JDK 1.2, IFC is the one
> >to use.
> Except that Microsoft has announced that they're not going to ship JFC with
> any of their products.
How on earth can they attemp to justify that?
..darcy
--
D'Arcy Smith
Symantec, Internet Tools
Check out http://cafe.symantec.com for JDK 1.1 for:
- Cafe 1.53 Prerelease 4
- Visual Cafe 1.1 Prerelease 1
- Visual Cafe Pro 1.1 Prerelease 1
Matt Landau
In article <33B0B5FC...@itools.symantec.com>, D'Arcy Smith <d...@itools.symantec.com> wrote:
>Matt Landau wrote:
>
>> >Since much of IFC is going into the AWT for JDK 1.2, IFC is the one
>> >to use.
>
>> Except that Microsoft has announced that they're not going to ship JFC with
>> any of their products.
>
>How on earth can they attemp to justify that?
Long story, some of which I've picked up in extended email conversation
with various Microsoft folks.
The bottom line seems to be that Microsoft is feeling very threatened, feels
that Javasoft and Netscape are trying to railroad the industry, that JFC came
out as a direct response to the AFC announcement (which I don't think I
believe -- I think it came out because AWT has too many well-known flaws to
survive ... but the timing of the announcements was certainly interesting...),
that they cannot as a company allow Sun to dictate what they ship, that
they have to protect their own business interests and investments, etc. etc.
etc.
Some parts of their reasoning seem sound to me, others less so.
D'Arcy Smith
Matt Landau wrote:
>
> In article <33B0B5FC...@itools.symantec.com>, D'Arcy Smith <d...@itools.symantec.com> wrote:
> >Matt Landau wrote:
> >> Except that Microsoft has announced that they're not going to ship JFC with
> >> any of their products.
> >How on earth can they attemp to justify that?
> Long story, some of which I've picked up in extended email conversation
> with various Microsoft folks.
> The bottom line seems to be that Microsoft is feeling very threatened, feels
> that Javasoft and Netscape are trying to railroad the industry, that JFC came
> out as a direct response to the AFC announcement
Which came out as a direct result of the IFC... :-)
Which came out because the AWT bites.
> (which I don't think I
> believe -- I think it came out because AWT has too many well-known flaws to
> survive ... but the timing of the announcements was certainly interesting...),
> that they cannot as a company allow Sun to dictate what they ship, that
> they have to protect their own business interests and investments, etc. etc.
> etc.
Then they shouldn't have signed a license :-)
Reality is a point of view
[note: followup set, as there is little talk of code and much of politics]
+---- nospam-...@ziplink.net wrote (Wed, 25 Jun 97 13:31:05 GMT):
| The bottom line seems to be that Microsoft is feeling very threatened, feels
| that Javasoft and Netscape are trying to railroad the industry, that JFC came
| out as a direct response to the AFC announcement (which I don't think I
| believe -- I think it came out because AWT has too many well-known flaws to
| survive ... but the timing of the announcements was certainly interesting...),
| that they cannot as a company allow Sun to dictate what they ship, that
| they have to protect their own business interests and investments, etc. etc.
| etc.
|
| Some parts of their reasoning seem sound to me, others less so.
+----
It is sound reasoning. Others have applied it to Microsoft in
the past.
In concert with an attack on 100% Java, a split on GUI common
classes would strike a damaging blow to one of Java's
strengths. Such a split benefits those that benefit from
platform specific code. So it shouldn't be much of a surprise
to find a major OS vendor trying to split development.
--
Gary Johnson gjoh...@season.com
Privacy on the net is still illegal.
James P. White
Reality is a point of view wrote:
> In concert with an attack on 100% Java, a split on GUI common
> classes would strike a damaging blow to one of Java's
> strengths. Such a split benefits those that benefit from
> platform specific code. So it shouldn't be much of a surprise
> to find a major OS vendor trying to split development.
The AFC/JFC/IFC/Bongo/SubArctic et al GUI split is *not* a damaging blow
to anything. All of them (except for JFC) are 100% Pure Java and will
all interoperate at the level of AWT and of Java Beans.
The fact that each of them represents around 1MB of classes *is*
significant, but is in no way special because of being GUI libraries.
The next generation of Java software, which is the generation that
fulfills Java's promise, will depend extensively on many large
libraries/beans/components and resources that are supplied by many
parties. These large bodies of bytes will need to be distributed in a
timely and safe manner for the applications to be widely useful to the
100's of millions of machines that will run them.
This can only be accomplished with automated distribution of signed file
collections. Attempting to do that "the old fashioned way" is just like
trying to push a wet noodle up hill. Or, for the more dramatically
minded, like trying to put out a forest fire with a garden hose.
Once the realization arrives about the nature of a computing and
business environment that is truly built on software component, it will
be readily apparent that the whole AFC vs JFC "battle" is a non-event.
While one good GUI may (or may not) eventually come to be dominant, I
don't believe it will have much to do with what Sun and Microsoft are
doing this year. (Of course it may, since I may be a little optimistic
in expecting Netcaster/Castanet/Microsoft channels (I saw the name the
yesterday but I forgot it again) to be widely available next year - but
then if that can't happen then how can JDK 1.2 be widely available...)
Pham, Vu
Matt Landau <nospam-...@ziplink.net> wrote in article
<5or6dg$asl$1...@kayrad.ziplink.net>...
> In article <33B0B5FC...@itools.symantec.com>, D'Arcy Smith
<d...@itools.symantec.com> wrote:
> >Matt Landau wrote:
> >
> >> >to use.
> >
with
> >> any of their products.
> >
> >How on earth can they attemp to justify that?
>
> Long story, some of which I've picked up in extended email conversation
> with various Microsoft folks.
>
feels
> that Javasoft and Netscape are trying to railroad the industry, that JFC
came
> out as a direct response to the AFC announcement (which I don't think I
> believe -- I think it came out because AWT has too many well-known flaws
to
> survive ... but the timing of the announcements was certainly
interesting...),
> that they cannot as a company allow Sun to dictate what they ship, that
> they have to protect their own business interests and investments, etc.
etc.
> etc.
>
> Some parts of their reasoning seem sound to me, others less so.
>
> Matt Landau mla...@ziplink.net
>
> Waiting for a flash of enlightenment in all this blood and thunder.
>
house in the world would not want their "vision" to be the world's
standard,
or dictate the world's direction. It's business and it's war. The one who
has
the best product that will win market share, win the battle. It's as
simple as that.
MS and SUN can compete to give out foundation classes, but at the end,
the
developers will ultimately decide.
"There is a reason why LISP is not used to write numerical simulation!"
Regards.
VP
--
Remove the two underscore _'s for correct e-mail address
<_vap...@uottawa.ca>
Jay Jayaprasad
M Thornton Optrak wrote:
> In article <5oc3fe$7cv$1...@engnews2.Eng.Sun.COM>,
> lin...@positive.eng.sun.com (Peter van der Linden) wrote:
>
> > Since much of IFC is going into the AWT for JDK 1.2, IFC is the one
> > to use.
> Unless of course you expect most of your users to be running MS IE. In
>
> which case, judging by current comments, the dilemma remains.
> Currently it
> seems that AFC may work with most JVMs but it is unclear whether JFC
> will
> work with the MS JVM.
Actually, I don't see why JFC will not run in the Microsoft VM as it
is100% pure Java and built on light weight components that are part of
JDK 1.1.
From all I've heard from Microsoft, they will support light weight
components
in their VM.
> Btw slagging off MS (or Sun) is not a useful response to this dilemma
> ---
> it may make you feel better, but doesn't help our decision.
>
> Mark Thornton
Jay Jayaprasad
SPSS Inc
Reality is a point of view
[note: followup set to the nonCode newsgroup]
+---- j...@pagesmiths.com wrote (Wed, 25 Jun 1997 23:06:23 -0700):
| The AFC/JFC/IFC/Bongo/SubArctic et al GUI split is *not* a damaging blow
| to anything. All of them (except for JFC) are 100% Pure Java and will
| all interoperate at the level of AWT and of Java Beans.
Yeah, and there are plenty of libraries for X too!
| The fact that each of them represents around 1MB of classes *is*
| significant, but is in no way special because of being GUI libraries.
+----
Had much experience with version control? The development
confusion around 1.0.x vs 1.1.x is just a small taste. Right
now applet developers are stuck with less than optimal
libraries. If the major browsers split then the applet
developers acquire more special casing headaches.
One of the major benefits of Java is a standard GUI target
across platforms. If that benefit doesn't stabilize sometime
soon then it will be lost. Don't except Microsoft to help.
James P. White
Jay Jayaprasad wrote:
>
> M Thornton Optrak wrote:
>
> > In article <5oc3fe$7cv$1...@engnews2.Eng.Sun.COM>,
> > lin...@positive.eng.sun.com (Peter van der Linden) wrote:
> >
> > > Since much of IFC is going into the AWT for JDK 1.2, IFC is the one
> > > to use.
> > Unless of course you expect most of your users to be running MS IE. In
> >
> > which case, judging by current comments, the dilemma remains.
> > Currently it
> > seems that AFC may work with most JVMs but it is unclear whether JFC
> > will
> > work with the MS JVM.
>
> Actually, I don't see why JFC will not run in the Microsoft VM as it
> is100% pure Java and built on light weight components that are part of
> JDK 1.1.
> From all I've heard from Microsoft, they will support light weight
> components
> in their VM.
No, JFC represents many changes at the AWT level. Only SwingSet, which
is a very small subset of JFC, will be 100% Pure Java. In order for the
Microsoft VM to run JFC applications, they will have to choose to
implement the AWT changes that will come in JDK 1.2.
Felix Grabmeyer
Hello,
> Anyways, if they decide not to ship with JFC then they are not standard.
> If this is the case then this is a good reason to boycott their
> technology.
just a simple question: What about the abilities provided by AFC / IFC?
I'm interested in how easy it is to create a not too slow, solid
plattform-independet application in java. If AFC should turn out
to be better (I didn't try any of both), then I'd forget IFC -
and vice versa.
If AFC is really 100% pure java, then all classes can be down-
loaded by your browser, so you've not to migrate to something
declared to be a kind of standard by someone at SUN, Netscape
or elsewhere.
Isn't platform-independence the big step forward, that made us
all move to java? So - why do Netscape & Co, start shipping
non-100%-java-tools? When will the Mac users, the users of
Windows 3.1, and other non-Sun-supported plattforms be able
to use these classes? In fact: If you use something very dependent
on the VM used, you will lose platform independence.
What's your opinion?
Greetings,
Felix Grabmeyer
Ray David Whitmer
Felix Grabmeyer wrote:
> Isn't platform-independence the big step forward, that made us
> all move to java? So - why do Netscape & Co, start shipping
> non-100%-java-tools? When will the Mac users, the users of
> Windows 3.1, and other non-Sun-supported plattforms be able
> to use these classes? In fact: If you use something very dependent
> on the VM used, you will lose platform independence.
Exactly. The move to lightweight components allows the components to be
based more upon 100% pure Java and less upon the idiosyncracies of the
platform's implementation of peers. AFC and IFC are designed to be
1.02-compatible, and as such, they are more dependant upon the VM (or
the native implementation of the peers distributed with a particular VM)
because 1.02 lacks lightweight components.
As for Netscape & Co., their committment to Java remains to be seen.
The platforms will have to be raised beyond the 1.02 level to use the
pure Java features. This is up to Microsoft, Apple, IBM, Netscape,
etc.how quickly they are willing to comply with the standards. As
enough move with the standards, those who do not will be at a
disadvantage. Either the platforms are supported by committed vendors
or they are not. Those significant platforms which are not, are open
markets for new entries.
It is true of any system that as it fails to keep up with real
standards, it becomes less compatible with the systems which are
advancing with the standards to try to build a solid portable
foundation. I.e., I would never successfully call my program or
platform more-platform-independant because it failed to move beyond a
particular Windows/Posix/Motif/HTML/etc. 1.0 standard, which lacked
important features forcing programs to rely on proprietary conventions.
Ray Whitmer
Peter Eddy
This is a multi-part message in MIME format.
--------------AC8CA1ED294B95338BD47A01
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
James P. White wrote:
>
> Reality is a point of view wrote:
> > In concert with an attack on 100% Java, a split on GUI common
> > classes would strike a damaging blow to one of Java's
> > strengths. Such a split benefits those that benefit from
> > platform specific code. So it shouldn't be much of a surprise
> > to find a major OS vendor trying to split development.
>
> The AFC/JFC/IFC/Bongo/SubArctic et al GUI split is *not* a damaging
> blow
> to anything. All of them (except for JFC) are 100% Pure Java and will
> all interoperate at the level of AWT and of Java Beans.
Sure, the AFC is 100% pure now, but you can bet it won't stay that way.
That's 100% Microsoft.
Peter
--
Home Page: http://www.ziplink.net/~petere/fcs.html
--------------AC8CA1ED294B95338BD47A01
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Peter Eddy
Content-Disposition: attachment; filename="vcard.vcf"
begin: vcard
fn: Peter Eddy
n: Eddy;Peter
org: Folding Chair Software
email;internet: pet...@bigfoot.com
title: Contractor
x-mozilla-cpt: ;0
x-mozilla-html: TRUE
end: vcard
--------------AC8CA1ED294B95338BD47A01--
Jeff Dinkins
James P. White wrote:
>
> All of them (except for JFC) are 100% Pure Java and will
> all interoperate at the level of AWT and of Java Beans.
Actually, the Swing part of JFC (the component set: Buttons, Scrollbars,
TreeViews, Listboxes, ComboBoxes, InternalFrames, etc) are all pure java,
and run on 1.1.2 on up.
The parts of JFC that will require some native code (and will be shipping
later as a result): Drag & Drop, Java2D, custom cursor support.
jeff
Swing Engineer,
JavaSoft
--
--
je...@eng.sun.com - http://java.sun.com/people/jeff
"Whether the chicken crossed the road or the road crossed the
Jeff Dinkins
James P. White
Jeff Dinkins wrote:
>
> James P. White wrote:
> >
> > All of them (except for JFC) are 100% Pure Java and will
> > all interoperate at the level of AWT and of Java Beans.
>
> Actually, the Swing part of JFC (the component set: Buttons, Scrollbars,
> TreeViews, Listboxes, ComboBoxes, InternalFrames, etc) are all pure java,
> and run on 1.1.2 on up.
Yes, that is so, sort of.
For IFC, AFC, Bongo, and SubArctic, 100% Pure Java means Java 1.0. For
SwingSet, 100% Pure Java means Java 1.1 and especially meaning AWT 1.1.
As was emphasized at this morning's JFC conference call, no browser
(except HotJava) supports AWT 1.1 - and those will not ship until 4Q97
(previews in another month or two).
Those browsers which support AWT 1.1, and therefore SwingSet, won't
begin to make a dent in the installed base until 2Q98. Few developers
will have the luxury of saying that they cannot deploy on IE 3 or NN 3
during 98. I still deal with customers who have thousands of NN 2.02
installed and are *still* debating when, and with which company and
version, to upgrade to.
Richard L. Ahrens
In article <33C33BF9...@pagesmiths.com>, "James P. White" <j...@pagesmiths.com> wrote:
>Jeff Dinkins wrote:
>> Actually, the Swing part of JFC (the component set: Buttons, Scrollbars,
>> TreeViews, Listboxes, ComboBoxes, InternalFrames, etc) are all pure java,
>> and run on 1.1.2 on up.
>
>Yes, that is so, sort of.
>
>For IFC, AFC, Bongo, and SubArctic, 100% Pure Java means Java 1.0. For
>SwingSet, 100% Pure Java means Java 1.1 and especially meaning AWT 1.1.
>As was emphasized at this morning's JFC conference call, no browser
>(except HotJava) supports AWT 1.1 - and those will not ship until 4Q97
>(previews in another month or two).
>
>Those browsers which support AWT 1.1, and therefore SwingSet, won't
>begin to make a dent in the installed base until 2Q98. Few developers
>will have the luxury of saying that they cannot deploy on IE 3 or NN 3
>during 98. I still deal with customers who have thousands of NN 2.02
>installed and are *still* debating when, and with which company and
>version, to upgrade to.
You're ignoring development of Java *applications*. At our shop we are
much more interested in deploying standalone Java applications outside the
browser. We'll be able to ship a VM of choice with our install, which
allows us to guarantee access to any and all classes we'll need.
Now, while we're on the topic of SwingSet.... I've used both IFC and
SwingSet. Supposedly, SwingSet was based on IFC code. If that's the case,
why is IFC so FAST, and SwingSet so SLOW????? (I of course realize that
SwingSet is in beta.)
--
Richard Ahrens | phone 212.285.1500
Avesta Technologies, Inc. | fax 212.285.1551
2 Rector St. | email rah...@avestatech.com
New York, NY 10006 | web http://www.avestatech.com/
Werner Punz
rah...@avestatech.com (Richard L. Ahrens) wrote:
>Now, while we're on the topic of SwingSet.... I've used both IFC and
>SwingSet. Supposedly, SwingSet was based on IFC code. If that's the case,
>why is IFC so FAST, and SwingSet so SLOW????? (I of course realize that
>SwingSet is in beta.)
>
Got an e-mail regarding this topic from someone from Javasoft and he
said. That they wanted to get the API out first but the improvement of
the SwingSet speed is really high on their priority list.
I personally think that the biggest time consumer is the redirection
of the paint calls due to the pluggable look and feel and maybe a slow
low level painting of lines geometrical shapes and bitmaps.And maybe
the 2d API will bring a speed improvement either)(Actually I had the
impression that the slowest components were those which had a lot of
painting going on) The funny thing is I ran the whole stuff with and
without a JIT (Symantec from Cafe1.45 pr4) and there was besides
occasional crashes with the JIT almost no visible speed difference.
Werner
---
mailto://we...@inflab.uni-linz.ac.at
http://witiko.ifs.uni-linz.ac.at/~werpu/
FOR A REPLY PLEASE REMOVE THE NOSPAM FROM MY E-MAIL
ADDRESS.
Werner Punz
Jay Jayaprasad <j...@spss.com> wrote:
>M Thornton Optrak wrote:
>
>> In article <5oc3fe$7cv$1...@engnews2.Eng.Sun.COM>,
>> lin...@positive.eng.sun.com (Peter van der Linden) wrote:
>>
>> > Since much of IFC is going into the AWT for JDK 1.2, IFC is the one
>> > to use.
>> Unless of course you expect most of your users to be running MS IE. In
>>
>> which case, judging by current comments, the dilemma remains.
>> Currently it
>> seems that AFC may work with most JVMs but it is unclear whether JFC
>> will
>> work with the MS JVM.
>
>Actually, I don't see why JFC will not run in the Microsoft VM as it
>is100% pure Java and built on light weight components that are part of
>JDK 1.1.
>From all I've heard from Microsoft, they will support light weight
>components
>in their VM.
Wrong only the beta swing components will plug into JDK1.1 the full
JFC won't because it'll use drag and drop and several parts of the 2d
API. So it's up to M$ to reprogram the 2d API to the the RNI. If they
do it plugging the stuff into it afterwards shouldn't be a problem if
not then thei'll loose the java branding on the Internet Explorer
(maybe they loose it because of not supporting the JFC? Who knows what
Sun decides)
L.J. Jin
> >Actually, I don't see why JFC will not run in the Microsoft VM as it
> >is100% pure Java and built on light weight components that are part of
> >JDK 1.1.
> >From all I've heard from Microsoft, they will support light weight
> >components
> >in their VM.
> Wrong only the beta swing components will plug into JDK1.1 the full
> JFC won't because it'll use drag and drop and several parts of the 2d
> API. So it's up to M$ to reprogram the 2d API to the the RNI. If they
> do it plugging the stuff into it afterwards shouldn't be a problem if
> not then thei'll loose the java branding on the Internet Explorer
> (maybe they loose it because of not supporting the JFC? Who knows what
> Sun decides)
>
> Werner
I tried Swing 0.2 examples with IE3.02 + MS JDK 2.0 beta, which does
support the delegation model and lightweight components. However, only a
couple of the simplest examples would run, and not a chance with the
SwingSet sample.
--L.J.
Jeff Dinkins
we...@inflab.uni-linz.ac.atNOSPAM (Werner Punz) writes:
>
>I personally think that the biggest time consumer is the redirection
>of the paint calls due to the pluggable look and feel
Actually, a big part of the slowdown is that is that repaint
rects are being unioned rather un-intelligently. To check this
out, turn off double buffering in SwingSet (set true to false on
line 146, comment out the setBuffered(true) line on 738). Run
SwingSet, and go to the Slider tab. Note how a HUGE region is
being repainted each time you slide the slider.
We're also adding dirty regions, which appears to be speeding things
up quite nicely. So far, in just 1 day's investigation, we appear
to be seeing a 2.7x speedup already.
jeff
--
--
Jeff Dinkins
Swing Team http://java.sun.com/products/jfc
JavaSoft, a division of Sun Microsystems, Inc.
James P. White
Richard L. Ahrens wrote:
>
> In article <33C33BF9...@pagesmiths.com>, "James P. White" <j...@pagesmiths.com> wrote:
> >Those browsers which support AWT 1.1, and therefore SwingSet, won't
> >begin to make a dent in the installed base until 2Q98. Few developers
> >will have the luxury of saying that they cannot deploy on IE 3 or NN 3
> >during 98. I still deal with customers who have thousands of NN 2.02
> >installed and are *still* debating when, and with which company and
> >version, to upgrade to.
>
> You're ignoring development of Java *applications*. At our shop we are
> much more interested in deploying standalone Java applications outside the
> browser. We'll be able to ship a VM of choice with our install, which
> allows us to guarantee access to any and all classes we'll need.
I was not ignoring JFC's use in applications, but those who promote JFC
as something that is not a full year behind IFC do ignore applets. I am
fairly certain that the fact that JFC does not work for applets is a
significant deficiency when compared to the other GUI libraries. I
think that my situation is fairly typical of Internet developers in that
we deploy as an applet, an application, and as a Castanet channel. Even
for those developers that do not specifically plan applet deployment,
being precluded from deploying or creating an applet will usually be
considered a negative. This is an important issue to keep in mind
during all the "AFC vs JFC" and "IFC vs JFC" arguments.
Werner Punz
"L.J. Jin" <lan...@qsii.com> wrote:
>
>I tried Swing 0.2 examples with IE3.02 + MS JDK 2.0 beta, which does
>support the delegation model and lightweight components. However, only a
>couple of the simplest examples would run, and not a chance with the
>SwingSet sample.
>
In fact the Swing stuff is pretty critical it even crashed the
Symantec JIT ocasionally (pr5 of cafe). I had more troubles getting my
own 500KB delegation event model app to run on the JDK2.0 Beta than
on the symantec PR1 of Cafe no wonder this stuff won't run on the MS
VM currently.
Werner Punz
"James P. White" <j...@pagesmiths.com> wrote:
>I was not ignoring JFC's use in applications, but those who promote JFC
>as something that is not a full year behind IFC do ignore applets. I am
>fairly certain that the fact that JFC does not work for applets is a
>significant deficiency when compared to the other GUI libraries. I
>think that my situation is fairly typical of Internet developers in that
It is, however IMHO the designers had to make a clear choice of
designing only lots of controls which run in applets or make a clear
designed application framework which will use several of the proposed
JDK1.2 features to get the necessary performance. If you have to rely
on applets then you definitely can't rely on JDK1.1 at all for the
next one til two years. IMHO the future of Java doesn't lie in Applets
anyway. Applications are the future.
Werner
we...@inflab.uni-linz.ac.at REMOVE NOSPAM BEFORE REPLYING
http://witiko.ifs.uni-linz.ac.at
check out ftp://ftp.gmd.de/if-archive for something which has
been forgotten years ago.
Werner Punz
Werner Punz
we...@inflab.uni-linz.ac.atNOSPAM (Werner Punz) wrote:
>In fact the Swing stuff is pretty critical it even crashed the
>Symantec JIT ocasionally (pr5 of cafe). I had more troubles getting my
>own 500KB delegation event model app to run on the JDK2.0 Beta than
>on the symantec PR1 of Cafe no wonder this stuff won't run on the MS
>VM currently.
Oops I made a mistake I meant the SDK2.0 beta not the JDK. Sorry folks
Matt Landau
In article <33C51F69...@pagesmiths.com>, "James P. White"
>I was not ignoring JFC's use in applications, but those who promote JFC
>as something that is not a full year behind IFC do ignore applets. I am
>fairly certain that the fact that JFC does not work for applets is a
>significant deficiency when compared to the other GUI libraries.
AFC doesn't work for applets either; it also requires the Java 1.1 event
model, and so is subject to exactly the same limitations as JFC.