Opinion: Do you want easy access to native code?

Discussions

News: Opinion: Do you want easy access to native code?

  1. Opinion: Do you want easy access to native code? (65 messages)

    There has been talk that a group at Sun has come up with a nice clean way to slurp up a header file, and have access to the native code. It is reportedly four times faster than JNI, and without the other head-aches. There is a lot of native support in Microsoft .NET, but do you need it in Java? Or, do you think that we should stay portable?

    Threaded Messages (65)

  2. YES![ Go to top ]

    I could use that right now with something I'm working on. The implementations of a given class are built to be pluggable. I currently have a pure-Java implementation, but I want a native-code option as well for increased performance.
  3. YES!!![ Go to top ]

    Portability is nice, but interoperability is critical.
    Every commercial Java application that I have developed has incorporated JNI (and it has always been a pain).
  4. Java is mature enough that developers understand the value of making their software portable. But there are many times, especially when writing client-side applications, that you need access to native libraries.
  5. Native access to USB Drivers, Print Drivers, Network Card, Native Bluetooth Drivers, sound and video cards, Drives etc.

    Then you we can have java based system software applications!
  6. Please no![ Go to top ]

    And that is not a matter of portability.
  7. Please no![ Go to top ]

    And that is not a matter of portability.

    Then what is the reason behind your oppinion?

    To me more power is more power. I don't use every library in J2EE/J2SE but I'm glad for what's there when I may need it.
  8. use std c lib[ Go to top ]

    u always can still portable if u use standard c lib calls
  9. I'd personally love to see better native support for .Net components and C in the JVM.

    Why should Java developers have to leave the Java platform & switch language and toolset just to get great .Net integration (for those rare occasions you really wanna twiddle with Excel) and C integration (for when you need to integrate with some legacy C stuff).

    By not openly embracing great support for .Net and C we'd be reducing the likeihood folks will have to jump over to the dark side...

    James
    Protique
    Enteprise Open Source
  10. Join the Darkside![ Go to top ]

    By not openly embracing great support for .Net and C we'd be reducing the likeihood folks will have to jump over to the dark side...

    Let them jump. :)

    People started working in Java and producing Java applications only because Java as it is now is a good tool for what it gives and what it has given.

    Java had success because SUN had the balls to keep it a consistent platform.

    Java does not need to be shaped to be "the golden hammer", or the "one ring to rule them all" or "one solution to fit them all". Windows tried to do it, and Windows, outside the desktop environment, now faces competition from cheap software like Linux and Apache. Internet Explorer and Outlook in evolution now are outpaced by thirdparty software like Mozilla.

    Microsoft tried to do everything at the same time, becoming as big as the former Soviet Union. If Microsoft does not realize that she needs to make her stack more independent, then Microsoft will eventually suffer the same fate and will dissolve. IBM instead worked with many different technologies, and now IBM can sell its PC division but still be IBM: an healty company wich does software development, consulting, tools building and even research. But IBM's software is more interoperable, more fragmented.

    On another side... I do not miss the times [1] where I could not run all the videogames that were produced on the market because I had a Commodore 64 and not an MSX or a Spectrum or an Atari 2006 or an Intellivision...

    And I long for a future where I am certain that I will be able to use tools and produce GOOD code that will satisfy the largest possible audience, beginning from myself and continuing to paying customers (then comes everyone else).

    JNI, unfortunately, is a stumbling block in that path.

    [1] If I miss them, I miss them only because I was younger :)
  11. JNI Made EZ[ Go to top ]

    There's an open source project called JACE that actually makes C++/Java integrations pleasant. It runs on Windows, Solaris, HP-UX, and Linux. It's been around for years, and is stable and well supported.

    You can find the site here...

    http://reyelts.dyndns.org:8080/jace/release/docs/index.html

    The author wrote an article that gives a good overview of the challenges of JNI and what JACE does to adress them. You can find that here.

    http://www.javaworld.com/javaworld/jw-05-2002/jw-0510-integrate.html
  12. YES[ Go to top ]

    The lack of a convenient facility for easy integration of C/C++ libraries is a major shortcoming of Java and a major advantage of .NET over Java.

    For example, it is a major shortcoming of Java that Java can't be easily used to consume scientific numeric analysis libraries, and it is a major advantage of .NET over Java that .NET can be used to consume such libraries.

    For another example, it is a major shortcoming of Java that it can't be used to easily leverage powerful OS facilities such as Apple's upcoming Spotlight API.

    Providing the ability to easily consume C/C++ libraries would not reduce Java's *potential* for portability. It would still be just as possible to write cross-platform, non-C/C++-consuming Java for those who need to do so.
  13. Java and Cocoa[ Go to top ]

    Java and cocoa (objtive-c) are already working almost transparent together on os-x
  14. More details[ Go to top ]

    Simplifying JNI with less overhead would definitely be a boon to many Java developers. It looks like DirectByteBuffer is turning out to be a good example of this kind of improvement.

    However, the devil is in the details. I'm quite leary of something that claims that it can just "slurp" header files. How is this different, for example, from Swig, which requires it's own language with all sorts of nuances just to be able to deal with crazy C++'isms? Or does this tool just not support C++ at all? Where's the beef?

    God bless,
    -Toby Reyelts
  15. Everything degenerates[ Go to top ]

    Well, it was fun while it lasted, but it looks like mobocracy and mediocrity will debase Java the way it has debased everything else it has touched--HTML becomes a programming system, XML swells to bursting with incomprehensibility, and Java degenerates into platform-specific code!

    Hasn't anyone heard the idea that you should pick the tool to fit the job? If you want platform-specific code, use a tool that's close to the platform.

    -- Techno-curmudgeon
  16. NO[ Go to top ]

    "pick the tool to fit the job?"

    Exactly.
  17. Pick the tool[ Go to top ]

    Hasn't anyone heard the idea that you should pick the tool to fit the job? If you want platform-specific code, use a tool that's close to the platform.

    That's the entire point. There are those of us who would prefer to use Java for the most part in our large systems, but there are small pieces of the system that must be coded in another language (most commonly C or C++), because it is the best tool (often the only tool), for that piece. We use JNI. We'd prefer that there be easier and better performing means to accomplish what we need to do.

    God bless,
    -Toby Reyelts
  18. Re: Everything degenerates[ Go to top ]

    Hasn't anyone heard the idea that you should pick the tool to fit the job? If you want platform-specific code, use a tool that's close to the platform.

    If I have a 99% solution where the 1% is lacking because of a native code restriction, why should I toss the 99% for the sake of the 1%? How reasonable is that? Downright impractical if you ask me.

    We already have JNI, so why not make it easier to use? How does this hurt anything?

    I don't believe that we've managed to get this far with "100% Java" applications because JNI was simply "too hard". Look at SWT, look at OpenGL bindings, look at the Type 2 JDBC drivers. Making JNI easier isn't pushing Java closer to the precipice of the abyss. It is simply making Java easier to use, and if nothing else may well ENCOURAGE Java use in areas where having a simple Foreign Function Interface is important (like, say, to a high speed game engine with the rest of the app in Java, or in the embedded market).

    I don't see what the stink is.
  19. YES[ Go to top ]

    Java should be easy to integrate with native platforms and other technologies like dot-net. If Java will return to its initial course of being business layer glue technology it will be very very nice.
  20. YES, and this is not about performance[ Go to top ]

    ... as someone else suggested. It's about reusability. Suppose you have a complex library written in C to perferm business related operations. Now you have to build a web interface to that system, and Java is the perfect tool for this job. I have headaches just remembering the pain it was to make call to the native library.

    Folks, remember that cross platform isn't the only "fitting point" for Java. Java is the best tool for many jobs even when you don't require or want platform independence.
  21. Use JNIWrapper (www.jniwrapper.com)
    It is a very painless way to talk to native code. Support is great and it's cheap.

    -Pete
  22. Use JNIWrapper (www.jniwrapper.com)It is a very painless way to talk to native code. Support is great and it's cheap.

    It still uses slow JNI under the covers. If Sun wants to offer an easy to use alternative to JNI that is "4 times" faster than JNI, I can't see why anyone would have a complaint.

    It's not as if JNI doesn't already exist. So this new alternative would be aimed at making current JNI users lives easier - and add a performance boost. These "users" of JNI includes BEA's Weblogic, Oracle, IBM's WebSphere which all have some (perhaps optional) high performance features that depend on JNI.

    And as someone pointed out, it's not as if Java developers don't already realize that writing portable Java code is a "good thing".
  23. Not for performance[ Go to top ]

    To me, Native access only should be used for hardware and OS spesific operations (like registry access), NOT for performance related operations.. Becuase it does not worth. people still did not get that java is fast enough. using unnecessary native code in java project just kills portability and maintainability (i dont know if there is a word like that, sorry for my english). if it is easily posible, do it java way..
  24. To me, Native access only should be used for hardware and OS spesific operations (like registry access), NOT for performance related operations.

    I would say easy Native access should be used for REUSABILITY. To avoid rewriting everything in Java: databases, mail servers, calculation routines etc.
     
    Wheel reinvention prevention.
  25. +1

    exactly the point i was going to make :)
  26. To me, Native access only should be used for hardware and OS spesific operations (like registry access), NOT for performance related operations.

    That's all very well if you have the option to write everything in Java, but what about those situations where you HAVE to link to some legacy code and the only way to do it is C? The fact is that there are occasions when you just have to use JNI. I'd still recommend keeping JNI use to a minimum, but sometimes you just have to bite the bullet.
  27. Multiple performance issues[ Go to top ]

    I was going to post a comment about JNI and performance, but it became too long and detailed, so I've posted it up on my blog, http://jroller.com/page/rreyelts/20041216#jni_and_performance

    Suffice it to say that JNI is still an appropriate venue for certain performance requirements.

    God bless,
    -Toby Reyelts
  28. re: Not for performance[ Go to top ]

    To me, Native access only should be used for hardware and OS spesific operations (like registry access), NOT for performance related operations.. Becuase it does not worth. people still did not get that java is fast enough. using unnecessary native code in java project just kills portability and maintainability (i dont know if there is a word like that, sorry for my english). if it is easily posible, do it java way..

    No language is perfect for every task, and some real-world tasks need performance help. For instance, do you think 3D ops shouldn't make calls out to accelerated OpenGL libraries? Many people also prefer the responsiveness of SWT over SWING (I admit swing has improved). Neither case sacrifices portability. The Java JVM can kick butt when used right, but the JVM alone is not appropriate for all tasks, performance, capability, legacy or otherwise.
  29. It was kept difficult on purpose[ Go to top ]

    I heard lots of complaints about JNI over the years, and the discussions often ended up revealing that some influential Java architects preferred it not be "too easy" to interop with native code in that way. The idea being, if you're doing that, "you're doing it wrong."

    This is a tough question, and I don't think we should take the easy way out. Just because it makes it easier to do JNI "only when we need it" doesn't mean it's automatically a good idea to just throw it in. If the end result is that Java apps are _in reality_ no longer portable, then isn't the right solution to move away from the VM more coherently, instead of pussyfooting around it?
  30. It was kept difficult on purpose[ Go to top ]

    If the end result is that Java apps are _in reality_ no longer portable, then isn't the right solution to move away from the VM more coherently, instead of pussyfooting around it?

    That actually makes sense. Take Linux applications as an example: many of them get compiled on all Unix flavors and get installed on wide variety of hardware. Sometimes compile-install procedure with all the dependencies is fully automatic and transparent (gentoo).

    I say for long time that Linux is Virtual Machine that shields developers from hardware very effectively and another VM (JVM) atop of it seems overkill.
  31. It was kept difficult on purpose[ Go to top ]

    I say for long time that Linux is Virtual Machine that shields developers from hardware very effectively and another VM (JVM) atop of it seems overkill.

    Thank you for making this observation. I totally agree.

    I use Java and .NET because they are similar to C/C++ but have garbage collection. If the C/C++ language designers, standards committees and the gcc folks would just agree upon and ship an optionally-used garbage collection extension for C/C++, then I probably wouldn't bother with Java or .NET. I'd just be a Linux C/C++ programmer.

    Linux is the VM.

    Doug
  32. YES!!!![ Go to top ]

    The Sooner the better. Let us (developers & architects) make the decision of when to be portable and when we need native access.
  33. NO[ Go to top ]

    It will encourage developer to sacrifice portability. And hoenstly it is hardly 5% of the time when you really want to access native code in the whole develoment life cycle. And if you do, you already have the JNI...Stay away from it SUN....
  34. NO[ Go to top ]

    Python seems to handle portability pretty well. I can write portable Python programs pretty easily. The presence of the win32 extensions doesn't encourage me to use them unless I actually need to do something win32-specific.
  35. Is this another joke?[ Go to top ]

    Great news, but this could be just a little too late. Does this ideea break the portability of java platform? If not, I hope they will go for it like a storm.

    Sadly, this is a news about a "talk". Maybe in 2 years we will have something really usable.

    Regards,
    Horia

    Think about JDIC project, witch IMHO is a joke. Maybe with a new ideea like this, we could isntantly integrate java apps into Win Desktop OS. Just try the icon tray component and you will laugh. It is a joke even if we are talking only about the noise they make around it. Icon Tray will kick MS's ass really hard.
  36. Smells like J++ spirit[ Go to top ]

    This time, it will be done in a way that respects the standard process of Java, but I can't help relating this to the extra features that were in J++ years ago. Probably a good thing for Java.
  37. Definitely[ Go to top ]

    Having been involved in a project where a decision had to be made - Java or .NET - and having the decision go .NET, for only one reason - Interoperability with other, 3rd party applications...

    Well, to me the choice is clear. DO IT. DO IT NOW. Don't let interoperability be a stumbling point for anyone else.
  38. I need to integrate Java with Groupwise (as a trusted application)

    Groupwise has a C++ interface. No java interface. There is a SOAP interface in the works, but it does not give me the flexibility I need.

    So, I could either learn JNI, write C++ wrapper classes around what Novell has provided (this is a decent sized interface mind you) and go from there.

    Or, I could use this to gobble up the header file and make my life easy.

    Hmmmmm, let me think about that...

    OF COURSE this should be done! Despite what people seem to think, there are at LOT of C/C++ applications out there that we developers MUST interoperate with. Be it older mainframe applications, Groupwise, or whatever, we need something better than JNI to do the job.

    JNI already exists, lets make it better.

    As for the "pick the right tool to do the job" argument. I am doing just that. Groupwise is the right tool for my e-mail job. Java is the right tool for our custom application (doing this application in C++ would be a nightmare). Now i need the right tool to make them work together.
  39. A rapid prototyping approach that allows calling native functinons without resorting to codeing JNI is ctypes4j.

    Opensource and working. http://ctypes4j.sourceforge.net/
  40. Portability is not Java's only Virtue[ Go to top ]

    There are times when I want to develop code that works with (large, complex, expensive, legacy) currently existing 3rd-party libraries.

    Building another 10,000 lines of C++ doesn't thrill me - especially if I'm writing something to use XML or other modern technologies for which Java has better support than C++ (no flame-wars, please, let us accept the obvious point that Java libraries are getting more attention and development these days).

    Java is the often right tool for the job in such situations, permitting me to leverage better IDEs, better cutting-edge libraries and (importantly) putting me on a path towards an eventual upgrade to 100% Java.

    Hence better Java/native code integration has its place. Of course some idiots will misuse it - but that happens with any powerful technology. The 100% pure reusable Java ethos is strong enough for the Java community in general to survive that issue.

    Sean
  41. Yes but ... no No NO![ Go to top ]

    Ease and performance are always good, unless you have to sacrifice too much. A better JNI seems like a good idea, if nothing is sacrificed. If you gotta to use it you gotta use it ease is nice but shouldnt enter the decision making process.

    The discussion of performance in this context worries me from a software engineering perspective.

    The catchphrase "seamless integration" fills me with a horror akin to that other case mentioned in this discussion - keeping business logic in legacy code (one, two, three: Ewwwww business logic will always need maintenance).
    I have heard a lot about .NET seamless low level integration of multilanguage and legacy code and it seems to me that this can only be a bad thing - the reason that I use different languages is to harness the different paradigms where indicated by the nature of the problem - ie different language different [sub-]problems.

    Protocol is crucial to any functional interface - the data flow across the interface must be very well defined for sucessful development, maintenance & operation. I'm not saying that you should use WSDL for every foreign interface, but simply that the message/call/shared memory use must be carefully considered.

    I said above that ease/efficiency shouln't change the decision making: if ease is a problem you are using too many entry points for your interface - your problems are not well separated and it is unlikley that you are getting any benefit from the separation, even if you are maintenance is a nightmare. If performance is an issue then the the operations are obviously very small and you should either redesign the interface, or just impement that nice small operation in the main language, anyway.

    (the above might be titled "Why I think .NET is snake oil")
  42. yes, why not?[ Go to top ]

    It can be very useful. Especially when developer has chosen java and found that some portion of the project can not be done purely in java.

    The message -- trying to write truely portable java has been conveyed clearly enough to developers. We can trust that the educated developers can make good decision for themselvs.
  43. My Views:

    Java already is equipped to access native code. What is meant by _easy_ access? .By, my terms i would say _easy_ access is having a out-of-the-box pure Java components to connect to the Operating system products., like IIS, Exchange Server, BizTalks erver,etc. I have personally felt the need to have custom Java components which directly talks to MS Exchange Server .
    Once the OS specific components are hidden by Java interfaces,then, the application developers all over will have one tool "Java". And behind the scene System developers can extend the Virtual machine slowly and steadily to have the Java VM right from Bootstrap, supplemented by few Assembly code.

    Regards
    Surajeet
  44. JNIEasy a new tool[ Go to top ]

    JNIEasy is a new Java development library to solve this problem, JNIEasy access C and C++ native code and let do "native programming" in Java without JNI, but in a very natural way never seen before.

    It has been showed in the II Congress javaHispano 2004, you can see the slides(spanish).

    Will be released soon. Link
  45. Thankyou but no, thankyou.[ Go to top ]

    I feel people is forgetting that Java is Java only because it has an accent on the "Write Once Run Anywhere" paradigm.

    Java is not pure as Smalltalk (but Smalltalk is so pure that you will never find two 100%-equals implementations), and Java is not hybrid as .NET/Mono. Java fits well a niche and paradigm: WORA. And no amount of Rory Blyths in the world will make me change my idea that WORA it is a splendid thing to have and that it is a reality.

    It all boils down to a thing: achieving interoperability of components.

    In 2004 I should be able to run the code I buy on any other machine I buy, using whatever version of Operating System I have at hand.

    That is, I have to be able to run my application either on an Apple machine with MacOS X Server, or on a Fujitsu Ultrasparc with Sun's JVM, or even Jrockit on XEON, using whatever J2EE server I need, be it Weblogic or Apache or Jonas.

    What do I fear I will get with "easier JNI"?

    Companies that will use this "easier JNI" to put anal activation schemes. To which I say, no thankyou. [1]

    Companies that will certify their software only on their endorsed platform and only if you pay big grands. To which I say, no thankyou. [2]

    As someone said, companies that will wrap their legacy Cobol pre-Y2K code, to which I say, no thankyou. [3]

    Java is already complex enough like it is. Java software has already enough screw-ups as it is. But Java also has an *IDENTITY*. You are programming Java stuff. Java stuff is WORA. You are not programming Python stuff, you are not programming C stuff, you are not programming C# stuff. And unfortunately you are not programming Smalltalk stuff.
    FOCUS!

    Please, at least, try to forget JNI, unless you are doing videogame development... but in that case you will anyway need part of the team dedicated to Native development and part of the team dedicated to create wrappers between the JVM and the native development, and you will also need to solve problems like the product activation and support for some architectures (it usually boils down to Windows/DirectX OR Windows/OpenGL). But that is part of YOUR problems, not the problems of everyone else in the Java camp.

    Developing, for example, on the Eclipse framework (even if I am finding Eclipse 3.0 to be better than I used to say some time ago) unfortunately is not Java stuff. It also adds the complexity of having a "RELEASE MANAGER" figure that certifies that your software, for the native parts, will run on a certain number of architectures. I don't see the need of complicating the deployment and adoption and SUPPORT of the software on sparse architecture. Software is already a beast like it is now. Java is already complicated. Why wanting it to become more complex?

    [1] in 2004 companies really need to buy only custom tailored solution... the "omni-comprehensive" pre-packaged software market is D.O.A., or at least it does not have anymore the relevance it used to have.

    [2] in 2004 I need your software to be part in MY Stack, not YOUR entire stack for running a single software I need.

    [3] business opportunities for me as a programmer is really only another side of the medal.
  46. To all the nay-sayers: JNI is here, has been and will be. Improving or changing it will not bring about chaos as some dimwits claim.
    If it can be made faster, easier, more power for those who need it; those who don't, those who despise, hate, loathe it it will be just the same - pretend it doesn't exist.

    But let's cut this WORA crap: there's quite a few other languages that are source and bytecode portable, and that don't mean shit. Java has industry backing and that's why it works.
  47. To all the nay-sayers: JNI is here, has been and will be. Improving or changing it will not bring about chaos as some dimwits claim.

    Fortunately I did not use the word "chaos", I only used the word "complexity", as in: "I do not want Java to become a more complicated platform". I would like the Java platform to become even simpler, not dumber, only simpler.

    For some good introductions on Chaos, Simplicity and Complexity checkout:

    The Collapse of Chaos - Ian Stewart
    http://www.amazon.com/exec/obidos/ASIN/0140178740

    Out of Control - Kevin Kelly
    http://www.amazon.com/exec/obidos/ASIN/0201483408
    Free online from the author here: http://www.kk.org/outofcontrol/
    But let's cut this WORA crap: there's quite a few other languages that are source and bytecode portable, and that don't mean shit. Java has industry backing and that's why it works.

    It has backing only because JAVA works as advertised everywhere... otherwise JAVA would have been yet another failure, like CORBA.

    JAVA is more like TCP/IP. It does one thing and it does it "good enough".

    By the way, is the page that your browser is rendering in html? :)
  48. To Marc de Kwant: all those APIs libs and so on, except GCC's CNI, use JNI. This is about improving and changing or replacing JNI with something better. Doh !

    Davide,
    How can simplifying and optimising an existing process lead to complexity ? Again, JNI was is and will be with us, and people who need it _will_ use it. Improving it will _decrease_ complexity.

    On the next point I personally think Java has industry backing because it comes from an industry giant. Next in line come Java's quality, promises and deliverables and everything else.

    Regarding CORBA, you're clearly either not informed or have a personal resentment against it. I really don't feel like reiterating corba-vs-whatever arguments here, ranging from deployed systems, industry support, maturity of specs, coverage of topics, vendors/implementations and the whole shebang.

    Java is not at all like TCP/IP; Java does a lot a things and does most of them (very) well. On that line of thinking that I don't particularly indulge, you might say that C is closer to TCP/IP than Java is. Java has provisions for distributed systems (including CORBA), databases, messaging, embedded devices and a shitload of other business requirements. Hell, Java has synchronisation primitives built into the language and basic object. Java does not do just one thing, if it did perhaps 10-15 people would have ever known about it.
  49. Davide, How can simplifying and optimising an existing process lead to complexity ? Again, JNI was is and will be with us, and people who need it _will_ use it. Improving it will _decrease_ complexity.

    Ok, point taken :)

    But let's not jump to the conclusion that we should open the floodgates and write native components and throw away java-only software only because "Microsoft does it" (and IBM wants us to).

    Microsoft with .NET supports only one operating system and only one architecture (well two and a half: x86, amd64 - which is half, and Itanium).

    If you want to produce software with native components in Java, please remember remember remember that you will also have to support N architectures, and that everyone else either has access to the JNI parts to recompile them, OR they have to meet your specs.
    Java is not at all like TCP/IP; Java does a lot a things and does most of them (very) well.

    Java is a software platform with portable bytecode. Java needs only to do one thing: the software platform with portable bytecode. If we miss WORA we are going to lose the only thing that makes it really stand out from the other software platforms.

    Then there are many other things that Java could do if it had "easier JNI", but it would not solve the problems of having a release manager who makes GCC run to build the JNI parts of your fantastical graphical widget when you recompile again your application for a new release.
  50. If we miss WORA we are going to lose the only thing that makes it really stand out from the other software platforms.

     Ok, I agree, but Windows/Intel market is 90% of computers (IDC last survey), ¿are you going to develop a desktop Java application? probably portability is not an issue, programming with a very good framework as Java is an issue, but sometimes Java doesn't cover all needs of integration with the system, integration is a big issue on desktop.

    WORA works really on server side, server side world is simpler usually because most of applications are Web based database managers, but on desktop usually you must talk with hardware (Windows mediated), custom DLLs etc.

     Then you have three options:

    1) Do with Net :(
    2) Use JNI : but be prepared to code in C/C++, setup new C/C++ based projects, tools, IDEs, duplication of structures in native code and Java, data conversion etc and port to other plattforms will be harder.
    3) Use a toolkit to avoid JNI as JNIEasy or JNIWrapper.
  51. RE: Thankyou but no, thankyou.[ Go to top ]

    If we miss WORA we are going to lose the only thing that makes it really stand out from the other software platforms.

    For me Java is just a tool. I decide how to use it. While doing server apps I sure want it to be portable. While I'm coding client app I really don't care because they are going to be deployed on Windows anyway. I really would like to see an improved and easier way to interoperate with native-code when doing client-app. So I could use Java instead of having to code it in C++.
  52. RE: Thankyou but no, thankyou.[ Go to top ]

    While I'm coding client app I really don't care because they are going to be deployed on Windows anyway.

    This sort of comment takes me back some time when the same thing was said about DOS. Unless you are doing something very specialised, Java gives you portability at minimal effort, and the ability for clients to use your app on Linux or MacOS is (I find) a real benefit, even for apps used just within an organisation.
  53. Then you have three options:1) Do with Net :(2) Use JNI : but be prepared to code in C/C++, setup new C/C++ based projects, tools, IDEs, duplication of structures in native code and Java, data conversion etc and port to other plattforms will be harder.3) Use a toolkit to avoid JNI as JNIEasy or JNIWrapper.

    You missed one thing Java/Com bridge, and that is how mostly you access the native code in .NET too,they called it RCW in .NET world. I used years ago (I beleive in 97) a SDK from MicroSoft that allowed you to access COM from Java (forgot the name) and I beleive many years after that (now) there must be lot of tools, API, or commercial products that allow you to do this. So what is the big deal, why corrupt Java?
  54. If you want to produce software with native components in Java, please remember remember remember that you will also have to support N architectures, and that everyone else either has access to the JNI parts to recompile them, OR they have to meet your specs.

    Not quite. There's software and software and no point in this one size fits all view that you have of it. If you write a JMS server you may want for instance to look into talking through Unix domain sockets to PostgreSQL, or use aio if available - this may give you the edge you need. If you want to write a GUI and you have integrate both some RMI server and Exchange you will have to do some JNI. It will work for your target audience and that's what's important, that's the bottom line. You really, really don't care that it does not run on AmigaOS and a headless 64bit SUN/Fujitsu server.
    And in the end, you can't really claim to posess the one true way that software should be written, or just make up selection criteria like "it's gotta run everywhere". Well yes, some code needs to run in a handfull of places, and some doesn't.
    Moreover, the code may just as well have native parts provided as optimising but optional layers - like Caucho's Resin does. Nothing wrong with that, au contraire Davide, it's choice and choice is good.
    If we miss WORA we are going to lose the only thing that makes it really stand out from the other software platforms.

    That's not really true; WORA is intrinsic to Java indeed, but it is NOT what sets it apart. Python and Lua are two examples of programming languages that produce portable bytecode. Are they Java ? No. Why ? Industry support. Python has been around for 15 years, did you know that ? RedHat's extensive use of python has pushed it into the front. It's all about who you know ! :)
  55. Vania, Jose... I agree with most of your points... :)

    Radu-Adrian:
    Nothing wrong with that, au contraire Davide, it's choice and choice is good.

    Choice is good if:
    1) the ones who make choices in the project are wide awake of the risks implied and...

    2) they do not have "other agendas" [1] behind the choices made and...

    3) the act of choosing can be supported within the costs of the project or inside a business decision ("let's focus on the embedded imagery market").

    If your customer is paying you for a JNI enabled solution which re-uses Exchange and an RMI server, THEN there is no problem in using JNI, go JNI all the way.

    And I add: if a new JNI spec does not break the JVM or its security [2], then, well, you proved your point and I too would be happy to see a new JNI spec.

    The real problem is inside that JNI seems, at least in some circles lately (the Gnome camp, the SWT camp) to be the widest reality of Java development and that needs to be even wider. The reality is that JNI is not the reality of Java development and deployment: it is an exception! [3]

    JNI is something slightly outside the general philosophy of Java.

    If you choose to pursuit the Java + JNI combination you (as a project manager, or person asked to make a choice) are taking a precise responsibility and are asked to use a certain tools or to train your developers for JNI support.

    But remember too that you are going to find less free support "in the wild" for Java JNI applications, less tools, less collective knowledge. In 2004 WORA is still stronger than JNI... things may change tomorrow (well... they started changing when Sun released Java3D with the full source code and started some JNI-full projects like Looking Glass or the Java-Desktop integration on java.net)... but winner will not be java, but winner be the people that are ready to embrace the change.

    What will happen tomorrow? Maybe the Java/JNI fad will pass like the Linux fad passed in 2001 :( (I still use Linux whenever I can, but I long the times when Linux was hyp and cool).

    But in order to help your software survive embracing the winds of change, keep it simple! Keep it small! Keep it as a set of components! Keep it as a set of services!

    An heavy JNI layer puts a big toll on YOUR software. If you decide that you must use JNI, you must be ready, one day, to re-invent the wheel in order to sell it to another customer.

    I said:
    If we miss WORA we are going to lose the only thing that makes it really stand out from the other software platforms.

    You replied:
    That's not really true; WORA is intrinsic to Java indeed, but it is NOT what sets it apart.

    Well, I can speak for myself: the first reason I started developing in Java is that it worked under Solaris and Windows at my university, and on Linux at home and that I could reasonably expect it to behave in the same (broken) [4] way in those three enviroments. :) :) :)

    The second reason is that I never liked C pointers and never liked #includeing too many stuff. :) Call me lazy :)

    [1] "let's sell our product" is not an hidden agenda. "let's use ${PROPRIETARY_FRAMEWORK}" because the one that sells the framework bribed them is an hidden agenda.

    [2] do you remember what ActiveX has done to the Windows JVM?

    [3] boys and girls, the next link is a joke: http://www.googlefight.com/cgi-bin/compare.pl?q1=java+jni&q2=java+servlets&B1=Make+a+fight%21&compare=1&langue=us

    And the next one too: :)
    http://www.googlefight.com/cgi-bin/compare.pl?q1=hani+suleiman&q2=maven&B1=Make+a+fight%21&compare=1&langue=us

    [4] aaah, the joys of Java 1.3
  56. I frankly see no statement in what you're saying over there.
    Apart from "going JNI means you have more responsability" and "using existing frameworks to sell new products is kind of wicked (hidden agenda)", things that are either obvious or arguably irrelevant, I fail to see more opposition to the idea that a benefic change to JNI is "thank you but no thank you".
    There you have it, JNI is for people that need it and a better JNI is for happier people that need it.

    Also why would you suggest lack of competence when the choice maker decides on JNI ? I'm obviously talking about informed decisions here; I don't care at all for the argument of helping hapless people not stab themselves to death with the ornamental swords.
    This is a business like any other, I fail to see why programming languages should be influenced by whether they're accessible enough for the lowest common denominator and go out of their way for the sake of preventing the poor, poor programmer from breaking his neck. I mean do you really expect if you worked at NASA they'd just let you write code in TCL because it's nicer than some weird-ass microcontroller assembly ? You either cut it or you don't, be it C++, Java, CSS2 or assembly. I see a lot of lazy-ass mentality on these forums, like "weee weee java is soooo complicated puhleaaaze do not interoducing generics cannot read teh code !"
    End of rant.

    KISS and layering and services have nothing to do with JNI or Java for that matter. And the Resin example I gave is excellent: SSL through OpenSLL or JSSE, take your pick.

    Oh and it's called "porting" not reinventing the wheel ok ? :)
  57. While I was reading this Forum about the jni issue, I read alot of yes/no's and good argumentation.

    But on numerous occasions there are references to 3d party api that provide mechanisms to call upon native functions etc..

    Since they already exists, why not keep the Java platform as it is, and use the 3d party api's to do the required work.

    When no alternative is avail, you can always fall back upon jni, or make ur own high performance low maintanance implementation.
  58. +1

    What's wrong with making a currently kludgy and awkward process easier? If you really need to use JNI, then why not!
  59. Simplifying integration is a good thing[ Go to top ]

    My current project requires integration with a legacy messaging technology and the only interface available is C++. Simplifying this sort of integration can only be a good thing(tm).

    Simon
    [ blog ]
  60. JBoss AOP[ Go to top ]

    Can't JBoss AOP do this already? In fact, didn't they donate the code to Sun?
  61. Best way how to deal with native code[ Go to top ]

    I found very flexible way how to deal with native code:
    proc=java.lang.Runtime.getRuntime().exec("myCode");
    and then simply
    proc.getInputStream() and proc.getOutputStream() should be used for communication.
    At first sight it looks strange but it's very easy to handle errors and your Java code stay stable. You can communicate event with bash scripts.
    Of course sometimes JNI is necessary but I always try to get around this.
  62. Sure![ Go to top ]

    Sure,

    easier and faster native code access is always wellcome. As someone said, it will not hurt cross-platform support as Java platform and average Java developer are matured enough that such a power will not be missused!
  63. Yes, Absoletely[ Go to top ]

    Sometimes, the *only* way to talk to a piece of hardware (camera, analog I/O, stepper controller, etc) is through C/C++ call to the API provided by the hardware vendor.

    However, by writing user interface code, file handling, timing, etc in Java, porting becomes much easier. When it does come time to convert your software to another platform or another piece of hardware, you just have to rewrite a small JNI library.

    I would *love* to have a simpler/faster JNI mechanism!

    -- Jeff
  64. In this particular community there is a missing appreciation for many of the things that are done in Java these days. There is a whole area of development into multimedia, games, etc. that absolutely require access to native APIs. The fact that Java doesn't have clean access to native APIs without much pain and suffering, casting, etc. means that many ports that should happen aceoss the various JVMs DON'T happen across the various JVMs because there is a considerable amount of momentum required to perform the port.

    As a result, Java stumbles in a few areas of native hardware acceleration where having the ability to more easily bind to native libraries would make life a lot easier for those of us interested in binding to things like OpenAL, OpenAL, DirectX, etc.
  65. YES! +1[ Go to top ]

    There are enterprise applications out there that aren't simple ordering systems. Consider informatics in life and materials science. In this domain we have tons of legacy code and very well validated algorithms that one would prefer to reuse. There is an exteremly high price to revalidate these systems if we were to port them to Java--let alone development costs. However, we'd also like to take advantage of the bredth of infrustructure technologies available with the Java platform. Assume the algorithms are already ported to multiple platforms. We use SWIG or plain-old JNI today--I don't know anything about JACE yet. If there is a better way to suck in a header file and generate a Java wrapper for native code it would save us a TON of money as a business.

    How could this not be a good thing? I think the counter-argument to this is simple evangelism rather than pragmatism.

    Leave the choice in my hands to design and write a good portable system and provide me the best possible tools to do get my job done in a cost-effective manner. Code reuse is an even more important feature than guaranteed portability.
  66. Yes: we want easy access to native code. The more tricks up our developer sleeve the better.

    e.g. I started working with JNI a few days ago. I needed to implement ping (and traceroutes). And to my initial surprise there wasn't any ICMP access in the Java libraries. (And possibly for good reason: ping sockets requiring root privileges on Unix; and the varying implementations on Windows and Unix). As it happens, I just need this to run on Linux and root access isn't an issue.

    But what exactly is the problem with JNI. And how exactly does the 'new and improved' native code accessing method work?

    Where has this talk about the group from Sun been going on. Got a link? Got a whitepaper? Any details? Or are you just floating a balloon here?

    As soon as you start sucking up header files you're going to have some pretty nasty API dependancies in that Java code. Since presumably you're then coding to that API in your Java code. At least with JNI you _start_ with a nice clean Java interface. Then do all the ugly C code and interacting with the underlying native API in that API's native language.

    I don't know where you are going to get a 4x performance speed up. Your actual JNI code is going to run as fast as native code since it _is_ native code. I'm presuming that most people are only doing a few JNI<->Java interactions in their JNI code. So that should not really be a factor in performance. Then it is just the java to native and back context switch. I haven't measured the overhead of that. But I can hardly imagine it would be significant.

    Anyway, just looking another silver bullet in the mouth.

    --
    RimuHosting - Power Java Hosting