Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
How can I publish an API with Java? In languages like C or C++ it is really quite easy because you can simply divide headers from code, but in Java this is a complete different story. So I know that there is no real way in Java you can obfuscate your code, even if you "obsfuscate" it, because it can be easily decompiled and analyzed. But if I don't simply can distribute headers to someone, what is the preferred way to publish a API in Java? I don't have special needs because I am in the beginning of the designing process so I am really dynamic and I would like to know all alternatives I have.
A clean way is to define your API purely in Java interfaces, include those into a separate API module and make implementation module depend on the API module. This does not provide the same functionality as separating C++ header files, but it is a good idea to program to interfaces anyway completely separating those from a particular implementation.
You don't need to publish your API as header files. Everything the developer needs is already in the JAR. If you want to publish documentation publish the java docs of the code.
You can obfuscate your code using a professional java obfuscator. Then it is not easily decompiled and readable. You can then publish your jars and javadocs like others have mentioned.
You could split your library into multiple jars and provide one with the classes and interfaces that form the api and another one that contains the implementations of those interfaces.
However, note that the hastle might not be worth it. Why exactly would you try and obfuscate code the users of that api would need anyways? What I mean is, that whoever would use your api would also need the implementations of the interfaces to run the application, so they'd still be able to decompile your code.
Generating an api-only jar would help with separating api and implementation though (which means you could replace the implementation or prevent accidential direct access to the implementation).
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed last year.
Improve this question
I've been trying to learn Kotlin but I find it to be a lot easier to learn when I can slowly apply it to things I'm working on in Java. Is it a bad idea to mix Java and Kotlin in production?
I know the overall goal is to use one or the other but is there anything wrong with the latter?
Objectively, we can say that compatibility with Java was one of Kotlin's main objectives, according to the official docs:
Kotlin is 100% interoperable with the Java programming language and major emphasis has been placed on making sure that your existing codebase can interact properly with Kotlin. You can easily call Kotlin code from Java and Java code from Kotlin. This makes adoption much easier and lower-risk. There’s also an automated Java-to-Kotlin converter built into the IDE that simplifies migration of existing code.
Many features are designed specifically to ease calling Java from Kotlin or vice versa: for example, the fact that property accessors are implemented in the same way as normal Java accessor methods, and the ability to implement SAM interfaces; and where Kotlin implements things differently, there are often annotations or other ways to use a Java-style implementation.
And in my own experience, there are no issues with mixing Java and Kotlin classes. Many of our projects have both (new classes written in Kotlin, a few old ones converted but many still in Java), and I'm not aware of any significant problems. I also converted a major project from Java to Kotlin, one class at a time — and after each one, everything still compiled and tested and ran perfectly.
Of course, new projects can be written in Kotlin from the start; but if you already know Java, mixing in some Kotlin is absolutely an option, and may be the easiest approach. You can convert parts to Kotlin piecemeal, when convenient, or leave them in Java long-term; pretty much everything just works, and you benefit from the parts that are in Kotlin. (You might even find that the way you write Java code benefits from knowing Kotlin!)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
When learning/working with a new API, does anyone have any tips for effectively learning it?
I currently make a bunch of get requests to understand what I can and cannot retrieve based on the API's responses. From that point I try to map out what is within the API and see what I can build out.
If you guys could share anything what you do that would be great.
The first thing i do is to read API documentation and search for examples in it. As you get used to read this kind of docs you'll find easier to find exactly what parts of the functionality you need to learn first.
I also use search engines to look for more working examples, and after that I work on creating a minimal use case of the API (for example write a file with commons-io api of apache). For this is a good idea to create a project with multiple JUnit tests with minimal use cases of an API (in the example of commons-io create a file, delete a file, move a file, copy a file, ...).
I must say this is not a science and each API is a new world and may require a slightly differnt approach (As with rest apis you'll need to use some tool like curl or postman to understand how to communicate with them, others will have pre-requirements like have a working installation of a system, and so on).
As everything in coding you'll need to do it by yourself and struggle to solve issues you'll find by yourself (what can take several hours of your free time).
There is no "magic" behind learning something, and coding is in some way like playing a musical instrument, it requires practice.
I dont know whether you are a beginner or you have developed already but will start from scratch..!!
Apis are the code which will allow you to play with the content having certain formats...!!
There are apis based on what operations you want to do are.
Get=> In order to fetch something.
Post=> In order to save something.
Put => to update something.
Delete => to delete something.
People also use patch similar to update...!!
You can play around all these by constructing objects and databases...!!
You will require rest services spring restful web service is the ultimate good options..!!
Diving deeper you need to be careful assigning the names you give I mean the meaningful names as you dont know if tomorrow you become famous and need to make your apis sharable ;)
Now some common concerns are like
Meaningful Name.
Versioning is required like what the old apis are working and now what data your apis give.
Can implement swagger its a tool which will allow you to describe the apis like you can write what this api does what type of data it brings etc etc..!!
Apis are more or less called an end points means you have that link as a connection between front end and backend So need to keep it secure..!! By authentication.
Above four points are considered to be good practises for writing apis ;)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I'm currently on a school project, we made a FuzzyLogicFramework in C++.
Now, I try to use this framework in Java in order to do an android app using the framework, I have a factory called FuzzyFactory in the c++ project.
the prototype for its methods are like this :
Expression<T>* newAnd(Expression<T>*, Expression<T>*);
I don't necesserly want to use all the avaiable types that is why I created a class like this :
template<> class FuzzyFactory<float>;
I generated a DLL library with this class.
My questions are the following:
I want to use this library in a Java file : what technology could I use?
I heard about JNI and was able to run basic functions with it, but would I be able to manage objects instanciation ? How would I be able to give pointers in my functions arguments in Java ? I was able to run my c++ project main in Java using JNI, but it seems using a Factory class with it is on another level.
I also heard about wrappers and JNA
I just need somebody to told me a technology to use, It's my first time trying to do cross language implementation so I'm a bit overwhelmed.
if you want to see a bit more about the current state of the project : https://gitlab.com/MelvinC/languageframeworkproject-ensisa-2020
Should my Java project and c++ project be in the same git repository ?
Sorry for my english, if it is not good enough.
Thank you in advance for reading and helping me.
SWIG has some support for C++ templates and can generate Java binding code from C++ headers. That will give you a very low-level, but hopefully usable interface.
Alternatively, you might want to consider some sort of external representation of your logic program. You can then use plain Java code to construct the program, then serialize it into the external representation and pass it to the C++ side.
For inspiration, the Z3 SMT solver accepts a representation called SMT-LIB.
Alternatively, you can create your own format using S-expressions, XML, or even just nested JSON.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
What are the options to define the public interface to a library in Java.
For example I often find that things are public because another package in the library needs them (although still with a common base package, e.g. com.stackoverflow.mylib.), so they can't have the package access level, and generally people don't want massive packages (it also seems that people using Spring insist on having the separate controller/service/model/impl/etc. packages, resulting in a single "feature" being forced to span many packages, when say a given service might be a completely internal implementation detail not for external use...).
So the ideal goal is to make the Jar I provided to 3rd parties to make it clear that these things are not to be used, ideally by not having them available at all (not present in the API jar), so that it is not possible for them to use and compile with those internal objects/methods.
Even more ideally for objects there only supposed to obtain from some kind of factory (e.g. a provided Spring Bean), a way to prevent direct instantiation from their code or custom bean (which may leave some future, not yet present property uninitialised after upgrade).
The two formal ways I know of currently are:
In some projects I have worked on, there is an api package (e.g. com.stackoverflow.mylib.api), and the rule is only the contents of this package may be directly accessed by outside users.
In some other projects I have worked on, there have been some custom attributes, e.g. #PublicSDK to mark objects and methods for use by the public (and I think some extra stuff to ensure only things marked as such are in the publicly distributed javadoc and api jar).
The first thing to ask yourself is - do you really need to hide the implementation details?
The reason I say this is that there's going to be an expense involved in doing so, which depending on your circumstances may or may not be worth paying.
For example, if your API is being used by developers outside of your immediate team then it's probably worth the expense; however if it's just to hide the implementation details within you team I think it's overkill.
If the API is for use within your project then a standard where by you try to depend only on abstract types or interfaces is, imho, sufficient (and already the standard).
However, assuming you do need to hide the implementation and expose only the public API, the best way I know to do it is to produce two jars - one containing the public API and another that is the implementation of that API.
If you're using Maven or Gradle to build the project that is using your API you simply declare a compile time dependency on the API jar (artifact) and a runtime dependency on the implementation jar (artifact).
This pattern can be seen throughout the common Java APIs, the latest example being the JSON API that is implemented separately as part of Glassfish.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I've done a lot with IO in Java and after looking for code to convert primitives to byte arrays and back I found source for java.io.Bits on one of the Java source code hosting websites. After a quick glance I realized it's exactly what I need, except it's package-private. So I made a copy which I made public, stored in my project's package and used (only in personal projects, I assure you). I find it very useful.
My question is, why is this package-private? I can see it being really useful for people who work with IO and I see no disadvantage from changing it's visibility to public (in rt.jar). Or is there perhaps an equivalent (and please don't mention other libraries)?
Here's a link to a randomly chosen website that has Java source for java.io.Bits: http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/io/Bits.java
You'd have to ask one of the Java devs for sure, but by making it package private, the API can be treated as "internal" - i.e. it might change or disappear at any time. This means the API can be developed relatively quickly, and doesn't need to go through the same relatively thorough testing process that public APIs need to go through (since once they're released, they're stuck there for good.)
In short, making an API public has long term implications, and it requires much, much more work than just hitting a switch.
I would hazard a guess it started life as a "hacked together" group of functions useful for a few other classes in the IO package, and has just stayed there ever since.
It's package-private, sure, but there are public APIs that expose the same behavior, e.g. ByteBuffer.wrap(array).getInt(index) and the other methods on ByteBuffer. You're almost certainly better off using that properly designed, well-documented public API than trying to wrap or copy internal implementation details from Java.