java-native / jssc

Java library for talking to serial ports (with added build support for maven, cmake, MSVC)

A small, single Java library for working with serial ports across various systems based on the work from scream3r/java-simple-serial-connector.

Usage

• Download .jar manually or add using maven

<dependency>
    <groupId>io.github.java-native</groupId>
    <artifactId>jssc</artifactId>
    <version>2.9.6</version>
</dependency>

• or Gradle (KTS)

repositories {
    mavenCentral()
}
dependencies {
    implementation("io.github.java-native:jssc:2.9.6")
}

• or Gradle (Groovy)

repositories {
    mavenCentral()
}
dependencies {
    implementation 'io.github.java-native:jssc:2.9.6'
}

• API code examples

Support

• Report a bug or request a feature

Developers

• Compile this project from source
• Chat on Discord

jssc's Issues

Apple Silicon Support

Placeholder to support the new aarch64 Apple M1 CPU. Note, Intel Macs can cross-compile for aarch64, but any unit tests will require a physical ARM64 Mac.

Cross compilation will generate wrong artifact classifiers

Cross compilation on linux_amd64 will still create an archive with that classifier (instead of arm_32 or so).

NoClassDefFoundError after updating from 2.9.1 to 2.9.2

Hi
After updating from 2.9.1 to 2.9.2 this exception showed up:

Exception in thread "main" java.lang.NoClassDefFoundError: org/scijava/nativelib/NativeLoader
	at jssc.SerialNativeInterface.<clinit>(SerialNativeInterface.java:88)
	at jssc.SerialPortList.<clinit>(SerialPortList.java:43)
	at main(Main.java:38)
Caused by: java.lang.ClassNotFoundException: org.scijava.nativelib.NativeLoader
	at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	... 3 more

Note: I'm adding .jar manually without Maven

Enable javac compiler warnings

Enable javac compiler warnings.

Configure the maven-compiler-plugin:

      <plugin>
        <artifactId>maven-compiler-plugin</artifactId>
        <configuration>
          <compilerArgument>-Xlint:all</compilerArgument>
          <showWarnings>true</showWarnings>
          <showDeprecation>true</showDeprecation>
        </configuration>
      </plugin>

cross compiled armhf binary will not work

