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/
Related
I am trying to develop NetLogo model (consumer research), but I would like more control over what agents (turtles) are and what they can do, therefore I would like to write code in Java, import Java libraries, possibly, use rules engine and so on. Is that possible in NetLogo?
If not, then what other agent modelling frameworks with Java programming capabilities are?
It is possible with NetLogo using the Extensions API. With this API, you write your overall model in NetLogo, making calls into your Java-based routines as needed. (You cannot call a Java library directly from NetLogo code; rather, you write an extension that exposes the routines in that library as NetLogo primitives, and then you use those primitives in your model.) A look at the NetLogo extensions download page should give you an idea of the diverse sorts of things are possible with this API.
See also: Integrating NetLogo and Java : when should we think about this integration as a good option?.
Two notable agent-based modeling frameworks where you write your entire model in Java are Repast and MASON.
As an experiment I am working on a small platform for Java applications (client server, P2P etc.) which I would like to be able to use from both Java and Scala. And possibly also from Groovy, jRuby etc.
I know that Scala can call easily into Java, but that Java cannot as easily call back into Scala. I don't know how this is working in jRuby and Groovy.
My initial thought was to implement the platform in Java, and then see if I could make it available to other languages. However, the platform may include starting threads which call components that implement certain Java interfaces. Would it be possible to pass e.g. a factory implemented in Scala, but which implements a Java interface, to a Java component and have that Java component call the Scala factory?
What are your recommendations in general for implementing such a cross language platform?
I am by no means an expert and have never done such a cross-language project (just minor Java/Scala).
But I would suggest implementing it in the language:
you know best
makes you most productive
ensures the most maintainability
In my case it would be Scala.
So what I would do is define the API in the form of Java interfaces, which I would then implement in Scala (probably I would need to convert Scala/Java collections back-and-forth, but that would be an implementation detail).
That way you make sure that other JVM languages can interact with your API, and you implement it in whatever language you are best.
Java can call Scala as easy at the other way around,
With eclipse you need to install 'Scala IDE' from the 'eclipse market place'
and configure the compiler to 'Scala Then Java' option in Properties->'Scala Compiler'-> 'Build Manager'-> compileorder.
P.s. you also need to add Scala nature to the project.
Would it be possible to pass e.g. a factory implemented in Scala, but which implements a Java interface, to a Java component and have that Java component call the Scala factory?
Even if it were so, switching to Scala would not solve the problem, as then jRuby would have even more problems to access that component.
Actually, all listed languages declare interoperability with Java, but not with other languages. So first design goal is, your platform should be Java-compatible in all its API, though some components could be written in other languages - but so that it is cannot be seen by API users. The easiest way to make it so is to write all in Java. Besides, I recommend Java because features of "more advanced" languages has their reverse side - one innocent-looking line of code can consume enormous amounts of CPU time or memory.
I am developing a Java application in which I need to call some C++ functions (from Google Talk library libjingle) . The objective is to run it all on Google App Engine (which only supports Python or Java).
How can I do this?
You need to define native methods in your java code for whatever you want to be implemented in C++ and directly access your native code. Then you run javah on your code and it will generate the C header files for you and you'll need to provide C++ implementations.
The native methods you can call from your Java code like any other methods and still they'll have their implementation written in C++ and talking to whatever other native library directly.
You then need to set the java.library.path system property to include the shared C/C++ libraries that you require: the google library and your own JNI implementation library would be required in this case.
If the library has C bindings through a DLL/SO, I usually prefer writing wrappers in Java using Java Native Access (JNA) rather than writing the bindings in C/C++ using the Java Native Interface (JNI). The former is easier to manipulate as the JNI access to Java objects is a real pain in the neck. However, it's not as obvious to wrap C++ classes using that API.
You might also want to look into the Simplified Wrapper and Interface Generator (SWIG) for automating part of this process!
You can't run native code on App Engine - only JRE code. If there's no avoiding the native code, you'll need to run this part of your app on another system, and call it from your App Engine app - or use the built-in XMPP API, in this case.
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.
I'm supporting a large system written in C++ and we now have a requirement for our application to talk with a third party system which only provides a JTAPI interface. It would appear that I am stuck writing a JTAPI proxy in Java that talks JTAPI on one side and some more language-neutral API on the other. However, this feels like it should be a solved problem and I don't want to unnecessarily re-invent the wheel. What is the best solution to interface to JTAPI from C++? Does such a proxy already exist, or perhaps is there a solution that does not require a Java layer?
This article shows a way to call Java objects from C++.
You can also think of embedding the JVM in your C++ program. This page talks about a possible way to do this. Also see: Embed Java code into your native apps
If your C++ system provides an API, then the easier approach is to write a Java program that wraps the C++ API (using JNI) and call the JTAPI library from there.