Here is the way to wrap external console-executable stuff.
private Process Process = null;
String command = "ping google.com";
Runtime r = Runtime.getRuntime();
Process = r.exec(command);
BufferedInputStream = new BufferedInputStream(Process.getInputStream());// bytes from the process
BufferedOutputStream = new BufferedOutputStream(Process .getOutputStream());// bytes to the process
...
Process.destroy();
System.out.println("------------------> Process killed.");
http://java.sun.com/developer/technicalArticles/WebServices/jaxb/

package rebecca.e.remote;
import java.io.ByteArrayInputStream;
import java.io.ByteArrayOutputStream;
import java.io.InputStream;
import java.io.OutputStream;
import javax.xml.bind.JAXBContext;
import javax.xml.bind.JAXBException;
import javax.xml.bind.Marshaller;
import javax.xml.bind.Unmarshaller;
public class XMLMarshal {
public Object UnMurshall(String xml, String packageName)
throws JAXBException {
JAXBContext jc = JAXBContext.newInstance(packageName);
Unmarshaller u = jc.createUnmarshaller();
InputStream is = new ByteArrayInputStream(xml.getBytes());
return u.unmarshal(is);
}
public String Murshall(Object xmlObject, String packageName)
throws JAXBException {
JAXBContext jc = JAXBContext.newInstance(packageName);
Marshaller m = jc.createMarshaller();
m.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, Boolean.TRUE);
ByteArrayOutputStream is = new ByteArrayOutputStream();
m.marshal(xmlObject, is);
return is.toString();
}
}
Steps to creation of an RMI system:
The short version
1) Create an interface. (in this case, the interface is myRMIInterface.java).
2) Create a class that implements the interface. (in this case, myRMIImpl.java).
3) Create a server that creates an instance of this class
4) Create a client that connects to the server object using Naming.lookup()
5) Compile these classes.
6) Run the RMI interface compiler on the .class file of the implementation
class (in this case, you’d say “rmic myRMIImpl”).
7) Start the RMI registry (on Windows NT/95, say “start rmiregistry”).
8) Start the server class (“start java myRMIServer”).
9) Run the client program (“java myRMIClient”).
The long version: http://patriot.net/~tvalesky/easyrmi.html
February 5th, 2009 in
How-To,
Java,
RMI |
No Comments
http://en.wikipedia.org/wiki/Dining_philosophers_problem
http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/locks/ReentrantLock.html
A reentrant mutual exclusion Lock with the same basic
behavior and semantics as the implicit monitor lock accessed using
synchronized methods and statements, but with extended
capabilities.
A ReentrantLock is owned by the thread last
successfully locking, but not yet unlocking it. A thread invoking
lock will return, successfully acquiring the lock, when
the lock is not owned by another thread. The method will return
immediately if the current thread already owns the lock. This can
be checked using methods isHeldByCurrentThread(), and getHoldCount().
The constructor for this class accepts an optional
fairness parameter. When set true, under
contention, locks favor granting access to the longest-waiting
thread. Otherwise this lock does not guarantee any particular
access order. Programs using fair locks accessed by many threads
may display lower overall throughput (i.e., are slower; often much
slower) than those using the default setting, but have smaller
variances in times to obtain locks and guarantee lack of
starvation. Note however, that fairness of locks does not guarantee
fairness of thread scheduling. Thus, one of many threads using a
fair lock may obtain it multiple times in succession while other
active threads are not progressing and not currently holding the
lock.
Also note that the untimed tryLock method does not
honor the fairness setting. It will succeed if the lock
is available even if other threads are waiting.
It is recommended practice to always immediately
follow a call to lock with a try block, most
typically in a before/after construction such as:
class X {
private final ReentrantLock lock = new ReentrantLock();
// ...
public void m() {
lock.lock(); // block until condition holds
try {
// ... method body
} finally {
lock.unlock()
}
}
}
http://unimod.sourceforge.net/
UniMod states for Unified Modeling. Long term project goal is to create unified methodology for application development process that will close the gap between Design and Development phases.
Currently, UniMod project is focused on designing and implementing applications behavior. Already implemented approach adapts SWITCH-technology for UML notation. SWITCH-technology is also known as Automata-based Programming and has it’s own Russian site http://is.ifmo.ru/english/.
SWITCH-technology suggests to model application behavior with a help of Structural Finite State Machine (FSM). Structural FSM is defined as set of Abstract FSMs and scheme of Abstract FSMs interconnections.
Eclipse plugin:
http://unimod.sourceforge.net/eclipse-plugin.html
January 20th, 2009 in
Java,
eclipse |
No Comments