JNI vs. Java re-write discussion

[Barf]

split from this discussion:
https://www.hifi-remote.com/forums/viewtopic.php?t=14213

Wow. Interesting. There are so much I would like to comment on, however, my Internet connection at home is temporarily broken (hopefully fixed on Wednesday) so I am writing this from work were I have neither my files nor very much time

RM(IR) and IR are programs for the programming of JP1 remotes, and I think it is wise to keep it that way. That is, functionallity for analyzing IR signals should prefereably go to another program, possibly a "super IRscope". I will developed this idea further, I have some concepts...

Pronto support: There is support in ExchangeIR, the original version, but not in my Java translation. The reason being that I did not like the implementation, and liked my own in IrpMaster better. Vyrolan (and others): Note that IrpMaster is (from design) intended not only as an interactive program, but as a library. Look at the Pronto class, you can likely use that to achieve what you look for. Feel free to use; the licensing is compatible.

One more thing: JNI is good for interfacing hardware interfaces (prime example jp12serial); for functions transforming numbers to other numbers (like ExchangeIR) it is sacrificing pure Java portability for no valid reason.

[mathdon]

One more thing: JNI is good for interfacing hardware interfaces (prime example jp12serial); for functions transforming numbers to other numbers (like ExchangeIR) it is sacrificing pure Java portability for no valid reason.

That depends on what you consider to be a valid reason. ExchangeIR is written as a dll so that exactly the same code can be accessed by IR.exe (written in Delphi) and IRScope (written in MS C++). With a JNI interface that same code could also be accessed by RMIR.

[Vyrolan]

RM(IR) and IR are programs for the programming of JP1 remotes, and I think it is wise to keep it that way. That is, functionallity for analyzing IR signals should prefereably go to another program, possibly a "super IRscope". I will developed this idea further, I have some concepts...

I tend to agree...bloating RMIR just for the sake of adding miscellaneous capabilities seems a bit strange. RMIR ideally would be more focused towards end-users (as it has always been) with more advanced features only accessed by toggling on certain options. Beyond that, any "expert only" stuff like this full-on protocol decoding/analysis/whatever we've been discussing feels better as a separate app. /shrug

One more thing: JNI is good for interfacing hardware interfaces (prime example jp12serial); for functions transforming numbers to other numbers (like ExchangeIR) it is sacrificing pure Java portability for no valid reason.

That depends on what you consider to be a valid reason. ExchangeIR is written as a dll so that exactly the same code can be accessed by IR.exe (written in Delphi) and IRScope (written in MS C++). With a JNI interface that same code could also be accessed by RMIR.

I agree in many respects with Graham's assessment. Lacking sufficient differences between the two, "the one everything else uses" wins IMHO.

[Barf]

My Internet connection works again!

One more thing: JNI is good for interfacing hardware interfaces (prime example jp12serial); for functions transforming numbers to other numbers (like ExchangeIR) it is sacrificing pure Java portability for no valid reason.

That depends on what you consider to be a valid reason. ExchangeIR is written as a dll so that exactly the same code can be accessed by IR.exe (written in Delphi) and IRScope (written in MS C++). With a JNI interface that same code could also be accessed by RMIR.

I was sort-of expecting this response, so I would like to comment upon it in some detail.

