java.io.IOException: Invalid argument
at java.io.FileOutputStream.writeBytes(Native Method)
at java.io.FileOutputStream.write(FileOutputStream.java:318)
at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295)
at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
at atael.PiGPIO.main(PiGPIO.java:35)

Andy,
Hi,
In the blog by Hinkmond Wong about using low level file IO to control the GPIO pins. It seems that you have used an older version of his code - he recently corrected it to avoid the "Invalid argument" exception by first checking for the unexport file - you should add the following fragment to your version as the first write.
Running this code either as a FileWriter or FileOutputStream works fine both ways as both are OutputStream(s).
At Oracle we made every effort to publish articles as much as possible to help out the open source development community - a link to the original article always helps when we update/fix technical issues.
Thank you to Raspberry PI evangelist Hinkmond.https://blogs.oracle.com/hinkmond/entry ... dded_gpio3

note: gpioChannel is undefined and should be replaced by GPIO_CH00 - see corrected version below.

If all you are trying to do is interact with the Raspberry Pi's GPIO ports from your own Java code, then you may want to try something like the Pi4J Project instead. This is an abstraction library that makes it much easier to work with the GPIO pins and states and you don't have to attempt to do all the lower level file access stuff.

But in the tradition of open source, before using a framework for the integration layer it is good to know about the mechanics of the low level file based peripheral control of the GPIO - when debugging issues with or away from the frameworks in the future.

I fully agree with your comment about understanding the mechanics of a framework, but the OP mentioned that they were a "novice developer" so starting with a framework to get up and running may prove more fruitful and then go back and learn how it works under the covers after accomplishing a working program

Pi4J and Framboos are both great options for Java programmers. Pi4J is of course my favorite since I started the project Pi4J does provide an eventing model for GPIO pin state change events based on interrupts (not polling).

Thank y'all for all the suggestions and after following Hinkmonds fixes it works like a charm.

The only reason for not using a framework is that I am trying to understand how to control the Pi on a very low level (I am a experienced Java developer but a novice at the interfaces Pi gives me). When I get a feeling for it I'll look into a framework and pi4j looks excellent.