cross compiled armhf and armsf binaries won't load (i.e. UnsatisfiedLinkError).
If I compile on my raspberry pi (using -DskipTests because of #24), loading the library will just run fine.

I also set the toolchain to armv6 (instead of 5). Need to test native compilation with softfloat and 5 and combinations.

Choose a build system

@bmhm has been very helpful in giving us some examples on how to create a JNI project with Maven with a working proof-of-concept here: https://github.com/bmhm/native-example

• Decide if the project use Maven, Gradle or something else
  • Note, some early work for Maven support is available in 2.8.1-experimental branch, authored kindly by @vogt31337
• Decide if we keep cmake or do we leverage Maven's native build capabilities directly
  • // edit by @bmhm: As discussed, we stick to cmake because of MacOS builds

Note, the temporarily cmake branch has a boilerplate for native and cross-compiling. This will be merged back into mainline once the above decisions are made.

Further TODO for the maven-cmake-branch:

• move the java parts to src/main/java
• restructure into submodules, so there can be multiple build jobs (one for each platform).
• find and replace hardcoded occurrences of linux_64.
• ask @tresf or @woodrowbarlow how to fix that UnsatisfiedLinkError in my previous comment.

Port wiki examples

When @scream3r converted the original project, the wiki articles never made it over.
We should at least provide basic usage examples.

https://code.google.com/archive/p/java-simple-serial-connector/wikis/jSSC_examples.wiki

Native compilation for armhf fails

if you execute
mvn clean install

on an raspberry pi, the compilation fails.
Reason: The libjssc.so will be put into the linux_32 directory.

It should be in linux_arm instead.

Thats a problem of the current native-lib-loader convention. The new one will fix this issue automagically.

Workaround: -DskipTests=true

Default release type

@woodrowbarlow:

• Any objections to make default release type Release? This should ensure no matter which platform we build on, we have a consistent binary.
• Do we need to manually call strip on our binaries? If so, can you please add it to the cmake branch? Make sure to disable it for Debug builds.

Javadocs for sendBreak() should indicate units for duration value

I figured out it was milliseconds by looking at the code, but it would be good to document it.

Wayne

Requirements for maven central deployment

https://central.sonatype.org/pages/requirements.html

• Correct Coordinates (tracked in #5
• Signing keys
• Project Name, Description and URL
• License Information #22
• Developer Information
• SCM information
• distributionManagement tag.
• add the sonatype plugin
• Create a release profile
• Take notes from https://github.com/acegi/acegi-standard-project about the GPG Key etc.

These needs to be added to the pom.xml.

Setting up the release profile

The release profile should include:

• javadoc
• java-sources
• signing

We can take a peek at projects like https://github.com/glowroot/glowroot/blob/12afc32250c96e25fa9e738fc997805b9529c368/pom.xml how they manage and implement the distribution management.

How to deploy

 # snapshot deployment
mvn clean deploy

# release deployment
mvn versions:set -DnewVersion=1.2.3
mvn clean deploy -P release

Requirements for Deployments

• Having an account at sonatype
  https://issues.sonatype.org/secure/Signup!default.jspa
• Having a GPG keypair

Create a dependency-bundled jar

Request to create an additional non-shaded, standalone jar for our downloads area.

• This can have namespace clashes, classpath issues, these issues exist for other projects too (such as PDFBOX using BouncyCastle, etc)
• This will result in two separate "fat" jars. The "uber" jar, which is maven-friendly, and the "release" jar which is available on our GitHub project page for download.

---

Original bug report:

Trying to run java-simple-serial-connector-2.8.1-SNAPSHOT.jar inside a project causes the following exception:

Caused by: java.lang.NoClassDefFoundError: org/scijava/nativelib/NativeLibraryUtil
	at jssc.SerialNativeInterface.<clinit>(SerialNativeInterface.java:81)
	at jssc.SerialPortList.<clinit>(SerialPortList.java:43)

I consider this a bug. Previous versions of JSSC did not have this issue.

Differentiate between ARM hardware floating point and software

"hf" and "sf" are suffix abbreviations that represent CPU capabilities on ARM devices.

JSSC 2.8.0 had this distinction and supported loading the right one. It uses some tricks for this, including the readelf binary, which isn't necessarily available on all platforms by default. Here's the code:

https://github.com/java-native/jssc/blob/v2.8.0/src/java/jssc/SerialNativeInterface.java#L118-L135

This functionality was removed with the master branch due to native-lib-loader library not having the same distinction capabilities.

We are investigating two options:

• IDEAL: Ship one binary to handle both hardware capabilities. Is this possible?
• BACKUP PLAN: Ship two binaries and use a patched native-lib-loader to fix this. (see @bmhm's upstream PR: scijava/native-lib-loader#32)

Related #26

Make master default branch

Currently, 2.8.0 is the default branch. I propose we rename this to master and archive off the other branches.

• Existing master will be migrated to a 2.7.0 tag instead.
• Existing 2.8.1-experimental can be deleted in favor of #4. It would remain on the original scream3r repo if anything is needed.
• cmake is a temporary feature branch and will be deleted once merged.

Zero ports list

Testing 3.0.0-SNAPSHOT, zero ports are listing. It appears to be a regression with the addition of java-native-loader. We accidentally killed some platform detection logic.

Better waitEvents implementation for *nix-like systems

jssc/src/cpp/_nix_based/jssc.cpp

Line 716 in 0d0e6f7

* Collecting data for EventListener class (Linux have no implementation of "WaitCommEvent" function from Windows)

So, this line mentions that there's no analogue for WaitCommEvent from WinApi. However, isn't that what poll/epoll/select functions are for? My concern is that for me using this library on Linux causes a memory leak and garbage collection around every 30 seconds (with default flags) when the app is just idle, and I don't think there's a good reason for that.

On Windows this behaviour is not present, of course. Now, I have zero experience with C++ code, so I probably shouldn't try to make a PR with critical code, but could someone take a look at it? Here's the example on SO of using poll on serial port and it's very close to what jSerialComm does:

JNIEXPORT jint JNICALL Java_com_fazecast_jSerialComm_SerialPort_waitForEvent(JNIEnv *env, jobject obj, jlong serialPortFD)
{
	// Initialize the waiting set
	if (serialPortFD <= 0)
		return 0;
	struct pollfd waitingSet = { serialPortFD, POLLIN, 0 };


	// Wait for a serial port event
	if (poll(&waitingSet, 1, 1000) <= 0)
		return 0;
	return (waitingSet.revents & POLLIN) ? com_fazecast_jSerialComm_SerialPort_LISTENING_EVENT_DATA_AVAILABLE : 0;
}

Then there's this blogpost with three different implementations. I just don't know how to connect all that to JNI and what to do with all the lines statuses.

Make quick way for native libs to be bundled into uber-jar

Currently, the uber-jar assumes native libs come from src/main/resources-precompiled/natives/<platform>/ but we don't actually copy them there at build time.

This means uber jars won't have the binaries needed for working code in a testing-type distribution without first manually copying them to their destination.

Add LICENSE.txt or LICENSE or LICENSE.md

The code from scream3r is LGPL.
I suggest we add the according license to each file and to the root of the github project.

idProduct and idVendor in Windows OS

Hello,

For begin thank you for library, i have question can you get the Port Properties in Windows and linux OS with jssc, like idProduct and idVendor.
and you're now in jssc 2.9 but in maven it's 2.8.0 ? exactly
thank you.

Consider OSGi artifacts using apache felix maven plugin

The patch attached in #33 had OSGi support.

We should clarify:

• what it is (in a few words) and why it might be useful to provide.
• if we need it.
• if so, why we need it.
• How to implement and test it.

Use the maven ${project.version} for the native library

The native cpp sources should use the version from the maven pom.xml.

Implementation details

• Maven can export the project version to the cmake process.
  This must be configured in pom.xml. See the existing <argLine> entries in the maven antrun task.
• This needs to be done for both the Unix and the Windows versions of the .cpp file.

Question: Can cmake substitute and/or use the argument and insert it into the specific cpp file at compile time?

https://github.com/java-native/java-simple-serial-connector/blob/c77563e3e08fadddd1d950986a3036240b20c92f/src/main/cpp/_nix_based/jssc.cpp#L55

For a trained cmake user, this is probably not a very complex task.

cant run jar generated by maven

ide:intelij comunity edition
os:debian
compiled by maven

/home/erik/.jdks/adopt-openjdk-1.8.0_265/bin/java -Dfile.encoding=UTF-8 -jar /home/erik/git/projects/arduino/projects/rgbStuff/riderPixels/java/riderPixelsV2Controller/target/pixelController1.0.jar
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.NoClassDefFoundError: jssc/SerialPortException
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
at java.lang.Class.privateGetMethodRecursive(Class.java:3048)
at java.lang.Class.getMethod0(Class.java:3018)
at java.lang.Class.getMethod(Class.java:1784)
at sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:544)
at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:526)
Caused by: java.lang.ClassNotFoundException: jssc.SerialPortException
at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
... 7 more

EXCEPTION_ACCESS_VIOLATION : JVM crashes on windows 10 in the jssc lib at : jssc.SerialNativeInterface.openPort

I was using jssc 2.8.0 and java 8. Need to switch to Java 11 for project requirement.
After everything is ported the jssc library seems to cause jvm to crash on window 10.
(Log is attached)

---------------  S U M M A R Y ------------

Command Line: -Dvisualvm.id=622907326716200 --module-path=C:\Program Files\Java\javafx-sdk-11.0.2\lib --add-modules=javafx.controls,javafx.fxml --illegal-access=warn --add-modules=javafx.base,javafx.graphics --add-reads=javafx.base=ALL-UNNAMED --add-reads=javafx.graphics=ALL-UNNAMED -javaagent:C:\Program Files\JetBrains\IntelliJ IDEA Community Edition 2019.1.3\lib\idea_rt.jar=50486:C:\Program Files\JetBrains\IntelliJ IDEA Community Edition 2019.1.3\bin -Dfile.encoding=UTF-8 App

Host: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz, 8 cores, 7G,  Windows 10 , 64 bit Build 17763 (10.0.17763.1158)
Time: Thu May 21 00:17:24 2020 Atlantic Daylight Time elapsed time: 18 seconds (0d 0h 0m 18s)

---------------  T H R E A D  ---------------

Current thread (0x0000026644350000):  JavaThread "Timer-0" [_thread_in_native, id=19756, stack(0x000000b036000000,0x000000b036100000)]

Stack: [0x000000b036000000,0x000000b036100000],  sp=0x000000b0360feb00,  free space=1018k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  0x000000007110b5db

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  jssc.SerialNativeInterface.openPort(Ljava/lang/String;Z)J+0
j  jssc.SerialPort.openPort()Z+65
j  Serial.attemptDongleConnect()V+72
j  Serial$3.run()V+45
j  java.util.TimerThread.mainLoop()V+221 java.base@11
j  java.util.TimerThread.run()V+1 java.base@11
v  ~StubRoutines::call_stub

siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), reading address 0x000000004c095fe6

