If you're inexperienced in the microprocessor/microcontroller programming field, you should probably learn C first, so that you can understand when and why Java is a poor choice for most microcontroller projects.
Did you read the restrictions on the JVM you linked? It includes the following problems:
- As little as 512 bytes of program memory (not KB, and definitely not MB)
- As little as 768 bytes of RAM (where your variables go. You're limited to 768 characters of strings by this restriction.)
- About 20k Java opcodes per second on 8 Mhz AVR.
- Only includes java.lang.Object, java.lang.System, java.io.PrintStream, java.lang.StringBuffer, a JVM control class, and a native IO class. You will not be able to do an import java.util.*; and get all the classes not in this list.
If you're not familiar with what these restrictions mean, make sure that you have a plan B if it turns out that you can't actually do the project with Java due to the space and speed restrictions.
If you still want to go with Java, perhaps because you expect the device to be programmed by a lot of people who only know Java, I'd strongly suggest getting bigger hardware, likely something that runs embedded Linux. See this page from Oracle for some specs to shoot for to run the embedded JVM, in the FAQ of their discussion they recommend a minimum of 32MB of RAM and 32MB of Flash. That's about 32,000 times the RAM and 1,0000 times the Flash of the AVR you're looking at. Oracle's Java Embedded Intro page goes into more detail about the restrictions of the JVM. Their tone of voice is, as you might guess, a good deal more Java-friendly than mine. Be aware that this kind of hardware is much more difficult to design than an 8-bit AVR.
I'm a computer engineering student with a computer science minor. My university's CS department has drunk the Java Kool-aid, so a lot of students in the engineering program come in knowing only Java (which is a sad state of affairs for a programmer, at least learn some Python or C++ if you don't want to learn C...), so one of my professors published a C Cheat Sheet (Wayback machine link) for students with a year of Java experience. It's only 75 pages; I suggest you read or skim it before making a decision. In my opinion, C is the most efficient, durable, and professional language in which to develop an embedded project.
Another alternative to consider is the Arduino framework. It uses a stripped down version of the Wiring language, which is like C++ without objects or headers. It can run on many AVR chips, it's definitely not restricted to their hardware. It will give you an easier learning curve than just jumping straight into C.
In conclusion,
Alt text: Took me five tries to find the right one, but I managed to salvage our night out--if not the boat--in the end.
The serial flow control signals (DTR and/or RTS) must be set accordingly to the Arduino specification and to the specification of USB-SERIAL adapter you're using.
Looking briefly at the schematic of your board, I can see that the RTS signal is disconnected, but DTR signal from FTDI chip is coupled with the ATMEGA's RESET pin (I imagine that this is done to allow Arduino uploader to reset the micro and upload new firmware to it).
This means that you have to set DTR signal (in your Java code) to avoid unwanted resets.
Best Answer
There are com-port libraries available for java.
RXTX seems to be one of the most prominent.
Here is a long discussion about how to use RXTX and an alternative, called JavaComm.
Here is a question on StackExchange asking essentially exactly what you are asking.
Note: I'm assuming you want to write a java application to do what you describe (otherwise, why would the application being java-based be relevant?)
If not, please update your question.
Edit:
If you're in control of the USB-serial converter, you could use the jD2XX library, which wraps the FTDI D2XX driver API.
This is an excellent API, but it will only work with FTDI usb-serial converters.