Develop Reference

Bootable program

I'm a front end developer that's looking to get into some other languages such as Java or C++. I have an idea for a program and was just looking for an answer to something. What I would like to do is build a program and boot directly to that program. For example I have an old computer and I wipe the hard drive clean. So they is nothing currently on it. Not even an OS. I want to build a program that I can install to the hard drive that will boot straight into the program once started. Would this be considered an OS?

No you don't. Unless you want to spend many years, writing drivers for your graphics card, harddisk controller, usb controller, dma controller and all the other hardware your computer have.
What you want is a minimal operation system, which include just the kernel, and a runtime library and which start your program and nothing else on startup. A minimal Linux such as linux from scratch or bsd would be a good starting point.

First of all you need to decide your your program needs what. I mean should operate in Protected mode or the routine you have is tiny, so it is enough to run before entering protected mode (i.e. in real mode).
Here you can do three things
Modify bootloader to jump the execution to your code . Then Your code can resume normal os initialization.
Modify your os kernel early initialization code So that it executes your code before entering protected mode
I think your code will not be harmed if a bit of os portion is running. So you can write your routine before full kernel initialization.
Now note that for the later two point you need to modify your kernel, which is not easy (not even always possible)
Now the problem in first approach: Nothing will be ready for you, not even a regular c library or divice drivers , so you have to write every raw bit of code by hand which is crude.
This is off course not possible in java. Because the jvm will not be ready for you.
Now practically: there are lot of tiny os available, use one of them and modify as per your need. use this link to get a complete list of what is available for you.

First, Java is right out. You cannot possibly do this in Java without enormous amounts of tool-building. Java is not suited for this task at all.
You can do it in C++ or C. The search terms you are looking for is operating system development. This would probably not technically be considered developing an Operating System since it wouldn't run other programs, but the information about how to get through the boot-up procedure and establish a minimal environment are going to be most easily found in the category of operating system development. Some reasonable starting resources for that can be found at the OS Dev Wiki.
Alternately, you could take an existing small open-source OS and modify what it does after the boot-up sequence completes. If your program is intending to do anything more than just use the keyboard and the screen in text mode, there need to be device drivers. Thus, depending on the project, changing an existing OS may be the easiest route because you won't need to write your own device drivers for any devices you want to use.

Java can't run without Environment. If you want to run you program on you machine without OS, Java is a wrong choice.
C++ program can run without OS, but it's difficult to write a bootable program in C++.
If you want to write your own bootable program, you should use assembly for boot and load function, with some knowledge to use hardware in low level.

You have to have an operating system, so your program would be the operating system (or you would have to use another one and write it for that). It's certainly possible in C++, but it's not really possible to write an operating system in java.