There is similar bug reported earlier - https://bugs.openjdk.java.net/browse/JDK-8203772
However, this was closed as jssc issue.
I am using openjdk 11. Wondering this is fixed. Since 2.9.0 mentions following in the fixes section.
Fixed hard crash on Windows using JDK11

hs_err_pid18016 (1).log

Project rename proposal

This is a proposal to rename the project from java-simple-serial-connector to something else. There are natural downstream effects to this:

• Dependency name will change (e.g. Maven) affecting projects
• Namespace changes (unavoidable -- we don't own scream3r.org and the classes aren't properly namespaced anyway)

Upsides:

• Easier to find in a search engine
• Shorter git clone URL

Better unit tests

A placeholder to port over some of @vogt31337's unit tests from the 2.8.1-experimental branch.

    public void testSerialPortListing() {
        String[] out = SerialPortList.getPortNames();
        System.out.println(Arrays.toString(out));

        // if we reached this point, loading the dynamic lib worked.
        assertTrue(true);
    }

    private String findASerialPort() {
        String[] out = SerialPortList.getPortNames();

        if (out.length > 0) {
            return out[0];
        } else {
            return null;
        }
    }

    public void testSerialPortRead() {
        String port = findASerialPort(); // could also be "COM1" under windows, or /dev/ttyS0 under linux

        if (port != null) {
            SerialPort serialPort = new SerialPort(port);
            try {
                serialPort.openPort();//Open serial port
                serialPort.setParams(9600, 8, 1, 0);//Set params.
                byte[] buffer = serialPort.readBytes(10);//Read 10 bytes from serial port
                serialPort.closePort();//Close serial port
            } catch (SerialPortException ex) {
                System.out.println(ex);
            }
        } else {
            Assert.fail("No comport found. Maybe running on a laptop? Or cables aren't attached?");
        }
        assertTrue(true);

    }

    private String findASerialPort() {
        String[] out = SerialPortList.getPortNames();

        if (out.length > 0) {
            return out[0];
        } else {
            return null;
        }
    }

    public void testSerialPortWrite() {
        String port = findASerialPort(); // could also be "COM1" under windows, or /dev/ttyS0 under linux

        if (port != null) {
            SerialPort serialPort = new SerialPort(port);
            try {
                serialPort.openPort();//Open serial port
                serialPort.setParams(SerialPort.BAUDRATE_9600,
                        SerialPort.DATABITS_8,
                        SerialPort.STOPBITS_1,
                        SerialPort.PARITY_NONE);//Set params. Also you can set params by this string: serialPort.setParams(9600, 8, 1, 0);
                serialPort.writeBytes("This is a test string".getBytes());//Write data to port
                serialPort.closePort();//Close serial port
            } catch (SerialPortException ex) {
                System.out.println(ex);
            }
        } else {
            Assert.fail("No comport found. Maybe running on a laptop? Or cables aren't attached?");
        }
        assertTrue(true);
    }

