Open nbriggs opened 1 year ago
I will do Nick. A v1 branch would be perfect for any updates and bug fixes, while the trunk will be the master for v2. A bit tricky operation though. I might just create another repo called jnetpcap-v1, jnetpcap-archive or jnetpcap-legacy or some thing like that.
I'd prefer to keep everything under same repo. Less confusion.
Thanks. I can cope with either organization.
Just to bring up this issue. The latest version in legacy branch was 1.5.r1500 which upgraded support for Java 9+ and added module-info.java file. Does that mean that due to your hard Java 8 limit you would not be able to run that release?
I'm just trying to understand what kind of support you need going forward in the legacy v1 development train.
I will be importing the SF.net SVN repository into a new repo. After considering many options, because I am still maintaining the legacy branch, which shares little code with the v2, I decided to use the Github import tool to transfer the old SVN repo. This will also preserve commits logs and transfer issue tickets.
I want to name it jnetpcap-legacy if there are no objections. I think just naming it jnetpcap-v1.x will be confusing and not explicit enough what is the latest. I won't call it jnetpcap-archive as there will still be maintenance done on it going forward.
I will investigate further whether there are any OpenJDK releases after the last Oracle release for Solaris 11.4 on SPARC -- this is where I'm currently at:
% java -version
java version "1.8.0_311"
Java(TM) SE Runtime Environment (build 1.8.0_311-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.311-b11, mixed mode)
I believe that in recent OpenJDK releases they purposely removed support for SPARC processors.
A separate repository is fine and of course you are free to choose any name that fits your purpose!
Just FYI -- I'm using the jnetpcap code with the Dodo XNS networking code (https://github.com/devhawala/dodo) to exchange raw XNS packets on the wire with the simulated XNS network with XNS services within Dodo.
I find this, for OpenJDK: https://openjdk.org/jeps/381
Looks as though I'm stuck at Java 8 (1.8) -- in order to build Java 9 I would need compilers that are too old/don't seem to be available anymore (the Java 9 source is not compatible with more recent Oracle Developer Studio compilers, and it refuses to build with gcc or clang of any vintage), and in order to get up to anything more recent their bootstrap process requires that you build every release between your existing release and the target. Sigh.
Spoke too soon -- I have found a Java 11 JDK hidden behind an Oracle login requirement, and have managed to get that and install it.
It would be great if you could keep a copy of the old 1.x library code here, too, along with what's necessary to build it.
The system I needed to build on has no Java support post Java 8, so no option to bring the application forward to the 2.x code.