Parallel port programming in Java

[karthik]

Hi,

I need to do parallel port programming in one of my Java applications.
The requirement is that I need to write a byte very frequently to the
port triggered by some events, which will be used by an Event
Acquisition hardware hooked onto this parallel port. I went through
the javax.comm documentation for doing this. I found that it was
treating the port as if a printer was connected to the port. I don't
know how to use this package to my requirements. If some one has some
sample code it would be great.

Also, I've thought about few alternatives. I am thinking of using JNI
to do this. I'll have all the parallel port access routines in a C
routine and I can call this from my Java module using JNI. Else, as an
alternate choice, I can use sockets to communicate with these C
routines instead of JNI, if JNI is not the right choice. I am not sure
which one would be better. If one of you can direct me onto a right
track I would greatly appreciate it.

So, if you could let me know which is better: javax.comm or TCP/IP or
JNI ti would be great!

TIA,
karthik

 

[Sudsy]

Hi,

Also, I've thought about few alternatives. I am thinking of using JNI
to do this. I'll have all the parallel port access routines in a C
routine and I can call this from my Java module using JNI. Else, as an
alternate choice, I can use sockets to communicate with these C
routines instead of JNI, if JNI is not the right choice. I am not sure
which one would be better. If one of you can direct me onto a right
track I would greatly appreciate it.

So, if you could let me know which is better: javax.comm or TCP/IP or
JNI ti would be great!

This is the perfect justification for using JNI. You've already
got the code written in C and it does exactly what you want. Why
try to reinvent the it in Java?
In a similar vein, why try to rewrite a fully functional CICS
application in J2EE/Java? Just use the CICS connector and let
each element do what it does best.

 

[Dale King]

javax.comm for parallell ports is *USELESS*
i'm using JNI and i'm quite happy.
ciao

You know, I'm pretty fed up with Sun on the whole Java Comm API. The
whole thing is pretty much useless. The stupid properties files is
totally unnecessary.

They have not touched it since JDK1.2. Any feedback falls on deaf ears. I
think someone needs to take up the ball and become the new defacto
standard since Sun refuses to lead or get out of the way. RXTX may be the
place to start on such a new standard.

 

[Marco Parmeggiani]

You know, I'm pretty fed up with Sun on the whole Java Comm API. The
whole thing is pretty much useless. The stupid properties files is
totally unnecessary.

well, with serial support i'm satisfied but usb support sometimes would
be useful...

They have not touched it since JDK1.2. Any feedback falls on deaf ears. I

i've posted a RFE to Sun, look at the response and try to follow the
link they provide to monitor the bug in the bugparade...

ciao


----------------------> start <-----------------------------------

To: (e-mail address removed)
Subject: Re: (Review ID: 182203) RFE: Parallel port support is too
limited
From: Ranjith Mandala <[email protected]>
Date: Thu, 6 Mar 2003 10:23:07 -0800 (PST)
Cc: (e-mail address removed)

Hi Marco Parmeggiani,

Thank you for using our bug submit page.

We have determined that this report is a new bug and entered the bug
into our
internal bug tracking system under Bug Id: 4828433.

You can monitor this bug and look for related issues on The Java
Developer
Connection Bug Parade at:
http://developer.java.sun.com/developer/bugParade/bugs/4828433.html

It may take a day or two before your bug shows up in this external
database.
The Java Developer Connection is a free channel that is maintained by
staff
here at Sun. Access this web page to join:
http://developer.java.sun.com/servlet/RegistrationServlet.

The home page for the Java Developer Connection is:
http://java.sun.com/jdc.

Regards,
Ranjith
----------------- Original Bug Report-------------------

category : javax_commapi
release : 2.0
subcategory : win32
type : rfe
synopsis : RFE: Parallel port support is too limited
description : DESCRIPTION OF THE REQUEST :
Parallel port support is limited to only unidirectional communication
(LPT_MODE_SPP).

JUSTIFICATION :
Bidirectional support is a basic feature that should be implemented in
order to have a minumum functionality with parallel ports.

CUSTOMER SUBMITTED WORKAROUND :
Using a custom, wild, non portable and uncontrolled implementation that
does not follow JavaComm specifications.
workaround :
suggested_val :
cust_name : Marco Parmeggiani
cust_email : (e-mail address removed)
jdcid : marcopar
keyword : webbug
company : void
hardware : x86
OSversion : win_xp
bugtraqID : 0
dateCreated : 2003-03-06 07:41:25.6
dateEvaluated : 2003-03-06 11:22:23.28


----------------------> end <-----------------------------------

 

[Dale King]

I don't think the API itself or the property file (which you are not
supposed to touch) is the fundamental problem.

If you've ever tried to use the Comm API from a WebStart app you would
have a different opinion about whether the property file is a problem.

All the property file tells you is what class is the one that you should
load as the implementation of the driver. They have a new standard for
doing that now called Service Provider
(http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Service Provide
r). Basically what the convention says is that property file should go in
the Jar in META-INF/services/javax.comm.CommDriver.

To get around the property file it would be nice if I could manually just
force load the driver and do without the property file. But for some
stupid reason they still require the file to be there after the driver is
loaded. They ask the security manager before any operation whether the
file is readable. To get around it you have to set your own security
manager.

IMHO it is the
reference driver implementation and the documentation as provided by
Sun. The so-called user's guide is one web page with maybe 50 lines of
text :-( One has to study the examples extensively to understand the
principle ideas and architecture of the API.

The API spec has minor problems. E.g. it is only possible to specify
one event listener per port. This is not a showstopper, but it is
annoying.

And it is flaky. I found that to get timely response from the serial port
so it did not timeout even though there was data there, I had to enable
notifyOnDataAvailable even though I was not using notification.

If I remember it correctly, Sun's Solaris reference implementation
still mentiones 1.1.6 ...

The last release was basically when 1.2 was in beta.

RXTX is a JavaComm driver It requires Sun's JavaComm framework
(which is all, but Sun's platform specific drivers from JavaComm), so
what are you complaining about?

My complaint was that we shouldn't be trying to implement the JavaComm
API anymore. The JavaComm API stinks and Sun doesn't care about it. Who
cares about compatibility with it? Forge your own path.

I hadn't checked in on RXTX for a while, They seem to have avtually done
what I am suggesting and said forget the JavaComm API. RXTX 2.1 does not
require the JavaComm API or even implement it.

 

[Dale King]

well, with serial support i'm satisfied but usb support sometimes would
be useful...


i've posted a RFE to Sun, look at the response and try to follow the
link they provide to monitor the bug in the bugparade...

Based on past experience, with Sun's total lack of interest in the
JavaComm API, I wouldn't hold my breath that you will even get a
response.