Rework default packaging

The default packaging should be changed, as discussed on Slack.

Current situtation

The build will create

• a default jar with machine-type classifier, containing only this native library.
• a "uber-jar" with precompiled libraries.

Critique

• A jar with only one native library is rarely needed.
• Instead, a jar with all the other precompiled libaries, but only one-off/updated (selected arch) would be much more helpful.
• The "uber-jar" should be the default jar, because it is what developers would expect.
• The warning that an assembly provides the default jar (no classifier) is irritating.
• At the moment, creating fat jars is quite complicated due to this implementation (See #21).

Proposed Solution

• Replace the default jar with a jar containing all the precompiled libraries.
• Create an additional jar with the existing classifier which includes the one-off (updated) library for the selected system type.

Add NodeJS/Electron support

Per request of @scream3r, the ability to abstract the native code and make the library re-usable for Electron/NodeJS support.

Library crashes on Windows XP

• @scream3r's jSSC-2.8_x86.dll - Does not crash Windows XP
• Our version - Crashes Windows XP

After some research I've found out this is due to the bundling (or lack thereof) of some standard libraries.

https://stackoverflow.com/a/6405064/3196753
https://stackoverflow.com/a/18138926/3196753
https://stackoverflow.com/a/12922118/3196753
https://sourceforge.net/p/mingw-w64/discussion/723797/thread/116e5fd5/

So far, this helps dependency walker (it stops complaining about libstdc++, etc) but the app still crashes.

set(CMAKE_CXX_STANDARD_LIBRARIES "-static-libgcc -static-libstdc++ ${CMAKE_CXX_STANDARD_LIBRARIES}")

UnsatisfiedLinkException NOT thrown

When running the SNAPSHOT from a local build in a Java project with a missing library (no DLL, no and calling SerialPortList.getPortNames();, the software does NOT throw an UnsatisfiedLinkError but it must.

import jssc.SerialPortList;

import java.util.Arrays;

public class Main {
    public static void main(String ... args) {
        System.out.println(Arrays.toString(SerialPortList.getPortNames()));
    }
}

Output:

[]

This should raise an exception and NOT continue. This is a regression.

This not a issue

macOS can't notarize 2.9.0

Any attempts to notarize the .dylib that we ship with 2.9.0 fail, resulting in the following:

      "severity": "error",
      "code": null,
      "path": "my-app-1.0.0.pkg/my-app-1.0.0.pkg Contents/Payload/my-app.jar/natives/osx_64/libjssc.dylib",
      "message": "The binary uses an SDK older than the 10.9 SDK.",
      "docUrl": null,
      "architecture": "x86_64"

2.8.0 did NOT suffer this problem. This is a regression. Pinging @lukas-w for possible help/recommendations with this.

removeEventListener result

1. removeEventListener method has comment "If the operation is successfully completed, the method returns true, otherwise false"
   But this method never return false, only true or exception.

2. Sometimes I get "Event listener already added" error, but I don't know why.
   every time after working with port I perform removeEventListener. Can you help me?

MSVC Support

@woodrowbarlow I'd like to make the following patches to provide support for MSVC compiler:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index ce5e05e..8c54ea1 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,6 +1,7 @@
 cmake_minimum_required(VERSION 3.9)
 project(jssc VERSION 2.8.0 DESCRIPTION "Java Simple Serial Connector")

+find_package(Java)
 find_package(JNI)

 if(APPLE)
diff --git a/src/cpp/windows/jssc.cpp b/src/cpp/windows/jssc.cpp
index 08428de..92dc1bb 100644
--- a/src/cpp/windows/jssc.cpp
+++ b/src/cpp/windows/jssc.cpp
@@ -46,7 +46,7 @@ JNIEXPORT jlong JNICALL Java_jssc_SerialNativeInterface_openPort(JNIEnv *env, jo
     const char* port = env->GetStringUTFChars(portName, JNI_FALSE);

     //since 2.1.0 -> string concat fix
-    char portFullName[strlen(prefix) + strlen(port) + 1];
+    char* portFullName = (char *)malloc(strlen(prefix) + strlen(port) + 1);
     strcpy(portFullName, prefix);
     strcat(portFullName, port);
     //<- since 2.1.0
@@ -259,7 +259,7 @@ JNIEXPORT jbyteArray JNICALL Java_jssc_SerialNativeInterface_readBytes
     DWORD lpNumberOfBytesTransferred;
     DWORD lpNumberOfBytesRead;
     OVERLAPPED *overlapped = new OVERLAPPED();
-    jbyte lpBuffer[byteCount];
+    jbyte * lpBuffer = (jbyte *)malloc(byteCount);
     jbyteArray returnArray = env->NewByteArray(byteCount);
     overlapped->hEvent = CreateEventA(NULL, true, false, NULL);
     if(ReadFile(hComm, lpBuffer, (DWORD)byteCount, &lpNumberOfBytesRead, overlapped)){

The static native method getNativeLibraryVersion() throws a UnsatisfiedLinkError

Invoking the method SerialNativeInterface.getNativeLibraryVersion() will throw an UnsatisfiedLinkError.

I do not why this is the case. The according junit test-case is deactivated due to the fact that this has not been resolved yet. Please see SerialNativeInterfaceTest (https://github.com/java-native/java-simple-serial-connector/blob/c77563e3e08fadddd1d950986a3036240b20c92f/src/test/java/jssc/SerialNativeInterfaceTest.java#L32) for further information.

This method is expected to work.

[GITHUB] add templates for issues and PR

Solaris 10 support

Previously, @scream3r provided Solaris binaries with the JSSC distribution. Attempting to repeat this on Solaris 10 (oldest supported Solaris version) I get the following:

[ 50%] Building CXX object CMakeFiles/jssc.dir/src/cpp/_nix_based/jssc.cpp.o
In file included from /usr/java/include/jni.h:27,
                 from /jssc/src/cpp/_nix_based/jssc.cpp:46:
/usr/java/include/solaris/jni_md.h:19: error: ISO C++ does not support `long long'
/jssc/src/cpp/_nix_based/jssc.cpp:83:21: warning: use of C99 long long integer constant
/jssc/src/cpp/_nix_based/jssc.cpp:90:21: warning: use of C99 long long integer constant
/jssc/src/cpp/_nix_based/jssc.cpp:93:21: warning: use of C99 long long integer constant
/jssc/src/cpp/_nix_based/jssc.cpp:96:21: warning: use of C99 long long integer constant
/jssc/src/cpp/_nix_based/jssc.cpp:99:21: warning: use of C99 long long integer constant
/jssc/src/cpp/_nix_based/jssc.cpp: In function `speed_t getBaudRateByNum(jint)':
/jssc/src/cpp/_nix_based/jssc.cpp:208: warning: converting of negative value `-0x00000000000000001' to `speed_t'
/jssc/src/cpp/_nix_based/jssc.cpp: In function `jboolean Java_jssc_SerialNativeInterface_setParams(JNIEnv*, _jobject*, jlong, jint, jint, jint, jint, jboolean, jboolean, jint)':
/jssc/src/cpp/_nix_based/jssc.cpp:251: warning: comparison between signed and unsigned integer expressions
/jssc/src/cpp/_nix_based/jssc.cpp: In function `_jbyteArray* Java_jssc_SerialNativeInterface_readBytes(JNIEnv*, _jobject*, jlong, jint)':
/jssc/src/cpp/_nix_based/jssc.cpp:538: error: `memset' undeclared (first use this function)
/jssc/src/cpp/_nix_based/jssc.cpp:538: error: (Each undeclared identifier is reported only once for each function it appears in.)
/jssc/src/cpp/_nix_based/jssc.cpp: In function `_jintArray* Java_jssc_SerialNativeInterface_getBuffersBytesCount(JNIEnv*, _jobject*, jlong)':
/jssc/src/cpp/_nix_based/jssc.cpp:563: error: `FIONREAD' undeclared (first use this function)
/jssc/src/cpp/_nix_based/jssc.cpp: In function `_jobjectArray* Java_jssc_SerialNativeInterface_waitEvents(JNIEnv*, _jobject*, jlong)':
/jssc/src/cpp/_nix_based/jssc.cpp:727: error: `FIONREAD' undeclared (first use this function)
/jssc/src/cpp/_nix_based/jssc.cpp:771: warning: comparison between signed and unsigned integer expressions
/jssc/src/cpp/_nix_based/jssc.cpp: At global scope:
/jssc/src/cpp/_nix_based/jssc.cpp:843: warning: unused parameter 'object'
/jssc/src/cpp/_nix_based/jssc.cpp:828: warning: unused parameter 'env'
/jssc/src/cpp/_nix_based/jssc.cpp:828: warning: unused parameter 'object'
/jssc/src/cpp/_nix_based/jssc.cpp:720: warning: unused parameter 'object'
/jssc/src/cpp/_nix_based/jssc.cpp:674: warning: unused parameter 'portHandle'
/jssc/src/cpp/_nix_based/jssc.cpp:674: warning: unused parameter 'intArray'
/jssc/src/cpp/_nix_based/jssc.cpp:632: warning: unused parameter 'env'
/jssc/src/cpp/_nix_based/jssc.cpp:632: warning: unused parameter 'object'
/jssc/src/cpp/_nix_based/jssc.cpp:610: warning: unused parameter 'env'
/jssc/src/cpp/_nix_based/jssc.cpp:610: warning: unused parameter 'object'
/jssc/src/cpp/_nix_based/jssc.cpp:580: warning: unused parameter 'env'
/jssc/src/cpp/_nix_based/jssc.cpp:580: warning: unused parameter 'object'
/jssc/src/cpp/_nix_based/jssc.cpp:558: warning: unused parameter 'object'
/jssc/src/cpp/_nix_based/jssc.cpp:533: warning: unused parameter 'object'
/jssc/src/cpp/_nix_based/jssc.cpp:518: warning: unused parameter 'object'
/jssc/src/cpp/_nix_based/jssc.cpp:499: warning: unused parameter 'env'
/jssc/src/cpp/_nix_based/jssc.cpp:499: warning: unused parameter 'object'
/jssc/src/cpp/_nix_based/jssc.cpp:480: warning: unused parameter 'env'
/jssc/src/cpp/_nix_based/jssc.cpp:480: warning: unused parameter 'object'
/jssc/src/cpp/_nix_based/jssc.cpp:470: warning: unused parameter 'env'
/jssc/src/cpp/_nix_based/jssc.cpp:470: warning: unused parameter 'object'
/jssc/src/cpp/_nix_based/jssc.cpp:470: warning: unused parameter 'portHandle'
/jssc/src/cpp/_nix_based/jssc.cpp:460: warning: unused parameter 'env'
/jssc/src/cpp/_nix_based/jssc.cpp:460: warning: unused parameter 'object'
/jssc/src/cpp/_nix_based/jssc.cpp:460: warning: unused parameter 'portHandle'
/jssc/src/cpp/_nix_based/jssc.cpp:460: warning: unused parameter 'mask'
/jssc/src/cpp/_nix_based/jssc.cpp:448: warning: unused parameter 'env'
/jssc/src/cpp/_nix_based/jssc.cpp:448: warning: unused parameter 'object'
/jssc/src/cpp/_nix_based/jssc.cpp:425: warning: unused parameter 'env'
/jssc/src/cpp/_nix_based/jssc.cpp:425: warning: unused parameter 'object'
/jssc/src/cpp/_nix_based/jssc.cpp:243: warning: unused parameter 'env'
/jssc/src/cpp/_nix_based/jssc.cpp:243: warning: unused parameter 'object'
/jssc/src/cpp/_nix_based/jssc.cpp:65: warning: unused parameter 'object'
/jssc/src/cpp/_nix_based/jssc.cpp:55: warning: unused parameter 'clazz'
gmake[2]: *** [CMakeFiles/jssc.dir/src/cpp/_nix_based/jssc.cpp.o] Error 1
gmake[1]: *** [CMakeFiles/jssc.dir/all] Error 2
gmake: *** [all] Error 2

My biggest concern is the line:

/usr/java/include/solaris/jni_md.h:19: error: ISO C++ does not support 'long long'

... since this a C++ API provided by Oracle failing on an Oracle OS. Is this simply a matter of specifying a newer language level?

Note, to get Solaris 10 compiling jssc:

# Optionally enable SSH from root
vi /etc/ssh/sshd_config
# CHANGE
# PermitRootLogin yes
svcadm restart ssh

# Allow vi to work through ssh
export TERM=xterm

# Install git, cmake
pkgadd -d http://get.opencsw.org/now

# Setup helpful tools
export PATH=$PATH:/usr/sfw/bin:/opt/csw/bin

pkgutil -U
pkgutil -y -i git 
pkgutil -y -i cmake 
# /opt/csw/bin/pkgutil -y -i maven2 # SOLARIS 10 VERSION TOO OLD FOR SUREFIRE

# Clone the code
git clone https://github.com/java-native/jssc

# JNI header is missing, create it by hand
cd jssc
vi jssc_SerialNativeInterface.h
# PASTE HEADER

# Build
cmake .
cmake --build .

Or Solaris 11:

sudo pkg install gcc git cmake jdk-8
cmake .
cmake --build .

README.md

Hi,

will be great write better README.md.

For example: What is main goal of this fork?

[INFRA] add checkstyle checks

Add checkstyle w/ current settings (4 spaces, KR brace style, etc)

Support 2400 baud

Reported downstream: qzind/tray#476.

https://github.com/java-native/jssc/blob/master/src/java/jssc/SerialPort.java#L49:L55

Baud 2400 is missing, despite it being supported natively.

Infact, the API doesn't seem to restrict the baud rate, it's jint baudRate and it's not an enumerated type:

JNIEXPORT jboolean JNICALL Java_jssc_SerialNativeInterface_setParams
  (JNIEnv *env, jobject object, jlong portHandle, jint baudRate, jint byteSize, jint stopBits, jint parity, jboolean setRTS, jboolean setDTR, jint flags){

Back-date releases, remove from readme

Past versions can be tagged to specific commits.

• Since the project commit history starts at 0.9.0 (1a837d9). That's the earliest we can import.

The README.md isn't a great place for release information... reasons:

• It makes the default README filled with historical information that a newcomer isn't necessarily interested in.
• It requires bumping the README.md each time a release occurs, which is redundant with the releases area.

How to add a Library in the main module [module-info.java]?

I use the jssc package to access serial port. I added it to the main module

module DeskCheck {
  requires java.desktop;
  requires java.logging;
  requires jssc;
}

But I believe I am doing it wrong, because there is an error saying that module does not exist.

Creating jlink image in dist\jimage/.
Executing: C:\Program Files\jdk-12.0.2\bin\jlink.exe --module-path dist\DeskCheck.jar;C:\Program Files\jdk-12.0.2\jmods --add-modules DeskCheck --output dist\jimage --compress=2
Error: Module jssc not found, required by DeskCheck

---

Question taken from Stack Overflow in Portuguese:

https://pt.stackoverflow.com/questions/416758/como-adicionar-um-library-no-modulo-principal-module-info-java

Cherry-pick from 2.8.1-experimental

@bmhm I think you're the best candidate for this, but there are some decisions that were made in the 2.8.1-experimental branch that may be useful for this project. Some are duplicates of open bug reports (such as code formatter) but I wanted a proper review of this experimental branch before purging it.

Travis-CI ignoring cmake flags

So for some reason Travis-CI is skipping some of our cmake flags. I’m not sure why. Here’s an example: https://travis-ci.org/java-native/java-simple-serial-connector/jobs/517483760#L851

cmake-generate:
     [exec] -- Configuring done
     [exec] CMake Warning:-- Generating done
     [exec]   Manually-specified variables were not used by the project:
     [exec] 
     [exec]     CMAKE_TOOLCHAIN_FILE
     [exec] 

The builds aren’t catching this problem -- of course — because we’re (intentionally) not doing unit tests on cross-compiles. This can be reproduced locally if you don’t delete /target between cross-compile builds. One “fix” is to call mvn clean (or equivalent) before each build, but before blindly doing that, first I’d like to know how the /target directory can even exist when we’re not explicitly caching it. Thoughts welcome. Please help baby-sit Travis-CI for a bit to make sure it does not happen again.

Create a checkstyle config for java

Create a checkstyle.xml which looks a lot like @scream3r's style.

• 4 spaces
• No tabs
• opening brace on the same line
• line length? (he uses unlimited chars, but I'd keep it to let's say 140 or so).
• Unix line breaks
• UTF-8 source code files.
• Avoid escaped unicode chars.
• No empty blocks (also for catch).
• No empty catch blocks, i.e. Exceptions must either be logged or rethrown (the history may not be lost). Thus, we might need a logging framework (slf4j).
• right curly brace alone on it's own line
• Whitespace around round parantheses in for and if statements.
• One statement per line
• no ternary operator ( expression ? true : false).
• Empty line at EOF.
• enforce sane member and class names.
• do not use finalizer (deprecated anyway).
• comments are intended on the same level as code and are in their own line (not trailing).
• No star (asterisk) imports, might pose security risk.
• Import order: Static imports, separator, own imports, separator, 3rd party imports, separator, java imports, javax imports.
• utility classes (only static methods) are final and have a private constructor.
• modifier order: As in the Java Language Specification (http://checkstyle.sourceforge.net/config_modifier.html#ModifierOrder).
• switch case's fall throughs must have a comment that this is intentional.

Most of these rules are standard Java rules.

Generate sources and javadoc jar in release profile

serial/ioss.h file not found

When compiling the c++ file on the cmake branch on macOS 10.14 Mojave, cmake throws the following:

Scanning dependencies of target jssc
[ 50%] Building CXX object CMakeFiles/jssc.dir/src/cpp/_nix_based/jssc.cpp.o
/Users/owner/java-simple-serial-connector/src/cpp/_nix_based/jssc.cpp:43:14: fatal error: 'serial/ioss.h' file not found
    #include <serial/ioss.h>//Needed for IOSSIOSPEED in Mac OS X (Non standard baudrate)
             ^~~~~~~~~~~~~~~

A related issue: neovim/neovim#9050

I've tried adding export MACOSX_DEPLOYMENT_TARGET=10.14 to no avail.

arm tests use bundled library, not built library

When compiling directly on arm (e.g. Raspberry Pi), it appears to run tests using the .so from the repo instead of the one that's built. I can't get it to pass a test unless I hand-place the .so file in place.

Edit: Correction, when building directly on a Pi this occurs, not cross-compiling. That was a typo.

Create a repository for building and distributing binaries

As seen in those repositories:

• https://github.com/acegi/acegi-standard-project#performing-a-release
• https://github.com/lmdbjava/native/blob/master/pom.xml

… we might want to set up a repository consisting of the c++ code and the generated .h file. For now, we'd need to manually copy the generated .h file to the new repository. But that should not be a problem, as the interface rarely changes.

Suggested name: jssc-native.

If we wanted to avoid manual coupling completely, we'd also had to set up yet another repository with the name jssc-native-header, which contained ONLY the the Java file with the native methods, and the generated artifact (jssc-native-header.jar) would contain the compiled class file and the generated header file. This way, this library (jssc) and each artifact from jssc-native would need to depend on the very same version of jssc-native-header, which would help in detecting version and interface collisions.

To have everything built with the same versions (dependencies, plugins, etc.), we even might want to create a jssc-parent repository. The benefit would be that this would remove all the clutter from any other repository mentioned so far.

Bump version

@bmhm and others... any objection to bumping the version to 3.0.0 (-SNAPSHOT)? It's currently 2.8.1-SNAPSHOT (@scream3r's last release being 2.8.0).

Reasoning... renumbering to 3.0.0 would help distinguish this release version and patches from its predecessors as well as help illustrate some fundamental changes in the build system and the platforms we support (e.g. dropping Mac PowerPC; dropping Mac 32-bit).

[RFE] (for later): Add mvnw wrapper scripts

Suggestion for later:

Add https://github.com/takari/maven-wrapper

It will put two small scripts (mvnw (sh) and mvnw.bat) into our repository, as well as a folder .mvnw containing a single tiny tiny jar file.

Benefit:

• Non-Maven-Users do not need to install maven
• Just executing ./mvnw clean install or just ./mvnw will suffice. If maven is not installed locally, mvnw will download it.
• Commonly used

Drawbacks:

• Binary files in repo (but they don't change often and are tiny)