We Keep Coding

How do you write vector files with the GDAL Java bindings?

I have no trouble reading files of different types using GDAL's Java bindings (version 2.2.1) via the org.gdal.ogr.ogr.OpenShared(filePath) method to create a DataSource. If I want to create a SQLite file from a DataSource, however, how would I do it?
Looking in the JavaDocs, I've found some ExportTo methods on the Geometry object that you can use to manually build GeoJSON, WKT, KML and others: http://gdal.org/java/org/gdal/ogr/Geometry.html
There doesn't seem to be anything in the Driver class that would let you use them to export a DataSource however.
Using ogr2ogr it would be as simple as running the following:
ogr2ogr -f "SQLite" ./output.sqlite3 ./input.geojson
And there is this technique for running ogr2ogr from within Java, but I would have assumed there'd be something native in the Java bindings.

I've accepted that the best way to do this is to simply include the ogr2ogr.java file from the GitHub repo in my project and wrap it in a function that makes it cleaner to access. It is almost a direct port of the original C++ GDAL file.
The one change I made was to rename the ogr2ogr main function to execute so that it didn't confuse application when I ran it.

Swagger-codegen renames methods with same names

I have generate a swagger client api with:
java -jar swagger-codegen-2.2.3/modules/swagger-codegen-cli/target/swagger-codegen-cli.jar generate -i http://localhost:8080/myproject/services/service0/swagger.json -l java -o client/myproject/java
But swagger-codegen rename methods with same names despite the fact that they are in different java clases. Is there any option to solve that issue?

The renaming of method will not affect the URL path and you should be able to make the REST call with the generated UI .
Even i don't know the reason why Swagger code gen works that way .
But i also feel that our API consumers doesn't have to know the method which are called either . So generated UI should be good to go

How to manage Linux file permissions in Java?

Is there any mechanism to get and set the file/directory permissions?
For example, I want to show the permisssions of a file in a shell way:
-rwxr-xr--
Is it possible to do this using Java?
I know that there are some methods in the File class to know if the file canExecute, canRead and canWrite, but AFAIK this info is for the current user only. I need to know the whole octal number, for example 755, so I need to get it from the user, from group and from others.
I know that Java7 brings Posix operations, but how could do this using a smaller JRE?
I would like not to use a command like ls, or chmod.

If you can use external libraries, there are several:
JPosix
Posix for java
jnr-posix
If an entire library seems a hassle, creating a JNI wrapper that calls the lstat C function and returns the access mode takes you about 10 minutes. Here's a tutorial that creates such a wrapper for the isatty and ttyname functions.

As you say, in Java7, the JVM supports it, so you have a guarantee that this can be done portably in all OSs (because the JVM implementation takes care of it). Under Java7, you'd have to use a native library per OS you want to support. This is potentially even dirtier than executing chmod

How to debug Java Stored Procedures in Oracle

I have an Oracle Db with stored java procedures, which I load new procedures here and then.
I would like to be able to debug these java procedures, with a same debug methodology like setting the App server in Debug mode.
is it possible? how can I do that?
Thanks

The Oracle JDeveloper has support for debugging java stored procedures. You will need to compile the java classes using the -g option so that the debugging information is generated in teh class files, i.e.
javac $JAVA_OPTS -g file_names
After that, you will need to write a dummy pl/sql package-procedure that invokes this java stored procedure. Then right click on the pl/sql procedure name and select 'Debug'.
After that you can step through the pl/sql and java code just as if you were debugging a regular java class. Since you compiled the java class using the -g option, you can watch variables, evaluate expressions etc. If you didn't use the -g option, you will still be able to step through the code in the debugger, but you will not be able to watch the variables/expressions.

I think you'll want to use JDeveloper which you can also use to debug the app server. It's not as good an IDE as, well, almost any other IDE, but it works well enough for debugging tasks.

Another option is to use the Java Logging framework.
You can then copy logging.properties, with your specified Handler into the folder ORACLE_HOME/javavm/lib

How should I call a Perl Script in Java?

I read Runtime.getRuntime().exec("perl script.pl") is an option, but is this the best way to do it?
I'll need an answer from that script, so I'll have to read the script's return in some cases, although I might read it from a text file on other cases.
Anyway, is exec() a good way of calling a Perl Script from Java? I should note, I'm working on a Java Web Application, so security is an issue here.

You can use Runtime.getRuntime().exec() or use the Process API.
The Process API allows you to get the output of the script, so you can have both communicate.
exitValue() and getInputStream() seems to be what you need.

This outlines how to do it fairly elegantly, though it may be more effort than it's worth:
http://search.cpan.org/~nwclark/perl-5.8.9/jpl/docs/Tutorial.pod
Overview:
Well-supported by JPL, but it is a complicated process:
The JPL preprocessor parses the .jpl file and generates C code wrappers for Perl methods. It also generates Java and Perl source files.
The C compiler compiles the wrapper and links it to the libPerlInterpreter.so shared library, producing a shared library for the wrapper.
The Java compiler compiles the Java source file, which uses native methods to load the wrapper.
The wrapper connects the Java code to the Perl code in the Perl source file.
Fortunately, a generic Makefile.PL simplifies the process. This is a Perl script that generates a Makefile for you.

exec() is likely the best option and you can catch it's return value with exitValue(). You might also be interested in Inline::Java.
-John

keep in mind, whatever file the Perl script create, it is created in the Java working folder. just refer to that file as './myPerlCreatedFile.ext'