No solution has just advantages or just disadvantages. The reason why I made a Java version of (parts of) ExchangeIR instead of an JNI interface is that I was (and am) convinced that a pure Java solution is better than a dll/so + JNI solution, not that I was not able to do a JNI solution. The latter solution has all the disadvantages we know of: Must be compiled for all different versions (see Dave's "can anyone help me compile DecodeIR for Linux, Mac"). Incompatibilities due to 32/64 bit versions etc. Additional files to install, and must match architecture, possibly adjust search paths etc. (How many people have problems with DLLs that could not be found?) For the developer, a JNI interface is much more "rigid", making it harder to fix problems. Debugging and profiling is essentially impossible with JNI. The list can be extended...

Sometimes (jp12serial) JNI is simply plain necessary, since you cannot do it in Java, but for something transforming number and symbols to number and symbols without hardware dependencies or extreme performance requirements, pure Java IS the portable solution. (C#/.net comes in between)

Of course, being able to call the same program from both C/C++ and Java may be an issue. It should be pointed out that there is also the possibility to call Java from C/C++; I have an article on this (e.g. calling IrpMaster from C, like LIRC) on my TODO-list.

It should also be said that at this point of time, no development has taken place on IR, ExchangeIR/C++, and IRScope since years, so the arguments pro JNI seems somewhat, well, "abstract" ....

[Vyrolan]

The latter solution has all the disadvantages we know of: Must be compiled for all different versions (see Dave's "can anyone help me compile DecodeIR for Linux, Mac"). Incompatibilities due to 32/64 bit versions etc. Additional files to install, and must match architecture, possibly adjust search paths etc. (How many people have problems with DLLs that could not be found?)

I would agree with all of those...however...

It should also be said that at this point of time, no development has taken place on IR, ExchangeIR/C++, and IRScope since years, so the arguments pro JNI seems somewhat, well, "abstract" ....

I cannot agree here at all. They are not at all abstract. Those apps are still the gold standard because they work and work well. As long as Rob, Vicky, and others continue to use IR because they have to and continue to point out things IR can do which RMIR cannot, they will continue to be the gold standard. In my humble opinion, until RMIR can do everything IR does, it cannot fully replace it and so the Java tools cannot take the forefront.

For those reasons, RMIR needs to do "what IR does". We have to get that far before we can worry about making it better. If we use an ExchangeIR JNI and add those capabilities to RMIR, we should be able to make RMIR do exactly what IR does (including any shortcomings or bugs from the shared ExchangeIR). Only then in my opinion can we realistically have a discussion about moving forward with fixing bugs and/or adding features. There's no reason to reimplement a bunch of stuff that's not really broken (in fact, it's a generally accepted bad idea). We don't have the time or the manpower for it. Would the users rather us spend time adding new features to simplify the toolset (so that RMIR is "the tool" to do everything) or spend our time translating C++ to Java so they have 1 less DLL on their system?

As it is, each new version of RMIR is compared at least partially to IR. Until that changes, the goal should be to change that comparison. Ideally, IR should be gone and each new version of RMIR should be compared only to the previous version of RMIR. Once you're in that scenario, suddenly a fix like "No longer reliant on ___ DLL" looks really great and valuable. However, as long as it still doesn't do X, Y, or Z that IR did, then that change doesn't seem nearly as good. Imagine you had a new car from 2010 and I tried to sell you a brand new 2012 model that was actually a duplicate of a 1970 model. You'd be like "this car doesn't have air bags or anti-lock breaks and its fuel efficiency is terrible....it's not even as good as my old car"! Then I'd release a second version of my car that had a CD player. I'd say "Look! Now it has a CD player!" You'd say "IT STILL DOESN'T HAVE AIR BAGS YOU DOLT!"

[Barf]

Thank you Rob for so very vividly (probably involuntarily!) illustrating my point: That JNI is error prone, work intense, and inferior to a pure Java solution.

As I understand, we probably need 6 versions of each shared library Windows, mac, Linux, in both 32- and 64-bit versions. (Although I am not really sure about the Mac). (And that still leaves the other systems unsupported.) LibraryLoader.java needs to be rewritten to take the "bit" into account also on Windows (and Mac?). Also taking the standard library path into account would be a good idea here (yes, the ball is here with me... )

It should also be said that at this point of time, no development has taken place on IR, ExchangeIR/C++, and IRScope since years, so the arguments pro JNI seems somewhat, well, "abstract" ....

I cannot agree here at all. They are not at all abstract. Those apps are still the gold standard because ...

Obviously I did not get by point across. Next try: I have respect for the problem of parallel versions, as a general principle. In this very situation, however, no active development appears to take place. (Theoretically, it can change, but I do not consider it likely): Therefore, just here, that argument does not appear to have much practical weight; is "abstract".

For those reasons, RMIR needs to do "what IR does". We have to get that far before we can worry about making it better. If we use an ExchangeIR JNI and add those capabilities to RMIR, we should be able to make RMIR do exactly what IR does (including any shortcomings or bugs from the shared ExchangeIR). Only then in my opinion can we realistically have a discussion about moving forward with fixing bugs and/or adding features.

If that is your opinion (I personally differ) it is a riddle to me why you refuse to use the Java ExchangeIR. It does what you want. Quite contradictory, really.

There's no reason to reimplement a bunch of stuff that's not really broken (in fact, it's a generally accepted bad idea).

You find one(!) twelve year (!) old blog entry, and conclude "generally accepted"?! Possibly more interesting: The blog article does not support your standpoint at all! It says that complete new implementation from scratch is evil, refactoring is good. However, translating C++ to Java is not new implementation, it is rather to be compared to refactoring!

[Vyrolan]

LibraryLoader.java needs to be rewritten to take the "bit" into account also on Windows (and Mac?). Also taking the standard library path into account would be a good idea here

It could very easily be changed to check whether it is running 32-bit or 64-bit and pick the appropriate one. I'd already have that done if we had 64-bit builds of the DLLs. I've also already changed it to try the standard library path if it can't find it in the hard-coded path.

Obviously I did not get by point across. Next try: I have respect for the problem of parallel versions, as a general principle. In this very situation, however, no active development appears to take place. (Theoretically, it can change, but I do not consider it likely): Therefore, just here, that argument does not appear to have much practical weight; is "abstract".

Oh no. You got your point across quite clearly. I just disagree with it. Just because IR has no "active development" does not change that it is the gold standard of how things work. The mere fact that it is still being used actively and extensively without regular bug releases only reinforces the quality of the product. Just because something is old or not being actively developed does not mean it is bad or should be replaced.

If that is your opinion (I personally differ) it is a riddle to me why you refuse to use the Java ExchangeIR. It does what you want. Quite contradictory, really.

It does what I want? So you're saying that you can guarantee me 100% that it will do exactly what the ExchangeIR.dll does in every single situation for every single call of every single function? You even admitted it that your Java version was only a partial translation, so I doubt that's true... Even if so, we're already using JNI for several other libraries...why jump through hoops to change? Are you going to translate DecodeIR to Java as well? Are you going to maintain those versions up-to-date as the original authors update their C++ versions?

Even if you are going to do all those in some valiant effort to save us from JNI, it still won't be complete. We'll still have to use JNI for the hardware interfaces, and so we're still stuck with the problem of having to distribute and load DLLs... If we have to solve the DLL+JNI problem anyway, why not leverage that solution for these other libraries? The only reason NOT to is just some philosophical notion of "correctness".

There's no reason to reimplement a bunch of stuff that's not really broken (in fact, it's a generally accepted bad idea).

You find one(!) twelve year (!) old blog entry, and conclude "generally accepted"?!

If you don't recognize and agree that Netscape's decision to rewrite was one of the worst software development business decisions in the last 20 years, then I don't know what to say. It's a canonical example for a reason, and the lesson to be learned from their mistake rings just as true today as it did then.

Possibly more interesting: The blog article does not support your standpoint at all! It says that complete new implementation from scratch is evil, refactoring is good. However, translating C++ to Java is not new implementation, it is rather to be compared to refactoring!

Translating to a new language is refactoring? That's just laughable and also completely erroneous. Changing to another programming language is definitely "rewriting" and not "refactoring". It's almost like you are just making stuff up at this point to create a reality in which everything you say makes sense and is correct. All you seem to care about is stuff being shiny and new. You seem to think anything old should be just because it's old. Do you really think any of the users care what language the app is written in? They just want it to work. Rob's situation doesn't "illustrate your point" in the slightest. All it does is highlight problems in the current implementation. If the logging were properly done to indicate the problem, then Rob never would have had a problem. If the user were given good clues in the app (disable the tab, tooltip/popup indicating the problem, instructions to resolve), then there wouldn't even be a problem. However, instead of adding a few small UI features to detect the problem and tell the user about how to fix it, you'd rather rewrite everything in Java. That's like demolishing your house and building a new one instead of replacing a light bulb.