i've bought a book "learning the java SE 6 platform". i wonder what the word platform really means. cause isn't it just a bunch of classes that i can use. the JDK 1.6 node in Netbeans under Libraries.
And what is API? isn´t it the same thing as platform. But doesnt library mean the same thing..a bunch of classes with some superclasses and so on?
The term "platform" is used to denote any collection of software, services and resources that, within a specific context, are considered a given so they can be used as building blocks for application software (or to build a higher level platform on top of that - something considered a platform in another context)
API is an acronym for application programming interface. This usually means the collection of calling conventions (function signatures and the like) that can be used by an application (the program you are writing) for perusing functionality residing inside a library or a platform.
An API is not the same as a library - the term Interface conveys that it only specifies what you can call, and how that behaves. The actual library that implements the interface can decide for itself how it delivers the specified functionality.
A good example of an API is for example the JDBC API - this is the standard way for java programs to communicate with databases. Each database vendor has its own protocol for connecting to the database, binding variables and such to database commands, but the JDBC API abstracts all that and defines a common ground what allows all java programs to use the same set of functions to talk to - ideally - any database. It is the database vendor's job to actually provide a driver, that is, implement a library that is in accordance with the API and knows how it can fulfill its tasks for that particular database system. So in this case you have many driver libraries (each vendor has their own, sometimes multiple ones) but they all deliver their functionality through the same set of functions, classes etc. specified by the API (in this case, the JDBC API - see http://java.sun.com/j2se/1.5.0/docs/api/java/sql/package-summary.html
Sometimes, an API is so extensive that it is considered a platform, but the term platform is more general, a platform does not need to be an API. For example, the collection of standard UNIX utilities like ls, grep, cd etc. can be considered a platform, but not so much an API.
The Java platform consists (roughly) of the following:
The Java programming language
The Java API
The Java Virtual Machine
There's a quite a bit of details in the Wikipedia article on Java (software platform).
The API, or application programming interface, alone provides the classes that come with the Java platform. For example, when one says the "Java API", one would probably be referring to the class libraries which come with the Java SE platform.
Just for the sake of providing links, here are the official documentation for each part of the Java platform:
The Java programming language - The Java Language Specification
The Java SE API - Java Platform, Standard Edition 6 API Specification
The Java Virtual Machine - The Java Virtual Machine Specification
API - is a Application Programming Interface - this is a set of classes for use.
Platform is a whole bundle - API with runtime and additional applications like compiler, ect.
Yeah platform is more of a general term that can mean different things in different contexts. Think of a gaming platform like the XBox. In this case Microsoft provides a "platform" for developers to make games, and for people to play games on.
In the case of J2EE (enterprise Java), the term platform to me means a solution for developers to build enterprise applications. Its more than a set of classes as you pointed out. For example there are plenty of specifications such as JPA (for persistence), EJB etc. In these cases the Java developers have laid out a specification for other vendors to implement. I think of platform as a base that provides a variety of services on which to build something greater.
An API is a more technical a precise term. It stands for Application Programming Interface. An API is the interface that we developers use when using other people's software. Think of a Java String class. It has a length() method. All Jave developers know that this method exists for the String class, and it is thus part of the Java API.
Related
Like on jdbc java provide an interfaces, I see the interfaces like a contract for implementers (Drivers from multiple vendor) to implement those interfaces with respect to their documented functionality from java.
But on java ee, and based on this answer :
https://stackoverflow.com/posts/7571260/revisions
It's the same case on jave ee, the application servers are vendors and they implement jave ee abstract API, but on jdbc (And I mentioned it just as an example) the interfaces on java.sql package define the contract, but on jave ee(for example HttpServlet class) where is the interface the defines the general rules from java to this class that application server have to implement?
or is there any external agreements among application servers to implement the functionality of java ee classes?
Or java ee doc (like on
https://docs.oracle.com/javaee/7/api/
)
is adopted as an agreement?
Some people will see my question is useless, but I want to know the root of any stuff I want to learn, and my mind is used to answer small deal questions.
There are test suites that the vendor implementations are tested against, which obviously need to pass. The specifications also need to be obeyed to be a valid Java EE implementation. The Javadoc API is not the spec, but rather a side effect of it.
We want to use existing C# sources within our Java project. So far, this would not be a great problem since using e.g. Java Native Interface (JNI) is quite straight forward.
The problem is that the software shall also run on non-windows OS. So, we can compile the C# sources with Mono in order to make them executable on e.g. Linux. But how about the integration within Java? JNI or any COM-based solutions for C# <-> Java interoperability are OS-dependent and only work e.g. on Windows.
One possible solution would be the implementation of webservices. Has anybody another idea of how to solve this problem? I would be very thankful for alternative suggestions!
Thanks very much!
Regards
This is maybe not an "answer" as such, more a bit of discussion of how I viewed a similar (I think) situation.
I had a major investment in a C#/.Net-based client-server style system. So when I decided that I also wanted to support an Android "client" app I looked into various options. To me the most important factor was to maintain my C# classes as the defining classes for the object interchange between the existing system and the to-be-written Java Android app.
What I eventually settled on, and tweaked to my liking, was a system where Google Protocol Buffers is the interchange media. (If you're not familiar with them they are a sort of JSON-like interchange format.)
https://developers.google.com/protocol-buffers/
At the .Net end I use ProtoBuf-Net, written by Marc Gravell (he works here at SO, I believe). It includes the ability to take .Net objects and generate .proto files, the defining file for Protocol Buffers.
https://code.google.com/p/protobuf-net/
At the Android end I use ProtoStuff, written by David Yu. There is a part of his code that takes a .proto file and generates the corresponding Java classes.
https://code.google.com/p/protostuff/
One problem I encountered was that this didn't work well for my .Net classes that are derived classes, which was most of them. I created a workaround that is described in my comment to the answer here:
How to get protobuf-net to flatten and unflatten inherited classes in .Net?
This is now working to my satisfaction.
Note that I haven't talked at all about how the Android app connects to the Windows-based system and how the communications is performed. That was secondary for me - my primary consideration was making the C# class definitions the definitive definitions and having Java classes created from them automatically, and then the object-to-object interchange. (In the event I'm using a home-made TCP/IP communications link, but the actual communications could be anything, probably also web services.)
Hope this helps.
So I did a lot of research on this topic and want to share my findings with you:
One (from a technical point very attractive) option is to use commercial bridges between Java and .Net. For sure, the most popular products are JNBridge and Javonet. Both products seem to be quite easy-to-use, have good support and seem to be very sophisticated. Especially JNBridge already supports bridging between Java and Mono too, which allows the portation to also non-Windows OS, which is one of our main requirements as stated above. Javonet also wants to integrate Mono and is going to release this feature soon. However, both solutions are commercial and one needs to weigh their features against the respective costs. Nevertheless, from a pure technical point of view, they look great and also state to enable very fast communication between Java and .Net (faster than with web services).
Another option is to connect Java and .NET via COM. Since COM is generelly defined platform-independently, this could work on multiple OS. There are lots of open source projects that could be used for such an implementation, such as EZJCOM, J-Interop, JACOB or JCOM. The main restriction (expecially for our project) is that Mono only supports COM-interoperability under Windows (yet). So, this is not really an option for us. But if you want to create Java-.NET interoperability on Windows only, this is a good way.
The straighforward way of integrating Java and C# is to use Java Native Interface (JNI). You can also find manifold implementations that make JNI more easy to use, the most popular one is probably jni4net which seems to be a very active and frequently used project. But there are also others with specific pros and cons, such as Caffeine, Espresso or csjni. Finally, JNI is not 100% platform independet. It is applicable on different platforms, but you have to generate platform-specific code which makes it clearly less usable for our purposes. If you limit your application to Windows, jni4net seems to be a very good choice.
The third option could be to run both the Java and the .Net part within a Common Language Runtime. Ikvm.net is one possible and very popular solution therefore (as mentioned above by Samuel Audet). The drawback of this option is the loss of features and efficiency of the JDK.
The last and surely most generic alternative is to set up webservices between the Java and the .Net world. For this solution, one needs to find appropriate ways for serializing/deserializing objects from/to Java and .Net. There are manifold possible solutions for that available. RenniePet mentioned a sophisticated solution based on Protocol Buffers. Others exist as well such as http://java-cs-bridge.sourceforge.net/. This option might have a potential drawback when considering communication runtime, but may be the way to go for us.
Hope this may help anyone in the future that is confronted with the same problem.
In an environment with both .Net and Java code, it seems that one way to consolidate the two is to use (or at least look at) common interface files in order to share a high level understanding of the business logic in an organization.
Java and .Net are different from a technical perspective, but by sharing interfaces they can focus on common business logic, while leveraging the advantages of OOP.
Is it common in any sense for an organization to implement an architecture based on having interfaces that are applied to both .Net and Java code and would it be possible to create (or does one exist) a syntax converter for interface code, so they can be easily shared by both frameworks? Or are these two frameworks so completely different that it would be counterproductive to share interfaces?
See IKVM:
IKVM.NET is an implementation of Java for Mono and the Microsoft .NET Framework. It includes the following components:
A Java Virtual Machine implemented in .NET
A .NET implementation of the Java class libraries
Tools that enable Java and .NET interoperability
IKVM makes it possible to develop .NET applications that use Java API's. Here's how to proceed:
IKVM comes with an implementation of the Java class libraries in .NET. To use those API's, simply add a reference to IKVM.OpenJDK.ClassLibrary.dll to your Mono / .NET IDE project.
To use other Java API's, you can take one of the following approaches:
Convert the Java API to .NET CIL using ikvmc. This produces a .NET dll that you can reference in your project.
Use the Java reflection API's to dynamically load and execute the Java bytecode using the IKVM bytecode interpreter. For example, your application can load Java bytecode over a network connection and execute it dynamically.
http://www.ikvm.net/
I'm confused about Java portability. If the Java language is portable, why is enum unknown in J2ME?
In C++, it's not important which platform or library is used. The "C++ language" doesn't change in all platforms.
My purpose is developing a Java library that just uses primitive types like int, String, or Array (something like a library for Genetic algorithms). I want to use this library in mobile and desktop applications. But it seems that enum and some other keywords do not exist in all platforms.
So I think I misunderstood the meaning of "Java portability". What does that mean?
There are three flavors of Java: ME for mobile, SE for desktops, and EE for enterprise.
"Java is portable" refers to the SE version. It means that you can run Java bytecode on any hardware that has a compliant JVM.
It doesn't mean that ME is the same as SE is the same as EE. EE has EJBs, but SE and ME don't. That does not make them less portable.
C++ language doesn't change in all platforms.
This statement is not strictly correct. Microsoft adds extensions to their C++ that won't run elsewhere.
ANSI C++ might mean portable source code, as long as you stay away from platform-specific extensions. It does not mean portable bytecode; you may have to recompile and relink.
You want to run genetic algorithms on phones? I know that mobile devices have become pretty powerful, but I'm educated to think that GA would be a server-side functionality. Mobile devices feel more like view to me.
Every hardware architecture has its own somewhat unique instruction set (add ax, bx...) when you build a C++ code, the compiler turns it into a machine code specific to the system/architecture you are working on. So you have to customize and build your code for different architectures for it to work on them.
But What happens in java is, When you build it, it is compiled into a Byte code (as opposed to machine code). And the java virtual machine(JVM) interprets the Byte Code into an instruction that is understandable by the specific architecture you the program is running on.
There is JVM for every major architecture and operating system so the code you write on windows will be interpreted and run on MAC-OS or linux without any source level modification by you.
That is why Java is portable and that is where the Write Once Run Everywhere motto comes from
Java is known as a "portable language" because Java code can execute on all major platforms. What's more, once you've compiled your Java source to "byte-code" .class, those files can be used on any Java-supported platform without modification, unlike many other languages, which require compiling "machine code" for each platform, e.g. a separate ".exe" for 32-bit vs 64-bit environments.
Another meaning of "portable", used mainly in Windows environments, means that the Java run-time environment can be run from any arbitrary location in your filesystem and does not need to be "installed", that is, have important information stored in the Windows registry. This is also true for most Java applications, and enables them to be run from different drive letters, via for example an external storage device like a USB flash drive from any computer without having to install the application first.
Java provides three distinct types of portability:
Source code portability: A given Java program should produce identical results regardless of the underlying CPU, operating system, or Java compiler.
CPU architecture portability: the current Java compilers produce object code (called byte-code) for a CPU that does not yet exist. For each real CPU on which Java programs are intended to run, a Java interpreter, or virtual machine, "executes" the J-code. This non-existent CPU allows the same object code to run on any CPU for which a Java interpreter exists.
OS/GUI portability: Java solves this problem by providing a set of library functions (contained in Java-supplied libraries such as awt, util, and lang) that talk to an imaginary OS and imaginary GUI. Just like the JVM presents a virtual CPU, the Java libraries present a virtual OS/GUI. Every Java implementation provides libraries implementing this virtual OS/GUI. Java programs that use these libraries to provide needed OS and GUI functionality port fairly easily.
See this link
While C and C++ language syntax and semantic are standardised, to write a truly cross-platform application is extremely difficult, unless you limit yourself to extremely basic applications.
There are a number of high level and low level reason for this - from the endianness up to how to interact with the underlying operating system (eg. opening a window).
In addition, C/C++ source code only can be considered portable, not the result of the compilation - resulting executable code and libraries are not portable, with major difference between system architectures (different CPUs for example) and Operating Systems.
Java is a fairly successful attempt to solve both of these issues:
Java does not compile code to assembly, but to a more abstract "bytecode" - a pseudo-assembly language which is "interpreted" or "recompiled on the fly" by the virtual machine (JVM) into assembly. This conversion is usually fairly efficient as bytecode is mostly quite a low level language. Some version of the ARM processor can even execute bytecode natively.
Thus, once a java app is compiled, the result can run on "any" architecture (provided a JVM is available for that machine)
Java comes bundled with a really large runtime library which provides not only an extensive implementation of the most common data structure (implemented in the JVM in the most efficent way for a particular architecture) but also provide an "hardware and software abstraction layer" - you can interact with the system in a standard way while coding, it is the JVM job to translate it into appropriate architecture and OS calls. As an example, Java provides the Swing framework, which allows you to create a GUI in a system independent way - ie, you open a window, and this is translated into Win32/MFC calls in Windows and XWin calls in Linux
Said that, there are different "types" of java:
JavaSE is the most common
JavaME is a cut down version with a limited library and not implementing the Java5.0 language changes
JavaEE for enterprise use, same as JavaSE but with a much larger runtime
Android Java, mostly compatible with JavaSE but with additional functionalities specific to android phones
However, you should be aware that the Java architecture has been designed to allow interoperability, in particularly to allow to mix libraries built for different versions or even different "types"
it means that your java program written on one machine will run on any other machine provided that machine has JVM.
refer to this link.
Portability refers to the ability to run a program on different machines. Running a given program on different machines can require different amounts of work (for example, no work whatsoever, recompiling, or making small changes to the source code). When people refer to Java applications and applets as portable, they usually mean the applications and applets run on different types of machines with no changes (such as recompilation or tweaks to the source code).
I have an open source Java database migration tool (http://www.liquibase.org) which I am considering porting to .Net.
The majority of the tool (at least from a complexity side) is around logic like "if you are adding a primary key and the database is Oracle use this SQL. If database is MySQL use this SQL. If the primary key is named and the database is Postgres use this SQL".
I could fork the Java codebase and covert it (manually and/or automatically), but as updates and bug fixes to the above logic come in I do not want to have to apply it to both versions. What I would like to do is move all that logic into a form that can be compiled and used by both Java and .Net versions naively.
The code I am looking to convert does not contain any advanced library usage (JDBC, System.out, etc) that would vary significantly from Java to .Net, so I don't think that will be an issue (at worst it can be designed around).
So what I am looking for is:
A language in which I can code common parts of my app in and compile it into classes usable by the "standard" languages on the target platform
Does not add any runtime requirements to the system
Nothing so strange that it scares away potential contributors
I know Python and Ruby both have implementations on for the JVM and CLR. How well do they fit my requirements? Has anyone been successful (or unsuccesful) using this technique for cross-platform applications? Are there any gotcha's I need to worry about?
Check out the Fantom programming language. It has its own Java-like/C#-like syntax but can target either the Java VM or .NET CLR.
Their "Why Fantom" page gives a high-level overview of their approach to portability versus dynamic languages running on a VM.
You might have some luck using IKVM.NET. I'm not sure on its exact status, but it's worth a try if you're insistent on running Java code on the .NET Framework. It includes a .NET implementation of the Java base class library, so it seems reasonably complete.
The only other option I might suggest is porting the code to the J# language, a full .NET language (although not first class in the sense that C# or VB.NET is). The language was designed so that the differences with Java were minimal.
If you are thinking about an emdedded approach, you might look at Lua.