Re: Java and NC

david@go5.com (David W Chan) wrote: :Mike Segel <mikey@segel.NOSPAM-.KING.OF.MYDOMAIN.-NOSPAM.com> wrote: : :>Actually, NC's are better for intranet apps than PCs. :>Look at the cost of maintanence of a PC versus an NC. :>By stripping down the PC, you lose configuration problems. :>You lose the hassles of some user modifying his/her OS from 3.11 :>to '95 then demanding support. : :The advantages of NC are well known. But do you see corporates who :have spent millions on PCs dumping them all in favour of NCs? Most of :them here won't. No, but they may replace PCs with NCs as the need arise. Reportadly Java applications does not run all that well on old 486/33 and lower PCs so there may be a significant need for NCs. :>You control software apps from a single point of distribution. : :Bur this only because you have thin clients. Java allows you to build :thin clients for both NCs and PCs. You can't use this argument in :favour of the NC. The thin PC version can also be loaded off the :network. Of course. But: The PCs have to run MS Windows and may therefore still need more management than the NC. I still agree with you. On the other hand Sun have announced a solution to make old PCs into NCs so *may be* the issue will go away (by giving you yet anothre choice). :>VJ++ ? Let me get this straight. You want to take a portable :>language, Java, and add Machine dependant code which makes your :>application less portable? : :No. It is still 100% Java. There is no machine dependant code in it. :The choice you have is that you can produce JVM p-code or Windows EXEs :and they will run happily on both environments. At the moment. the :exe version executes about 10 times faster than the jvm version. VJ++ can create Windows EXEs but in version 1.0 it only added a stub to the file so the JVM was started automatically. It still compiled your Java code to Java byte code and you gained no speed advantage. The only advantage was you could start your Java applications the same way you can start any other Windows application. I can find no reference to any native code generation in the version 1.1 spesifications on the MS web pages. Do you have other information? The only available tool I know of to create native MS Windows code is Asymetrix SuperCede. Others are coming so fast though they may allready be available. Also with native code generation Java application code does run faster (may be not 10 times, but at least significantly faster). As usual however it may not make much of a difference in typical database applications. With new multimedia and other applications it's surely significant. Also although you sure can generate 100% Java applications and applets the key factor is whether you want to rely on Microsoft to keep it this way. The AFC is more at issue here than VJ++. The AFC can so easily be made to run very much better on MS Windows and they can also easily put in grand features that you want to use that will not be made available on other platforms or not execute well on those platforms. I do not see Microsoft as the driving force to make foundation class libraries that work equally well on many platforms. Netscape, IBM, Javasoft and others are much more likely candidates here, so I would sure not put my eggs in the MS basket. Remember if you start using the AFC you will be bound to Microsoft forever unless you rewrite your application at a very fundamental level. VJ++ doesn't support the new JDK 1.1 from Javasoft. Microsofts ambigous position on this issue (making noise in the media about it) is a clear sign of their unwillingness to support Java properly. This non support of JDK 1.1 is devastating. The differences are so greate between 1.0.2 and 1.1 of the JDK you will reportadly have a major rewrite in front of you when you shall upgrade. Eventually you will have to upgrade so I wouldn't use a 1.0.2 tool if I can avoide it. The competiors (Symantec and others) allready have trial releases of their tools for 1.1 and will have final releases soon. According to the Inforworld review available via the MS Web site VJ++ doesn't support JDBC in it's database Wizard. Instead it supports Microsoft spesific (MS Windows only) connectivity via RDO/DAO objects. Although you will be able to use JDBC via direct coding this is to me another indication of Microsofts direction. Taken all togheter: Avoide VJ++ at all costs. The costs aren't high though :-). There are other better tools available. :>Hello? Am I the only one who thinks that this is strange? : :I wouldn't go as far as to say it is strange. I would say it is :unfortunate. : :>The biggest feature of Java is that it is machine independant. :>This way, when I write an app, it will run on any machine. Which means :>I can then buy the hardware best suited to my needs. : :I disagree. The biggest feature of Java is that it allows you to :produce thin applications. But if an organisation has lots of PCs, :there are lots of advantages in producing an exe version for them to :use. When you get NCs, you can then compile a jvm version as well. Agreed. Thin clients means multi tiered applications. With all the tools now available it looks like it will be reasonably simple to create such applications. A key issue is also that these tools are priced right. Java have finaly made this type of software development available to the masses. We no longer need to go to Forte, SAP ABAP, C based CORBA, traditional TP monitors or similar tools with exorbitant prices to do it. With Java and Java interfaces all the way through applications and tools it's also going to be a much simpler world, although it will surely have its great pitfalls and problems. By not having machine independanse as your top priority you also elegently avoide the current problems with incompatibilities between machines. Nils.Myklebust@idg.no NM Data AS, P.O.Box 9090 Gronland, N-0133 Oslo, Norway My opinions are those of my company The Informix FAQ is at http://www.iiug.org