Unless you want write something in (for example) Open Firmware and Forth or say a ROM BASIC. You'll probably qualify as a boot loader. Your application may qualify as an operating system. In my opinion, and a modern context, it entirely depends on how much functionality it provides to hosted applications. I'm not sure that something like FreeDOS would be considered an operating system (no pre-emptive task scheduling or GUI for example) given modern computers (I don't care to argue the point either way).

What to consider when writing a java program that is supposed to run 'forever'

I have to write a program that is thought to run 'forever' , meaning that it won't terminate regularly. Up until now I always wrote programs that would run and be terminated at the end of the day. The program has to do some synchronizations, pause for n minutes and than sync again.
AFAIK there should be no problem with my current implementation and it should theoretically run just fine, but I'm lacking any real-world experience.
So are there any 'patterns' or best practices for writing very robust and resource efficient java programs that have a very long runtime? What could be possible problems after for example a month/year of runtime?
Some background :
Java : 1.7 but compiled down to 1.5
OS : Windows (exact version is not certain yet)
Thanks in advance

Just a brain dump of all the things I've had to keep in mind when writing this kind of app.
Avoid Memory Leaks
I had an app that runs once at mid day, every day, and in that I had a FileWriter. I wasn't closing that properly, and then we started wondering why our virtual machine was going into melt down after a few weeks. Memory leaks can come in the form of anyhing really, with one of the most common examples being that you don't de-reference an object appropriately. For example, using a class's field as a method of temporary storage. Often the class persists, and so does the reference. This leaves you with objects, sitting in memory and doing nothing.
Use the right kind of Scheduler
I used a java Timer in that app, and later I learnt that it's better to use a ScheduledThreadPoolExecutor when another app was changing the System clock. So if you plan on keeping it completely Java based, I would strongly recommend using that over a Timer for all of the reasons detailed in this question.
Be mindful of memory usage and your environment
If your app is loading large amounts of data each and every day, and you have other apps running on the same server, you may want to be careful about the timing. For example, say at mid day, three of the apps run their scheduled operation, I would say running it at any other time would probably be a smart move. Be mindful of the environment in which you're executing your code in.
Error handling
You probably want to configure your app to let you know if something has gone wrong, without the app breaking down. If it's running at a certain time every few hours, that means people are probably depending on it, so I would have a function in your Java code that sends out an email to you, detailing the nature of the exception.
Make it configurable
Again, if it needs to run at various points in the day, you don't want to have to pull the thing down for a few hours to work out some minor changes to your code. Instead, port it into a java Properties file, or into an XML Config (or really, whatever). The advantage of this is that you can update your program and get it up and running before anyone really noticed the difference.
Be afraid of the static keyword
That bad boy will make objects persist, even when you destroy their parent reference. It is the mother of all memory leaks if you are not careful with it. It's fine for constants, and things that you know don't need to change and need to exist within the project to run well, but if you're using it for random values inside a project, you're going to quickly wonder why your app is crashing every few hours rather than syncing.
Props to #X86 for reminding me of that one.

Memory leaks are likely to be the biggest problem. Ensure that there are no long-term references held after an iteration of your logic. Even a relatively small object being referenced forever, will exhaust the memory eventually (and worse, it's going to be harder to detect during testing if the growth rate is 1GB/month). One approach that may help is using the snapshot functionality of profilers: take a snapshot during the pause, let the sync run a few times, and take another snapshot. Comparing these should show the delta between the synchronizations, which should hopefully be zero.
Cache maintenance is another issue. The overall size of a cache needs to be strictly limited (whereas often you can get away without in short-running programs, because everything seen will be small enough to not cause problems). Equally it's more important to do cache-invalidation properly - broadly speaking, everything that gets cached will become stale at some point while your program is still running, and you need to be able to detect this and take appropriate action. This can be tricky depending on where the golden source of the cached data is.
The last thing I'll mention is exception-handling. For short-running processes, it's often enough to simply let the process die when an exception is encountered, so the issue can be dealt with, and the app rerun. With a long-running process you'll likely need to be more defensive than this. Consider running parts of your program in threads, which can be restarted* if/when they fail. You may need a supervisor-type module, which checks that everything else is still heartbeating and reboots it if not. If appropriate to your structure, this is anecdotally a lot easier to achieve with actors-style libraries rather than Java's standard executors. And if it's at all possible, you may want to have hooks (perhaps exposed over JMX/MBeans) that let you modify the behaviour somewhat, to allow a short-term hack/workaround to be affected without having to bring the process down. Though this requires quite some amount of foresight to predict exactly what's going to go wrong in several months...
*or rather, the job can be restarted in another thread

How can I prevent my Java program from lagging while other applications are running?

I wrote a simple code in Java that uses the Robot class to move the mouse according to some conditions.
Although the code works nicely, there seems to be a 'lag' when other applications are running.
I think Java has some issues posting system messages.
Is there a workaround to avoid this?

Before you start thinking about reducing the lag, you must first understand it's causes. I'll present the answer(s) in a fashion in which you can understand the "why" along with the "what to do".
By your description that the lag only occurs when other programs are running along with your robot, the most likely causes for the lag are:
Lack of system resources - Too many things running at the same time, consuming too much memory/processing-power, thus making the OS slow-down some programs in order to be able to run the others.
What to do: To try to fix such issues, you can try to optimize your code, to make it use less memory/processing power, thus reducing the cause of the lag, with implicitly reduces the lag itself. Unfortunetly tough, it's hard to legally do the same for any 3rd party programs, so the lag can hardly be completely removed if the concurrent applications are not yours.
Concurrency regarding a non-replicable, non-shareable component - One or more components that cannot be accessed by more than one process at a time and that cannot be cloned into multiple instances needs to be used by more than one process that is running. While one process takes control of it, any other processes have no choice but wait for the component to be freed.
What to do: In this case, there hardly is any legal method other than to reduce the concurrent process's priority while increasing your's (effectively slowing them down in order for your program to run faster), or shut them down completely.
How to do: To increase your process's priority, this is the code to set it at 80% (default is usually 50%), inset at your main():
Thread.currentThread().setPriority((int)(Thread.MAX_PRIORITY*0.8));
Note: You can set your process to "never" let go of whatever components it needs, using Thread.MAX_PRIORITY without multiplying by 0.8, but that is unrecommended, as it will pretty much pause any process that requires the components (quasi-same to shutting them down while yours is running), and if your program hangs, for whatever reason, so will those, as the components are never released.

Java Crashing Windows

I have been developing a Java application using J2EE and a Derby database. My boss does most of the testing and I do most of the coding, but he has come to me with a strange problem. He claims that occasionally the Java application "crashes his computer".
To mention a few details, first let me say that I am currently working remotely, so I can't be around when these "crashes" happen. Second, I use OS X 10.6 and he uses Windows XP (SP3 I believe). The Java application in question does not use any JNI or anything weird except for an embedded Derby database. Lastly, he said it freezes everything in Windows (his mouse doesn't even move) -- it doesn't show up in the console like an uncaught exception would.
So, is it possible that my Java program is crashing his computer? I didn't think that Java code could have any system-wide effects outside of the JVM. Is this something that could possibly be the fault of my program, or should I just ignore it and attribute it to some problem with his computer?

For a Java application to crash the OS it runs on, there must be a bug in the JVM. That said there are situations that can give the same impression:
the Java application can grow its heap far enough that the OS starts to swap and other applications appear to slow down to a halt
the Java application can grab all CPU by one or more threads in a tight busy loop
If you can setup your testers' machine so that a heap dump can be triggered when the problem occurs, you can analyse that dump remotely. For instance with IBM's Java heap analyzer found on alphaworks.

There were cases before of crashes under windows on IBM Thinkpads (and other machines I am sure) due to a bad graphics driver. I'd suggest doing the usual thing of making sure the drivers are up to date just to be on the safe side.
While your code may not use JNI directly a lot of what happens under the hood can (anything that integrates with the underlying OS essentially). Which means drivers can be a big problem.
The other thing would to be sure that the most recent version of the Java is being used (if 1.6_17 isn't possible at last the latest version of the version of Java being used).
One other thing that has fixed random crashes for me is to re-seat the memory (unplug it and plug it back in).

he said it freezes everything in Windows (his mouse doesn't even move)
A user-mode application — whether Java or otherwise — can't do that against a modern OS like WinNT.
He either has a hardware problem, or a bad driver.

To crash the entire computer, try this:
public void crashComputer() {
while(true)
new Thread(new Runnable() {
#Override
public void run() {
while(true) {
crashComputer();
}
}
}).start();
}
public void crashJVM() {
while(true)
crashJVM();
}
The crashComputer function takes about 2 seconds to crash the entire computer. You can stop it from crashing by holding power button.
The crashJVM function crashed only the JVM by overloading the stack, causing a stack overflow (That's where the name of this website comes from).
WARNING: Use at your own risk. This will not damage your computer, but I'm not taking the blame if you forget to click save on a document or something.

Also check the page file space on the client (Windows/XP) system.

Point one: On my XP, SP3 system, when any program runs full tilt, it almost locks up the computer. When my anti-virus program checks for updates, everything else stops for all practical purposes, and it uses very little CPU (seems to be writing to disk all the time). My own infinite loops, using 100% CPU, have a similar effect. (Why the task manager does not get priority over a user program with "normal" priority I do not know.)
Point two: On any computer I've ever used, heavy paging will bring a program to an almost complete stop.
So start with an XP computer with 512Mb of real memory and 2000Mb of virtual memory. Write a Java program with 1400Mb worth of arrays and other data structures. Put in a loop that repeats several billion times and reads or writes to each byte in that 1400Mb on each execution. This program will not finish until long after the universe collapses in on itself. The computer will do nothing. I have not tried this and I do not intend to, but I will bet anything even the mouse won't move. Depending on the make of the computer, the only fix may be pulling the power plug out of the wall socket. (Note that technically, the computer has not crashed. Indeed, it is working just fine. But you are going to need to be patient. Move the mouse the day before you plan to click.)
The moral of this story is to avoid both XP and virtual memory, but if you have to deal with either, be aware of these problems.

unresponsive java application for no reason

I have a java application that I run from eclipse 3.5.
My OS is WinXP(SP2) and the JRE version is 6.05.
I run the application on two identical computers (or so I think) but the application behaves differently on each computer.
The computers are the same Dell Optiplex model with the same amount of memory and have the same GPU.
On the first computer, the application runs flawlessly. However, on the second one the application freezes for a couple of minutes and then returns to run normally.
The strange thing is that the CPU usage on the second computer is not high at all. It seems as though my application does not receive any CPU for no apparent reason.
Computers should be deterministic so I assume there must be some difference between the machines but I don't know where to look.
I would love some ideas on where the problem might be.
Thanks,
Yoav.

I've found the problem.
The application that was unresponsive was run in debug mode.
Sorry to have wasted your time...

It may help you to get a Thread Dump when the app freezes. This will hopefully tell you exactly what is holding you up (i.e. waiting for IO somewhere).

Well, I would first update your JRE version as there are newer versions now.
As for both computers being identical, are they really identical? I find it difficult to believe that both have the same exact software and setup and that anything you have done to one, you have always done to the other. If this is indeed the case, you may want to try to debug your application on the second machine (the one that hangs) and find out specifically where it hangs.
It may also help us if you give more information about your application. The problem may not be your computer at all if the application is doing things like web access, network access, etc.

So both computers have nearly identical hardware. A few other things to check
Do they both have Eclipse 3.5, WinXP(SP2) and JRE 6.05 installed?
And behave differently when run from within Eclipse (on both machines or on one run from command-line)?
Is this reproducible? If yes When does it happen? On startup? Or on some specific action?
Does the program have a GUI?
Is there maybe some kind of virus scanner or another comparable software installed on one of the machines which could delay the program
Is networking, file acccess, multithreading involved?

I can think of two non-application possibilities:
Memory Paging. There's something extra happening on the slow machine, so your JVM is not getting a fair share of CPU time. A large daemon process or some such.
Network access. Your app is making some kind of network call and it's glitching or timeing out. Perhaps going and fetching some XML schema, perhaps a disk acesss to a mounted drive.
I've seen all manner of weirdness when apps attempt to access hosts by name and DNS is not well. One machine has an etc/host entry the other does not. Even each machine might want to resolve itself.