Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
As a newcomer in Java, and especially in JavaEE, I try to be as correct as possible in the words I use. I understand that an Interface is a series of abstract methods. On the other side, an Application Programming Interface is "a collection of prewritten packages, classes, and interfaces with their respective methods, fields and constructors". Am I wrong if I understand that API has not so much to do with Interfaces and could be called "Java Libraries" ? And that the use of the word Interface is, to say the least, confusing ?
Basically, you will face this terminology error everywhere. Library, API and Framework.
What you are asking,
Interface: In computing, an interface is a shared boundary across which two separate components of a computer system exchange information. The exchange can be between software, computer hardware, peripheral devices, humans and combinations of these.
This is by Wikipedia, This actually means, in Programming Languages like, Java, C++, Php or any other, it relates to isolating the layers from others. For example, You might need to access USB drive but for this, you won't use the core Java code, going deep into the Microprocessor or Micro-controller level. So, you will use any Java interface to achieve the same thing.
Whereas, when it comes to Application Programming Interface (API): then it is more application specific, not like Java interface which is more generic. For example, you are making an application which interacts with its own database, and you do not wish any third party application to interact with your database directly, but you want them to access your application, then you create an API for your application, which will act as a communication method for any third-party application to interact with your resources, safely, because you have exposed those methods.
Related
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
I soon need to implement an interface. The interface will need to provide a contract between a web service and 'n' other web services for highway traffic control. The company plans to investigate/test with a single traffic control service at first and add more later as they become available. I can define an interface that's "generic" for this single use case, but the problem is that at any point in the future, we might want to communicate with another web service that may or may not be compatible with the interface we have at that time.
I could modify the Java interface as we go to accommodate the differences in API's from third party services. This would also mean updating all implementors of the interface, too.
I would like to know if there are any patterns that would be suitable for this. Almost like "dynamically extending an interface" at run time. Or, any clever use of Java generics that would allow us to implement a single Java interface once that could be used with any/all traffic control systems.
Bottom line: When we come to communicate with any other third party services, I want as minimal effort on our side to integrate them.
Any thoughts?
If the issue is adapting different representations for the same semantics, then define your own interface containing all the semantics you need, and create an adapter layer that transforms the custom representations to yours. This is the same principle behind device drivers. A uniform client interface and multiple adapters to different devices.
If you expect to encounter "devices" (traffic control services) with wildly differing semantics, then you will have to have multiple driver types... again, exactly the same situation as the difference between block devices and character devices.
Your situation is just another example of a very well known and solved pattern :-)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I appreciate this question may get closed due to its open-ended nature, but I'm curious none-the-less.
If I wanted to develop a cross-platform Web application using a statically-typed language, what would my choices be? I'm aware of Mono and Java, but what else is there?
(When I say cross-platform, I mean Windows and at least one common flavour of Linux)
You can use single language for the both client and server parts:
Java
C#
Google's Go
Scala
GWT(Java framework)
Haskell web frameworks
There are several high-performance Haskell web frameworks that emphasise strong static correctness:
snap
yesod
happstack
The goal is to lean on the type system to provide highly optimzied code, and zero chance of runtime failure.
To quote the Yesod web site:
Turn runtime bugs into compile-time errors
Yesod believes in the
philosophy of making the compiler your ally, not your enemy. We use
the type system to enforce as much as possible, from generating proper
links, to avoiding XSS attacks, to dealing with character encoding
issues. In general, if your code compiles, it works. And instead of
declaring types everywhere you let the compiler figure them out for
you with type inference.
If you mean statically typed, there isn't that much choice unfortunately. Google's Go language seems to begin growing into the web application space (there is Go support for Google's App Engine and projects such as GoWeb), but these efforts are probably not very mature yet.
Scala might be another possible option. While it also runs on the JVM, its web frameworks are very different due to the language's advanced features (see e.g. Lift) and might be worth a separate look.
In addition to Java and C# (via mono), you could also use (modern) C++ in the form of the
Wt (C++ Web Toolkit).
Now the C backwards-compatibility part of C++ is not strongly typed, but otherwise C++ programs are type safe.
If you want really strong type safety, you can use Haskell with Yesod. The goal of Yesod is to use strong types to prevent common errors in programming web applications. URLs, for instance, are type checked. You cannot construct an intra-application link without supplying the correct parameters. Escaping of user-content when rendering the web page is another situation where the Haskell compiler is used to ensure that strings are properly escaped before being included in a rendered page.
I believe Ruby is stongly typed, so Ruby on Rails be a good choice for this.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I learned php using just the website php.net, but I'm struggling to do the same with Java.
I would like to reach my php level with jsp and generally java, but I find the official docs way too much difficult to read, and if I have a task to accomplish it's quite impossible (to me) without googling and stackoverflowing.
I am wondering if it's normal, or I'm ignoring some secret about the APIs I should know.
I want to make an example: if I have to manipulate a string in a way, I look the PHP manuals for the string functions, and look for the ones I could use reading the brief description I find there.
But if I want to do the same with Java, ok, I know that there's the String class, but there are also an incredible amount of other classes, inherited classes, abstract superclasses, accessories, methods inherited from, interfaces, and I don't know what, that's impossible to read anything (if I'd try perhaps I'll learn Java in the following life).
So I have to rely to manuals websites and google, and find guides and tutorials which describe how to do a particular task (for example, connecting to a Tomcat server and manipulate a DB);
But I don't like to rely to external sources, I would like to find what I need at the source, as I had the experience of my php.net pages which are so precise and full of info and examples.
So? What am I missing?
I am quite sure there's a way to find the right info starting from the api. is it true? and how?
Welcome to the wonderful world of Java.
Yes, just for something like reading from a file, you have java.io classes for things like File, RandomAccessFile, FileReader, FileInputStream, DataInputStream, and BufferedReader (all slightly different and used for different purposes, often one stacked atop another). Then you have java.nio, plus the auxiliary classes like java.util.Scanner which are great to have but you need to be aware of first. For any package you'll want to use there's generally an interface, an abstract class, and then a factory to actually manufacture the instance (generally of a third-level derived class) you need to use.
No, reading the JavaDoc is not a great way to learn the language. Java is not as simple as PHP, for whatever reason (the word "enterprise" comes up often, and static safety is a big difference in the language core even without philosophical angles). It has strong advantages, but being able to learn it just from the APIs is not one of those pluses.
You should get a book - I recommend O'Reilly Publishers' products. There are also plenty of decent tutorials on the Internet for the taking. The raw APIs are more "I know which class I want to use, now what methods does it have?".
I don't recommend using the API unless you want clarification on how a particular object behaves, or how you can best manipulate the object for your purposes. The reason being, as you said, there are a lot of different objects that do very similar things, but with subtle differences.
The API is a reference to information about the language; exploring the Java Trails would be the ideal place to start.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
Hoping that anybody here knows about a good one: I'm looking for a (free to use) C++ library with a class hierarchy and methods resembling the Java API, with at least the I/O & networking part if it, specifically HTTP handling.
I work mainly with C & Java, but for this particular project C++ is recommended, so I thought of adopting a good set of C++ libraries without facing a steep learning curve.
Thanks in advance for any recommendation.
Qt is IMHO very java like. I.e. they prefer Java-Style Iterators over the STL ones. Qt includes networking (examples) and much other stuff (like scripting via javascript)
Have you looked at the Boost libraries?
Boost.IOStreams provides a framework for defining streams, stream buffers and i/o filters.
Asio - Portable networking, including sockets, timers, hostname resolution and socket iostreams.
Many others....
The Boost libraries provide similar capabilities as compared to the Java API, but they very much 'look and feel' - appropriately - like a C++ library.
There is also the option of using something like POCO, which is slightly simpler than using something like Boost, while still being cross platform.
While the only time I used HTTP in Java was a long time ago, the interface for the POCO library looks fairly simple to use. It gives a example of basic FTP usage a something like this:
Poco::Net::FTPStreamFactory::registerFactory();
std::ofstream localFile(inputFile, std::ios_base::out | std::ios_base::binary);
Poco::URI uri(inputURL);
std::auto_ptr<std::istream> ptrFtpStream(Poco::Net::URIStreamOpener::defaultOpener().open(uri));
Poco::StreamCopier::copyStream(*ptrFtpStream.get(), localFile);
A C++ library that looked like a Java one would be a bad library, IMHO. The two languages are so very different that what is good design for one will almost inevitably be bad design for the other.
You can take a look at Mindroid, which is primarily oriented to embeddded programming:
Mindroid is an application framework (with focus on messaging and concurrency) that lets you create applications using a set of reusable components - just like Android. The name Mindroid has two different meanings. On one hand Mindroid is a minimal set of core Android classes and on the other hand these classes also form Android's mind (at least in my opinion).
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
We are developing a middleware SDK, both in C++ and Java to be used as a library/DLL by, for example, game developers, animation software developers, Avatar developers to enhance their products.
What I would like to know is this: Are there standard "Best Practices" for the development of these types of API?
I am thinking in terms of usability, readability, efficiency etc.
My two favourite resources on the subject: http://mollyrocket.com/873 and http://video.google.com/videoplay?docid=-3733345136856180693
From using third party libraries on Windows I've learned the following two things:
Try to distribute your library as a DLL rather than a static library. This gives way better compatibility between different c compilers and linkers. Another problem with static libraries in visual c++ is that the choice of runtime library can make libraries incompatible with code using a different runtime library and you may end up needing to distribute one version of the library for each runtime library.
Avoid c++ if possible. The c++ name mangling differs alot between different compilers and it's unlikely that a library built for visual c++ will be possible to link from another build environment in windows. When it comes to C, things are much better, in particular if you use dll's.
If you really want to get the good parts of c++ (such as resource management through constructors and destructors), build a convenience layer in c++ that you distribute as source code that hides away your c functions. Since the user has the source and compiles it locally, it won't have any name mangiling or abi issues with the local environment.
Without knowing too much about calling c/c++ code from Java, I expect it to be way easier to work with c code than c++ code because of the name mangling issues.
The book "Imperfect C++" has some discussion on library compatibility that I found very helpful.
The video from Josh Bloch mentioned by yrp is a classic - I second that recommendation.
Some general guidelines:
DO define your API primarily in terms of interfaces, factories, and builders.
DO clearly specify exactly which packages and classes are part of the API.
DO provide a jar specifically used for compiling against the API.
DO NOT rely heavily on inheritance or the template method pattern - over time this becomes fragile and broken.
DO NOT use the singleton pattern or at least use it with extreme caution.
DO create package and class level javadoc explaining usage and concepts.
Take a look at Framework Design Guidelines. I know it is .NET specific, but you can probably learn a lot of general information from it too.
There are lots of ways to design apis, depending on what you are solving. I think a full answer to this question would be worthy off a whole book, such as the gang of four patterns book. For Java specifically, and also just OO programming in general, I would recommend Effective Java 2nd Edition. The first is general and a lot of popular programming patterns, when they apply and their benefits. Effective Java is Java centered, but parts of it is general enough to apply to any programming language.