>Like pascal and basic, there's no particular reason that java programs can't be >compiled all the way to machine code instead of byte codes, is there?=20 There is something of a reason -- java is far richer conceptually than C = for generating native equivalent code.. But it can and has been done. Most = java JVM's have just-in-time technology these days which does this for you transparently. With java you get machine independent source ( java = source ) AND machine independet binary ( class files ) AND machine dependent performance by whatever technology is available to convert the class = files to machine code.. Even for the PIC ( www.muvium.com ) which for those = who attendend 816-MUV at MASTERS this year would have seen how we get 'C' performance from Java.. At least for the PIC. There are an enourmous number of applications written in java but GUI's don't seem to be it's speciality and one of the reasons for this is that Java tends to be a bit more generic.. The reason java is a bit slower is = not because of the runtime performance of the JVM but because the libraries = it uses tend to be designed more generically ie for ease of re-use rather = than for speed optimisation. What I mean is that it is algorithmic rather = than JVM execution speed.=20 In particular GUI's are difficult to match custom code ie say a DirectX engine or something working very tightly with a particular machine configuration with a generic transportable GUI library. For a start = anyone thinking about building a commercial desktop application doesn't first = think 'linux' simply because 90% of the market still uses windows. So if you choose windows then Java probably isn't the best tool for the GUI. Hence the result is pretty obvious -- commercial desktop applications = tend to get written for the Windows platform using whichever windows tool = suits it best. Java GUI app's tend to be smaller utility applications that are more transportable. Not because java is not a good language or it's slow = or something like this -- simply because it's about using the appropriate = tool for the appropriate job. It's not that Java is not a good tool for building applications -- = Eclipse for example is a very good tool for all sorts of things -- = www.eclipse.org -- but yes it tends to focus on development but it's plugin = extensibility for example is a very good reason to use java. In fact again if you = attended 816-MUV you would have used Eclipse to run emulated PIC hardware and = write java applications for the PIC all running from the muvium java plugin = for eclipse which puts our development kit integrated in the Elcipse = environment for debugging and launching emulated and real hardware. Plus because = it's java this IDE can run on linux too -- so suddenly you hava a real development environment for the PIC that runs on Linux or whatever else = runs Java and Eclipse ( just about everything ) D.Jay Newman wrote: >This is a *huge* application. It has seven modules that the students >can create simulated experiments and see the results and match them=20 >up against similar data from real experiments.=20 This is a hint of one very powerful reason to use java and we take = advatage of this in our tools. Where Java running on your PC is the same as the = Java running on say a PIC so you can use your PC to emulate and debug your = Java programs. We have tools ( from www.virtualbreadboard.com ) to wrap up = this in a real-time framework ( called openVBB -- java ) which allow us to develop and run real-time emulations of whole electronic systems and integrate them with real-time systems under control via java adaptors -- = eg robots can be a system under control. Like Jay's system we are working = with a University project and demonstrated this year a system for RoboCup Jnr where the development environment is a java soccer match physics = emulation running java robots driven by muvium powered PIC's running the exact = same java robot code in the emulator as the real-robot allowing emulated to = match up with the real. This for example allows in this case for the = real-robot to be developed for or evalulated 'offline' or by students who don't own a real-robot and then to put the code in the real-thing for 'competition' = day. Other applications could be for you to send your customer a software evaluation of your hardware for say user interface sign-off or = functional specification agreement or perhaps you want to get started developing = before you complete the hardware so you did with 'Virtual Hardware' -- we call = this VWARE.. Or you don't have all the parts yet but you want to evaluate different designs.. Well I could keep going..=20 So.. Java has its uses ;-) Regards, James Caska www.muvium.com uVM - 'Java Bred for Embedded' -----Original Message----- From: pic microcontroller discussion list = [mailto:PICLIST@MITVMA.MIT.EDU] On Behalf Of William Chops Westfield Sent: Saturday, August 07, 2004 3:35 PM To: PICLIST@MITVMA.MIT.EDU Subject: Re: [PIC] php for PICs ? On Aug 7, 2004, at 7:20 AM, Gerhard Fiedler wrote: > the GNOME desktop environment, StarOffice productivity suite, Mozilla=20 > browser, Evolution mail and calendar client, and Java 2 Platform=20 > Standard Edition." > > Not much of that seems to be written in Java :) > My impression was that recent versions of staroffice and mozilla = contained quite a bit of Java code, in their bid for more platform-independence. Wasn't that one of the things leading to complains of slowness? Like pascal and basic, there's no particular reason that java programs = can't be compiled all the way to machine code instead of byte codes, is there? Machine-independent binaries are nice, but for major applications they aren't nearly as important as machine-independent source code... BillW -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email listserv@mitvma.mit.edu with SET PICList DIGEST in the body -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email listserv@mitvma.mit.edu with SET PICList DIGEST in the body