JCL for C++
Pages: 12
After taking an excursion from Java for almost 10 years, I've recently gone back to using the JDK as part of my learning how to use Scala.
I've totally forgotten how easy it is to use the JDK!
It's really too bad that C++ doesn't have an equivalent resource. IMHO, a great part of the usefulness of Java has nothing to do with garbage collection or not having pointers. Rather, it's the availability of the JDK. Googling around, I wasn't successful in finding any attempts to port the JDK into C++. I do see OpenJDK and the availability of JDK source code from Java.
If I had more time myself, I would attempt to port the libs into C++ using OpenSource (haven't looked into JDK licensing issues).
Has anyone else considered this or found attempts at porting?
I've totally forgotten how easy it is to use the JDK!
It's really too bad that C++ doesn't have an equivalent resource. IMHO, a great part of the usefulness of Java has nothing to do with garbage collection or not having pointers. Rather, it's the availability of the JDK. Googling around, I wasn't successful in finding any attempts to port the JDK into C++. I do see OpenJDK and the availability of JDK source code from Java.
If I had more time myself, I would attempt to port the libs into C++ using OpenSource (haven't looked into JDK licensing issues).
Has anyone else considered this or found attempts at porting?
Last edited on
Uh... Huh?
http://en.wikipedia.org/wiki/JDK
Operating system.
Compiler.
Linker or related tools (depending on the toolchain).
Doxygen.
Debugger.
Operating system.
Native code disassemblers.
No equivalent concept or already covered by one of the previous tools.
Already covered.
???
Operating system (?).
Something to do with reflection. Not supported by C/++.
There's no equivent tool, AFAIK.
Debugger.
Operating system, presumably.
Operating system, presumably.
I don't know of an equivalent tool, other than possibly OS debugging facilities.
Linker?
Operating system, if a permission system is available.
System monitor.
No equivalent.
System shell.
http://en.wikipedia.org/wiki/JDK
| * java – the loader for Java applications. |
| * javac – the compiler, which converts source code into Java bytecode |
| * jar – the archiver, which packages related class libraries into a single JAR file. This tool also helps manage JAR files. |
| * javadoc – the documentation generator, which automatically generates documentation from source code comments |
| * jdb – the debugger |
| * jps – the process status tool, which displays process information for current Java processes |
| * javap – the class file disassembler |
| * appletviewer – this tool can be used to run and debug Java applets without a web browser |
| * javah – the C header and stub generator, used to write native methods |
| * javaws – the Java Web Start launcher for JNLP applications |
| * extcheck – a utility which can detect JAR-file conflicts |
| * apt – the annotation-processing tool |
| * jhat – (experimental) Java heap analysis tool |
| * jstack – (experimental) utility which prints Java stack traces of Java threads |
| * jstat – (experimental) Java Virtual Machine statistics monitoring tool |
| * jinfo – (experimental) This utility gets configuration information from a running Java process or crash dump. |
| * jmap – (experimental) This utility outputs the memory map for Java and can print shared object memory maps or heap memory details of a given process or core dump. |
| * idlj – the IDL-to-Java compiler. This utility generates Java bindings from a given Java IDL file. |
| * policytool – the policy creation and management tool, which can determine policy for a Java runtime, specifying which permissions are available for code from various sources |
| * VisualVM – visual tool integrating several command-line JDK tools and lightweight performance and memory profiling capabilities |
| * wsimport – generates portable JAX-WS artifacts for invoking a web service. |
| * jrunscript – Java command-line script shell. |
Perhaps you are misunderstanding what I meant. I don't care about the Java compiler, linker, etc... I only care about the application library.
For example, it would be nice if I could do the following from C++ (and linking the proper libraries, of course):
I do not care about how it's implemented - just having access to the equivalent functionality would be nice.
For example, it would be nice if I could do the following from C++ (and linking the proper libraries, of course):
#include <javax/swing/JTable.hpp> I do not care about how it's implemented - just having access to the equivalent functionality would be nice.
Last edited on
Oh, you mean the JCL, not the JDK.
Some compilers implement pragma directives that let you link libraries directly from the source. The reason this is usually not implemented is (AFAICT) because it's not very useful when used in distributable, portable sources. In Linux, for example, you don't link directly to libsome-1.0.5.4.a. You call a command that returns the proper linker flags (-L/usr/lib -lsome).
It's a solution to an inexistent problem.
Also, what Bazzy said.
| linking the proper libraries |
It's a solution to an inexistent problem.
Also, what Bazzy said.
I was thinking about using Qt or wxWidgets (last C++ toolkits I've used are XView/Motif/X-Windows) with C++. I have used Ultimate++, which actually has a nice GUI toolkit, but that's a little bit off target from my OP.
As an application developer, having an unified JDK behind me is extremely useful.
When programming in C++, it's usually nice having choices of libs, but most of the time, it would be better to have a standard library behind me that is easy-to-use and just works. I mean sql, socket, threading, and lots of other functionality, etc...
Yes, in C++ there is STL, iostreams, POSIX threads, boost, etc, but it's a mish-mash of libs at all different levels of abstraction. Even a single library like boost is a motley collection of libs.
I am not complaining about C++, only wistfully thinking how nice it would be to have something like a JDK behind C++. It's not even necessary to try to design something better than the JDK - just reverse-engineering it so we have the functionality in C++ would be great.
As an application developer, having an unified JDK behind me is extremely useful.
When programming in C++, it's usually nice having choices of libs, but most of the time, it would be better to have a standard library behind me that is easy-to-use and just works. I mean sql, socket, threading, and lots of other functionality, etc...
Yes, in C++ there is STL, iostreams, POSIX threads, boost, etc, but it's a mish-mash of libs at all different levels of abstraction. Even a single library like boost is a motley collection of libs.
I am not complaining about C++, only wistfully thinking how nice it would be to have something like a JDK behind C++. It's not even necessary to try to design something better than the JDK - just reverse-engineering it so we have the functionality in C++ would be great.
| Oh, you mean the JCL, not the JDK. |
Yes, you are right - I was too ambiguous - the JDK includes too many other components.
EDIT: changed the Topic from JDK to JCL
Last edited on
It doesn't make much sense, the Java libraries are like C++ libraries. The only difference is that JCL comes with all the other tools.
boost is a natural expansion of the standard library and other libraries ( both for C and C++ ) mix quite well with the standard library
boost is a natural expansion of the standard library and other libraries ( both for C and C++ ) mix quite well with the standard library
| It doesn't make much sense, the Java libraries are like C++ libraries. |
To a certain extent, but not exactly.
Looking at a very practical stand-point, in general, the time required to get something working in Java takes much less time than doing the same in C++. I am convinced that main reason for this is the ease-of-use of the JCL.
There are other things that are not so nice. For example, I am coding in Scala (using the JCL) under the Netbeans IDE. It's slower because I haven't figured out the vim bindings and compiling is much, much slower than gcc. However, getting things to work on an application-level is much more pleasant, due to the JCL.
I guess my tilt gets me to try languages like D, which does have a JCL-like library in Phobos. Maybe I will have try D/Phobos again, once D 2.0 settles down...
Last edited on
| kfmfe04 wrote: |
|---|
| Has anyone else considered this or found attempts at porting? |
Good for you to have 10 years of programming, it would be nice not to get old while learning a langauge eh.
I think I know what you feel about this. IMO having a rich library that is standard or common is great. I mean like every programmer has the same knowledge when they talk or discuss, C++ world is far away from that world.
BTW please PM me if ever you release some Java API port to C++. I was thinking like wrapping wxWidgets and Boost library and provide a Java like API for C++ programmers :)
PS: what does JCL mean? Quick google search says Job Control Language
| Oh I see. I refer to them as Java API but now I know. |
No worries, blackcoder41 - I've never heard of the JCL term until these guys pointed it out.
I knew someone else must've thought of this already (there are very few new ideas).
Check out the C++ snippet at the end of the gcj article:
http://en.wikipedia.org/wiki/Gcj
http://www.linuxjournal.com/article/4860
http://www.linuxjournal.com/article/7413
http://stackoverflow.com/questions/354854/anyone-here-have-any-experience-using-gcjs-cni-for-java-external-libraries
Of course, I wouldn't expect a call from C++ to be as seamless as a call from Scala, but at least you wouldn't have to reverse engineer the entire Java platform!
Scala is easy enough to use and the compiles not too slowly, so I think I'll stick with Scala for now.
Last edited on
I did not mean reverse engineer in a legal sense.
I meant reverse engineer in the sense of keeping the APIs the same, and the functionality the same, without caring about keeping the implementation the same.
I meant reverse engineer in the sense of keeping the APIs the same, and the functionality the same, without caring about keeping the implementation the same.
With Java Native Interface you can call Java functions from other languages. It is very cumbersome, but with some practice one can use it without problems.
http://en.wikipedia.org/wiki/Java_Native_Interface
http://en.wikipedia.org/wiki/Java_Native_Interface
@kfmfe04
Yeah I have tried GCJ before, but it's not yet complete. I'll give it another try some other time. BTW compling eclipse natively was epic.
@R0mai
I know about it already but thanks anyway.
Yeah I have tried GCJ before, but it's not yet complete. I'll give it another try some other time. BTW compling eclipse natively was epic.
@R0mai
I know about it already but thanks anyway.
closed account (S6k9GNh0)
Java Native Interface is usually not that convenient for use. So far, the only thing I've found it useful for is low-level APIs (OpenGL, DX), and for starting a Java application through an executable (which is rather pointless most of the time). Even then, it's somewhat complex and not really that fun to play with.
Pages: 12