Netscape IFC @ JavaOne

Jim White
Netscape DevEdge Champion for IFC

So far there are no sessions or BOF meetings on IFC. I will be working to get something together so that we can get discussion and clarification on the IFC to JFC transition tools and support story.

I would like to meet with as many IFC users as possible, and will arrange a time at the Netscape DevEdge booth if nothing else.

I am planning to demonstrate the IFC wrapper classes for JFC (JIFC) I am developing (plenty to do yet but it looks quite promising). A very large open issue is how this library will get distributed (the big question being who will have to pay and how much).

Watch this page during JavaOne for the latest information on when and where you can contact me (use your reload button if necessary). I will also check my mail from time-to-time: jim@pagesmiths.com.

For more IFC information, see my IFC page: www.pagesmiths.com/ifc.html.

In addition to the IFC newsgroup, you may also want to keep an eye on my "under construction" page: www.pagesmiths.com/RSN.html.

Tuesday, March 24, 1998

Spent the day at the show and got to talk to a number of people.  Especially noteworthy is IBM's Visual Properties & Actions (VPA), which is in early beta and will be available as part of the Visual Age (VA) package.  VPA needs work on their approach to persistence, but it is an extremely effective GUI resource-oriented (factory classes actually) builder which works with JFC components.

Prospects of a meeting don't seem high since I've not heard from very many of you IFC folks.  I suspect the late notice and that I didn't send to a broader audience (most IFC users don't frequent the IFC newsgroup).  I will be at the Netscape booth often, so leave a message there (or email me) if you would like to arrange a meeting.  I also plan to set up the JIFC demo in the Netscape booth tomorrow.
   

Wednesday, March 25, 1998

A very productive day!  I met with Scott Ryder <ryder@lighthouse.eng.sun.com> and had a very positive discussion about their plans for IFC to JFC transition support and future versions of Constructor.  If you are an IFC user interested in moving an application to JFC, I suggest you let him know who you are (let me know also so I can add you to my list).

I set up the JIFC work-in-progress demo in the Netscape booth and showed it to Scott, as well as other IFC users: Makoto Nagata of Bank of America, Helen Yuen of AT&T, and Martin Vetter of the German National Research Center for IT.  Interestingly, all three of them have been using IFC for more than a year to develop applications in advanced R&D labs for their respective organizations.  I think it is quite important that Javasoft help speed the transition of all you leading edge developers from IFC to JFC so that the rest of the Java community can benefit from your significant knowledge and experience in creating sophisticated Java GUI applications.

For all you IFC users who will be at JavaOne on Friday, I would like you to come to the JFC/Swing BOF at 12:15p.  I think you may have valuable feedback for the JFC/Swing team and then we can meet informally afterward.
  

Thursday, March 26, 1998

While it is clear that for many (most) applications and developers (particularly those who adopted IFC very early), JFC is a necessary next step (and one to be made sooner rather than later).  On the other hand, it is also clear that IFC has a number of virtues which JFC lacks (100% Pure Java 1.0, very fast, distributed with Communicator).  The issue of performance (both speed and size) is important when developing and deploying applications throughout the world (really everywhere).  Being Java 1.0 is important for ensuring the greatest level of compatibility amongst all the various JVM implementations.  As a consequence, there will continue to be developers and applications using IFC in certain situations.

SlangSoft <www.slangsoft.com> is another GUI package which shares those qualities with IFC.  SlangSoft produces a SDK and an application suite that provide support for 41 national languages and, like IFC, is pure Java 1.0, small, and fast.  The combination of SlangSoft and IFC is ideal for producing high quality applications with excellent tools that can run on all of today's (and tomorrow's) Java platforms.  Another benefit of using IFC for applications with SlangSoft is that Constructor's plan files are inherently designed for internationalization without modifying or compiling Java code.  IFC also has built-in (but undocumented, other than the source) support for locales and bitmapped fonts (supplied as GIF files).

Other news is the problem of running JFC/Swing with Communicator.  Apparently the Swing/JFC team thinks that it is Netscape's problem that Swing fails to run in the applet security sandbox.  I have had my own related problems in developing the IFC wrappers for JFC which reveal shortcomings in Swing's approach to applet security.  IFC clearly demonstrates that everything Swing/JFC needs to do can be done in the sandbox.  Clearly it is important that the applet security sandbox not be comprimised for a library such as Swing, as that would only introduce insidious opportunities for nasty hacks.  Hopefully, by transitioning more of the IFC technology to JFC, these problems will get ironed out before Swing is finalized for Java 1.2.  Longer term, I am fairly confident IFC technology can also be used to cure a big chunk of JFC's slowness.