Re: java-linux, reliabilety
Hi Lukas, I asked this exact question many months ago. I'm pleased to say now that I've found both Linux and Java have been quite reliable for my project. I've currently got RTLinux and Java running in our company's new networkable instrument. All the real time stuff is written in C and runs an I/O card I designed to control the instrument's various hardware bits. All the Linux software (non-real time) stuff is written in Java and it performs all the high level management of the instrument such as networking, LCD panel display, etc. As in you project, the instrument is 'headless', no keyboard or monitor. It's currently in the lab being tested, and any problems we've had so far are related to bugs in my code, not the underlying OS or JDK. It generally doesn't run for more than a day or so before someone turns it off. But during that time it's running one or more network connections, doing real time closed loop temperature control, real time sampling and integration on 70 channels, LCD display updates, button scanning, timing, etc. So it's busy! The schedule was extremely tight for time, and I credit java for allowing me to meet the deadline. It would definitely be possible in C or C++, but I firmly believe that it would have taken longer. And not been as robust given the same amount of time. In fact, there was even enough time to create some extra's like a 'probe' application that can attach to instrument across the network and pick up stack traces for any exceptions that get thrown in the embedded software. In general I'm quite pleased and impressed with the quality of both Linux and the Blackdown JDK. Jim. At 10:31 AM 9/15/98 -0700, Lukas Hazlehurst wrote: >hi, > >This isn't a technical Java question, so feel free to tell me to go away. >I'm at the analysis point of developing some server software. The software >would run on a series of computers distributed around the net. The server >machines themselves would simply be boxes, no screens or keyboard etc. >At this point i am trying to select a development language & a target OS. >My preference is to go with java and linux. >Is java on linux reliable enough to run on a box by itself for a >considerable period of time, or would C be more appropriate ? > >Lukas. >[EMAIL PROTECTED] > > >
FIFO's
I'd like to access FIFO's with Java under Slackware linux 2.0.0. When I try to open a FileInputStream on the fifo file, things just stop. I'm using 1.1.6. I've read that: "An error in the green threads implementation (Solaris). Try running it with native threads (load the native threads add-on and set the environment variable THREADS_FLAG to "native")." This seems to be the case here too. Is there a native threads for linux? Is there a fix or work around? Thanks, Jim.
Re: Survey, what tool do you use?
No nedit users? Jim. At 11:49 PM 6/18/98 -0400, you wrote: >Thanks for all your input. > >I get 17 responses today. Here is a summary: > >Xemacs: 6 >Pico: 3 >vi: 2 >JDE: 2 >Jacob: 2 >Emacs: 2 >WipeOut: 1 >Simplicity: 1 >Cat (!?) : 1 > >I've took out jdk cause I think everyone should be using some kind of jdk. > >Thanks again. > >Sze Yuen. > >P.S. ok. So I think I should give up in finding an IDE. > >
[rtl] Re: Java and rtl (was LabView for Linux)
At 08:38 AM 11/24/98 -0600, Wright, Robert B. wrote: >I would also like to hear about any projects that incorporate java and rtl. Ok, please excuse me if this is a bit long winded :-) I'm currently working on two projects that involve RTLinux and Java. Both involve real time instrument control. One is more deeply embedded than the other. I.e. no monitor, keyboard, just an Ethernet connection. The other actually has a GUI component but is being designed such that the GUI component doesn't have to reside on the instrument doing the acquisition. Both designs use RTLinux and C to handle all the hard real time instrument control as well as the acquisition. Several FIFOs connect this real time layer with the Java code. One FIFO is for commands, one for responses, one for the acquisition data stream. One FIFO is used for error propegation from the real time layer up to the GUI layer. Some fiddling is required to get Java to read data from the FIFO properly. First, the byte order must be switched. Secondly, I found that, on occasion, simply trying to read four bytes from the fifo wouldn't work properly. So I had to counteract with a rather ugly kludge. I've found that connecting the real time layer and the non-real time Java layer in this way isn't very efficient for moving large amounts of data. I'm currently exploring another possibility to improve performance. Both designs use a PC104 interface board that I've designed and built to offload some of the processing overhead. A programmable timer on the board starts a conversion. When the conversion finishes, an interrupt is generated. The ISR (in the real time layer) reads the value, passes it to the data FIFO and switches to the next channel to be serviced. Both designs boot a pared down RTLinux system from an IDE flash disk. They run from memory so the systems can be powered down without concern for any shutdown. Both are running from an Advantech single board computer measuring about 4"x6". These SBCs contain ethernet, video, IDE controller, etc. So the overall system is quite compact. Overall, I'm quite impressed with the combination of RTLinux and Java. This instrument needed to be networked. Using Java, I was able to jam in more than was required in the tight timeline that was available. I've done similar things in C, C++ and strongly believe that it was quicker & simpler to do in Java. Primary to this belief was a) the networking classes, and b) multi-threading. Granted, it's not as fast as had it been written in C or C++. But I'd probably still be writing it had it not been for Java. Originally, one of the projects was started in QNX, but was switched to RTLinux after a period of evaluation. The instrument currently can handle multiple clients. Only one of which can control the instrument. The others being only to interrogate the instrument for things like: current instrument status, time remaining on current job, current owner, etc. Also, it was easy to build debugging into the design. Multiple concurrent debug monitors can attach to the instrument via the network and receive information on the current operation of the program, as well as thrown exceptions and stack traces are reported to any debug monitor programs that might be attached. So if a customer calls and says that the instrument fails randomly once a week, I can attach via the net and monitor for that intermittent failure. One unit has been tested for a while in another department. When I asked about any crashes or failures of the RTLinux system, all I got was blank stares. It has never happened. Also, I can update the software and reboot via the net. When they ask for a change, I do the update, then phone them and ask what version number is reported on the instrument's LCD panel to confirm the update. They find this quite amusing. I find it very convenient, as I'm about 100km from where it's being tested. Hope this was of some interest. Regards, Jim. --- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] For more information on Real-Time Linux see: http://www.rtlinux.org/~rtlinux/
Re: [rtl] Re: Java and rtl (was LabView for Linux)
I've built a couple of scripts to build a tiny RTLinux system from a full system for the flash disk. I can put it on the net if anyone is interested. I've got another to prepair the flash disk and install everything. I've got a desktop system with two IDE interfaces that I use to plug both the IDE and flash drive. I had no success in getting the IDE and FLASH drive to cooperate as master and slave. Putting them on separate controllers worked. This wasn't a problem since the Pentium motherboard had two IDE controllers built-in. I also wrestled with lilo. Little beast wouldn't install on anything but hda. So here's what I ended up doing: - put IDE drive on hda - install Linux, then patch to RTLinux - install application software, Java - move IDE drive to hdc (second controller) - put the FLASH disk on hda - use the install boot disk and instruct it to use hdc as root (mount root=/dev/hdc) The mini-build scripts then mount the flash disk, prepare it, install a compressed root file system, and run lilo. The system is configured to run from ram disk with the flash remounted so it can be used to store persistant information. If the RTLinux community is interested in having this as a FAQ, then I would be glad to prepare a more detailed guide to doing this, with the scripts that I used, and the various config files for lilo, etc. Also, I'm not certain that this would warrent a FAQ, but I could write a little blerb with code fragments on getting Java to read properly from a FIFO. I've got it working, and I'm working on what I hope will be a much faster way. As for paring the JDK down, it can be done but the licence seems to prevent one from pulling parts from it. It can be made smaller if things like the AWT isn't required. Not that I've done this of course, but that's what I've heard :-) I'm currently using a Sandisk 40Mb IDE flash drive. It's much too large for this project and I'm working on a smaller device. Advantech makes an IDE flashdisk about half the size of a credit card. It has an IDE socket on it. It just plugs right onto the IDE header on the SBC. It's perfect for what I want. I've got the 8Mb version and have RTLinux booting from it. To enable it to connect directly onto the motherboard's IDE header, the connector is the mirror image of a regular IDE cable, so I built a small adaptor so I could plug it onto a regular IDE cable and install RTLinux onto it. Advantech is supposed to have at 16Mb version now. The RTLinux system, Java, and all the libs that I need to run it fit into just under 20Mb, so I'm about to look for things to throw overboard to get it down to 16Mb. When the SBC has the small Advantech IDE flash disk installed, you wouldn't even notice that it's there! Regards, Jim. At 03:32 AM 11/18/98 +0200, Nikolay Ognyanov wrote: >Hi James, > >Could you please tell us a bit more about your project? The problem >of putting RT Linux into FLASH has been raised several times on >this list but as far as I can recall you are the first one to present a >real case study. Could you tell more about this : what kind of FLASH >device you use, did you have problems with making Linux boot from >it etc.? Also did you try to reduce in some way Java footprint ? How >big your instalation (including Java) is? > >BTW, does somebody know about Embedded Java more than can be >found on JavaSoft site? Could it have something to do with RT Linux? > >Regards >Nikolay Ognyanov > >
Sun JDK 1.2 Ships....
Of possible interest :-) http://java.sun.com/features/1998/12/jdk.ship.html
JFC on Linux?
Will the JFC work on Linux? Does it need a special port? Jim.
Swing package
Could someone please let me know how to set things up to use the swing classes? I've got things set up to compile java programs ok, but can't get the swing lib to be located. (jdk1.1.6 is located in /usr/local). I've got a copy of swing101.zip, and placed it in various locations with various permutations of the CLASSPATH env var. But I keep getting the message: 'com.sun.java.swing.*' not found when I try to compile a program that imports from it. Thanks for any assistance! Jim.
Slackware 3.5 Segmentation violation woes
Greetings Java-Linux group! I'm hoping someone can help me with this snag: I've been developing an application that runs ok under Slackware 3.4 with jdk1.1.6-v1. When I installed Slackware 3.5 it get a segmentation violation when trying to run the same app. I've upgraded to 1.1.6-v2, but get the same error. Also, I've tried copying /lib/ld.so from the Slackware 3.4 system that works correctly, but it doesn't help. I've created a simple test case that runs fine until I try to create a Socket object, then it blows up as indicated below. Does anyone know of a workaround or fix? Thanks for any help! Jim. SIGSEGV 11* segmentation violation stackbase=0x413aa000, stackpointer=0x413a9e54 Full thread dump: "Thread-4" (TID:0x40648088, sys_thread_t:0x413a9f04, state:R) prio=5 *current thread* java.lang.Runtime.loadLibrary(Runtime.java) java.lang.System.loadLibrary(System.java) java.net.PlainSocketImpl.(PlainSocketImpl.java:67) java.net.ServerSocket.(ServerSocket.java:57) java.net.ServerSocket.(ServerSocket.java:131) java.net.ServerSocket.(ServerSocket.java:83) ConnectionServer.run(ConnectionServer.java:65) "Finalizer thread" (TID:0x40644208, sys_thread_t:0x41388f04, state:R) prio=1"Async Garbage Collector" (TID:0x40644250, sys_thread_t:0x41367f04, state:R) prio=1 "Idle thread" (TID:0x40644298, sys_thread_t:0x41346f04, state:R) prio=0 "Thread-4" (TID:0x40648088, sys_thread_t:0x413a9f04, state:R) prio=5 *current thread* java.lang.Runtime.loadLibrary(Runtime.java) java.lang.System.loadLibrary(System.java) java.net.PlainSocketImpl.(PlainSocketImpl.java:67) java.net.ServerSocket.(ServerSocket.java:57) java.net.ServerSocket.(ServerSocket.java:131) java.net.ServerSocket.(ServerSocket.java:83) ConnectionServer.run(ConnectionServer.java:65) "Finalizer thread" (TID:0x40644208, sys_thread_t:0x41388f04, state:R) prio=1"Async Garbage Collector" (TID:0x40644250, sys_thread_t:0x41367f04, state:R) prio=1 "Idle thread" (TID:0x40644298, sys_thread_t:0x41346f04, state:R) prio=0 "Clock" (TID:0x40644088, sys_thread_t:0x41325f04, state:CW) prio=12 "main" (TID:0x406440b0, sys_thread_t:0x81acf40, state:CW) prio=5 InstrumentMgr.initializeInstrument(InstrumentMgr.java:72) InstrumentMgr.(InstrumentMgr.java:49) InstrumentMgr.main(InstrumentMgr.java:209) Monitor Cache Dump: java.lang.Runtime@1080328536/1080688792: owner "Thread-4" (0x413a9f04, 1 entry) (0x0x81acf40): Waiting to be notified: "main" (0x81acf40) Registered Monitor Dump: "Idle thread" (TID:0x40644298, sys_thread_t:0x41346f04, state:R) prio=0 "Clock" (TID:0x40644088, sys_thread_t:0x41325f04, state:CW) prio=12 "main" (TID:0x406440b0, sys_thread_t:0x81acf40, state:CW) prio=5 InstrumentMgr.initializeInstrument(InstrumentMgr.java:72) InstrumentMgr.(InstrumentMgr.java:49) InstrumentMgr.main(InstrumentMgr.java:209) Monitor Cache Dump: java.lang.Runtime@1080328536/1080688792: owner "Thread-4" (0x413a9f04, 1 entry) (0x0x81acf40): Waiting to be notified: "main" (0x81acf40) Registered Monitor Dump: Thread queue lock: Name and type hash table lock:
Re: linux on laptops
I'm using a Twinhead Slimnote EX266TG with Slackware 3.5. Works perfectly. Two of the things that I needed to consider the system usable was an XGA 1024x768 LCD display and an ethernet PCMCIA card. The display does do this resolution and XFree86 that comes with Slack 3.5 drives it. I've got a USRobotics Megahertz 33.6 Ethernet modem that's recognised without any twiddling. I've used the ethernet part extensively, but haven't tried the modem part. I did have probs with Slackware 3.4 not recognising the modem card, but 3.5 cleared it up. The beast is a bit heavy, but I appreciate the exercise. :-) Regards, Jim. At 10:04 AM 7/29/98 -0700, Richard Dost wrote: >I want to install linux on a yet to be bought notebook. Are there >driver compatibility issues for the ethernet card? Should I make sure >to get/avoid certain ethernet cards? Is there a list of supported >devices somewhere? Am I just conjuring up problems where none exist? >Thanks :) > >
Re: GUI debugger for Java-Linux?
I've used ddd, it works with java (use ddd --jdb to start). Didn't use it a lot, so I can't attest to how well it works. It does have quite a following for it's use in other languages. Check out: http://mumm.ibr.cs.tu-bs.de/softech/ddd/ Regards, Jim. At 12:59 PM 8/3/98 -0400, Rich Edwards wrote: >Does anyone know of any GUI-based debuggers for Java on Linux? I have >tried WipeOut from softwarebuero, which is a front-end to jdb. It's >flaky, at best. Any other debuggers out there? > >Thanks, > >Rich Edwards >Senior Software Engineer >Codonics, Inc. >e-mail: [EMAIL PROTECTED] > >
