Are there any good ways to define interfaces/class hierarchies in a non language specific fashion and then generate corresponding source code in specified languages? In particular, I need to target both Java and C# for a fairly comprehensive API I am creating. I recall at one point seeing a post here on SF where an answer mentioned a programming language that 'compiled' to other languages-- but I have not been able to find the post. That language may be a solution for what I'm trying to do.
Thanks,
Andy
Have you considered UML? It's easy to find code-generators from UML for lots of different languages (Eg. this one can generate C#, Java and VB.NET code), but you might want to carefully evaluate if it's the right choice for you. As a standard, it has come in for substantial criticism over the years.
Lots of ways of doing something like what you want.
For example you could look at using an interface definition language (IDL). Corba's IDL allows you to declare objects & interfaces in a language neutral way. These idl files are then run through an IDL compiler which outputs the appropriate classes, headers, stubs, proxies etc. for the language of your choice.
For example IIOP.NET is an implementation of Corba for C#. I have no idea how good it is, but it would have an IDL compiler that spits out C# classes. Java has an IDL compiler called idlj as part of the JDK.
In theory therefore you could have C# and Java implemented from the same interfaces & classes.
Another way of doing something similar would be to utilise a UML tool that can generate source code from a model.
Another alternative would be to use something like WSDL / XSD to define your interfaces & types, and generate stubs from that.
Take a look at IKVM.NET. With it, you can write your program in Java (or a JVM language) and transform it into a .NET assembly. So you'll have both a JVM and a .NET version of your program.
Related
I'm using CodeDom compiler to dynamically compile user defined scripts. We're working with C# scripts as standard, but I was wondering if there was a way how to support all CLI languages. To do that I'd have to detect used CLI language that was used in this particular source code.
Is there some elegant way how to detect only CLI languages from the source code?
Thanks
There are only 3 languages for which the framework provides a CodeDomProvider: C#, JScript and VB. Therefore, if the framework provides any direct method to parse "any language", it can only support these 3 languages. I don't think it does.
You may want to try to parse your code with all three implementations of CodeDomProvider, and keep the first that succeeds. It will take a dozen of lines of code.
I think it might be your best try.
Documentation for CodeDomProvider: http://msdn.microsoft.com/en-us/library/ds075xdx.aspx
Documentation for CodeDomProvider.Parse: http://msdn.microsoft.com/en-us/library/system.codedom.compiler.codedomprovider.parse%28v=vs.110%29.aspx
It is possible to make a library that can be used in many languages? Or at least a library that can be used in several languages.
If so, what documentation do you recommend me to achieve this?
Yes, by providing a C interface to it. Most if not all mayor languages provide the ability to bind to C functions.
In .NET, any assembly you create can be used by any other .NET language. So if you create a library in C#, you can make use of it in J#, C++.NET, VB.NET, etc.
The Java Virtual Machine(JVM) can run many languages (not just Java).
Any library written in one of these languages can be called from another language on the list.
SWIG can be used to automatically create many of the language wrappers everyone's talking about here. In many cases, the wrapper has two components: a C++ one that is rolled into your DLL, and one written in the language.
A C library will be accessible from the most languages in the most environments.
However, you ask in your comment how to define classes for use in multiple languages. C has no classes. If you want an object-oriented API, you can:
Define Java classes for use with languages running on the JVM.
Define .NET classes for use with languages running on .NET.
One option, depending on what you're writing, may be to write a single implementation in C, then expose it via separate wrappers in C++, Java and .NET.
A library can be created that can be used by more than one language. One of the issues is the calling convention.
A calling convention defines how parameters are passed to a function as well as any setup required. For example, one convention may specify that parameters are passed from right to left (the right most parameter first). Some conventions say to pass values in the N registers; others demand that all parameters passed by address (pointer).
Some calling conventions may decrement a stack pointer, which is used by the function, for storing parameters. Some may not even use a stack.
Yes, a library can be used by more than one language. The trick is how to write code in a language to properly access functions in the library.
I'd like to know good strategies for deploying a domain-specific-language which must run under at least 2 languages (Java, C#) and probably more (Python, and possibly Javascript).
Some background. We have developed and deployed a domain-specific language currently written in C#. It's deployed though a series of method calls whose arguments are either common language primitives (string, double, etc.), Collections (IEnumerable, HashSet, ...) or objects in a domain-specific library (CMLMolecule, Point3, RealSquareMatrix). The library is well tested and the objects have to comply to a stable deployed XML schema so change will be evolutionary and managed (at least that's the hope).
We hope the language will become used by a wide and partially computer-literate community, used to hacking their own solutions without central control. Ideally the DSL will create a degree of encapsulation and produce the essential functionality they need. The libraries will manage the detailed algorithms which are many and varied but fairly well known. There's a lot in common with the requirements of the DSL in Domain-specific languages vs. library of functions.
I'd appreciate ideas on the best architecture (clearly once it's deployed we cannot easily backtrack). The choices include at least:
Creation of an IDL (e.g. through CORBA). The W3C did this for the XML DOM - I hated it - and it seems to be overkill
manual creation of similar signatures for each platform and best endeavour to keep them in sync.
Creation of a parsable language (e.g. CSS).
declarative programming in XML (c.f. XSLT). This is my preferred solution as it can be searched, manipulated, etc.
Performance is not important. Clarity of purpose is.
EDIT There was discussion as to whether application calls contitute a DSL. I have discovered Martin Fowler's introduction to DSLs (http://martinfowler.com/dslwip/Intro.html) where he argues that simple method calls (or chained calls) can be called a DSL. So a series like:
point0 = line0.intersectWith(plane);
point1 = line1.intersectWith(plane);
midpoint = point0.midpoint(point1);
could be considered a DSL
There seems to be some ambiguity in the question between language and library. The terms "internal DSL" and "external DSL" are useful, and I think are due to Martin Fowler.
An "external" DSL might be a standalone command-line tool. It is passed a string of source, it parses it somehow, and does something with it. There are no real limits on how the syntax and semantics can work. It can also be made available as a library consisting mostly of an eval-like method; a common example would be building a SQL query as a string and calling an execute method in an RDBMS library; not a very pleasant or convenient usage pattern, and horrible if spread around a program on a large scale.
An "internal" DSL is a library that is written in such a way as to take advantage of the quirks of a host (general purpose) language to create the impression that a new language can be embedded inside an existing one. In syntactically-rich languages (C++, C#) this means using operator overloading in ways that seriously stretch (or ignore) the usual meanings of the operator symbols. There are many examples in C++; a few in C# also - the Irony parser toolkit simulates BNF in a fairly restrained way which works well.
Finally, there is a plain old library: classes, methods, properties, with well-chosen names.
An external DSL would allow you to completely ignore cross-language integration problems, as the only library-like portion would be an eval method. But inventing your own tool chain is non-trivial. People always forget the huge importance of debugging, intellisense, syntax highlighting etc.
An internal DSL is probably a pointless endeavour if you want to do it well on C# and Java. The problem is that if you take advantage of the quirks of one host language, you won't necessarily be able to repeat the trick on another language. e.g. Java has no operator overloading.
Which leaves a plain old library. If you want to span C# and Java (at least), then you are somewhat stuck in terms of a choice of implementation language. Do you really want to write the library twice? One possibility is to write the library in Java, and then use IKVM to cross-compile it to .NET assemblies. This would guarantee you an identical interface on both of those platforms.
On the downside, the API would be expressed in lowest-common-denominator features - which is to say, Java features :). No properties, just getX/setX methods. Steer clear of generics because the two systems are quite different in that respect. Also even the standard way of naming methods differs between the two (camelCase versus PascalCase), so one set of users would smell a rat.
If you are willing to re-describe your language using ANTLR you could generate your DSL interpreter in multiple languages without having to manually maintain them including all of the languages you mentioned plus more.
Antlr is a parser/lexer generator and has a large number of target languages. This allows you to describe your language once, without having to maintain multiple copies of it.
See the whole list of target languages here.
Although I do not want to promote my own project too much, I would like to mention PIL, a Platform Independent Language, an intermediate language I have been working on to enable the support of multiple software platforms (like Java, Python, ...), specifically for external DSLs. The general idea is that you generate code in PIL (a subset of Java), which the PIL compiler can then translate to one of many other languages, currently just Java or Python, but more will be added in the future.
I presented a paper about this on the Software and Language Engineering conference about 2 days ago, you can find a link to the publication of the PIL website (pil-lang.org), if you're interested.
Ability to escape to the implementation language in the event you need to do something that just isn't supported by your DSL, or for performance reasons (though I realize that isn't a priority).
I am researching DSL for implementing rules in a rule engine in C#, some of the rules are really complex and may change significantly in the future, so being able to escape out to C# is really useful. Of course this breaks cross-platform compatibility, but it is really just a way of hacking around edge cases without having to change your DSL.
You'd be best off writing the library in C (or some language like rpython which will generate C-code) and then using SWIG or similar to generate the language specific bindings for C#, Java Python etc.
Note that this approach won't help if you are using Javascript in the browser - you'll have to write the javascript library separately. If you are using javascript through Rhino, then you'd be able to just use the Java bindings.
It is possible to interpret JavaScript from inside a Java-program directly using the script engine, and apparently also from C#. Python can be run on the JVM and the .NET engine.
I would suggest that you investigate these options, and then write your library in a common subset of the execution paths available to the language you choose. I would not consider writing it in a language which requires post translation and conversion, since you introduce a step which can be very, very difficult to debug in case of problems.
I would like to expand on Darien's answer. I think that ANTLR brings something to the table that few other lexer/parser tools provide (at least to my knowledge). If you would like to create a DSL which ultimately generates Java and C# code, ANTLR really shines.
ANTLR provides four fundamental components:
Lexer Grammar (break down input streams into tokens)
Parser Grammar (organize tokens into an abstract syntax tree)
Tree Grammar (walk the abstract syntax tree and pipe the metadata into a template engine)
StringTemplate (a template engine based on functional programming principles)
Your lexer,parser, and tree grammars can remain independent of your final generated language. In fact, the StringTemplate engine supports logical groups of template definitions. It even provides for interface inheritance of template groups. This means you can have third parties use your ANTLR parser to create say python, assembly, c, or ruby, when all you initially provided was java and C# output. The output language of your DSL can easily be extended as requirements change over time.
To get the most out of ANTLR you will want to read the following:
The Definitive ANTLR Reference: Building Domain-Specific Languages
Language Implementation Patterns: Create Your Own Domain-Specific and General Programming Languages
I have a small (~2000 lines of code) class that I would like to use from both java & .NET. There are several approaches to do this - among them wrapping the class as a service, using some interop voodoo, or duplicating the code to both C# & java.
Do you know an out-of-the-box tool that accomplishes the latter - takes a simple C# class with no dependencies and converts it to an equivalent java class?
IKVM.NET does pretty good job in taking a jar file and compiling it to a managed .NET assembly.
If it is small (or in fact, even if it is large), I'm not sure of the wisdom of mechanical translation tools; I've simply never had much joy with them. However, one option would be to write the .NET code in J#.
But I stress - if it was me, I'd manually port it between the two manually and maintain them separately. Most of the time the differences aren't huge - signed bytes, the boxing differences, etc. Of course, anything with delegates will need changing - and captured variables work differently, etc etc.
There used to be a COM bridge and you can register C# assemblies for use in COM with regasm.exe or visual studio.
It's not really what you asked for, but I would just create a simple C# to Java translator.
The differences are not that huge and you seem to be the author of the source so you can avoid nasty constructs that are quite difficult to translate. That way your translator would be quite simple. I would go from C# to Java because C# is more expressive, and you can emulate almost all the C# functions in Java.
Actually cs2java seems to do just that.
This is list of tools I know. Sharpen or j2cstranslator looks like good options.
I'm porting a Java library to C#. I'm using Visual Studio 2008, so I don't have the discontinued Microsoft Java Language Conversion Assistant program (JLCA).
My approach is to create a new solution with a similar project structure to the Java library, and to then copy the java code into a c# file and convert it to valid c# line-by-line. Considering that I find Java easy to read, the subtle differences in the two languages have surprised me.
Some things are easy to port (namespaces, inheritance etc.) but some things have been unexpectedly different, such as visibility of private members in nested classes, overriding virtual methods and the behaviour of built-in types. I don't fully understand these things and I'm sure there are lots of other differences I haven't seen yet.
I've got a long way to go on this project. What rules-of-thumb I can apply during this conversion to manage the language differences correctly?
Your doing it in the only sane way you can...the biggest help will be this document from Dare Obasanjo that lists the differences between the two languages:
http://www.25hoursaday.com/CsharpVsJava.html
BTW, change all getter and setter methods into properties...No need to have the C# library function just the same as the java library unless you are going for perfect interface compatibility.
Couple other options worth noting:
J# is Microsoft's Java language
implementation on .NET. You can
access Java libraries (up to version
1.4*, anyways).
*actually Java 1.1.4 for java.io/lang,
and 1.2 for java.util + keep in mind that J# end of
life is ~ 2015-2017 for J# 2.0 redist
Mono's IKVM also runs Java on
the CLR, with access to other .NET
programs.
Microsoft Visual Studio 2005 comes
with a "Java language conversion
assistant" that converts Java
programs to C# programs
automatically for you.
One more quick-and-dirty idea: you could use IKVM to convert the Java jar to a .NET assembly, then use Reflector--combined with the FileDisassembler Add-in--to disassemble it into a Visual C# project.
(By the way, I haven't actually used IKVM--anyone care to vouch that this process would work?)
If you have a small amount of code then a line by line conversion is probably the most efficient.
If you have a large amount of code I would consider:
Looking for a product that does the conversation for you.
Writing a script (Ruby or Perl might be a good candidate) to do the conversion for you - at least the monotonous stuff! It could be a simple search/replace for keyword differences and renaming of files. Gives you more time/fingers to concentrate on the harder stuff.
I'm not sure if it is really the best way to convert the code line by line especially if the obstacles become overwhelming. Of course the Java code gives you a guideline and the basic structure but I think at the end the most important thing is that the library does provide the same functionality like it does in Java.