Develop Reference

How can I protect Java/Javafx code from being seen by final user?

I have been working on a project alone for more than two years for a company. The project is a really big one using rxtx to communicate with a hardware device. I used Java 8 and JAVAFX for the UI. Now it is almost finished and I am starting to search how to deliver the end user application that the company will distribute over its clients.
The problem is that the company I am working with wants the code to be non reachable when the software is between final clients hands because the Java code contains some extremely sensitive information that could have very bad consequences for the company if final clients happened to know them. The clients can literally perform actions they don’t have the right to perform.
So after searching (a lot) and thinking relatively to my case, I understood that giving a JAR obfuscated isn’t the solution. I then tried to generate a JAR and then transform it to an EXE but all I succeeded on was wrapping the JAR into EXE which does not prevent extracting the JAR and then seeing all the code easily. Finally, I found that I should use AoT compilation like GCJ compiler to produce native binary exe from my Java code but here I am stuck because after watching videos and reading articles etc I didn’t manage to find a clear way to produce the native binary exe.
I am now confused since I don’t know if I am on the right path and good direction or if I am totally wrong and there is another way of protecting the code (at least from non professional hackers, I understand that it is not possible to make it 100% safe but I am just searching for a reasonable and good way). How should I manage this final step of my work?

I currently work for a company that has code that we don't want anyone to have access to for the security of our clients and-- less important-- for legal reasons. ;-)
One possible solution you could look into would be to rewrite the code you deem most sensitive into a C/C++ library. It would be possible to compile this into a .so/.dll/.dylib file for the respective OSs and it would make it difficult, not entirely impossible, but difficult to decompile.
The trouble would come from learning how to access native code from Java as much of the documentation is not helpful or just simply nonexistent. This would utilize the Java Native Interface (JNI) which allows Java to, well, interface with the native (compiled C/C++) code. This would make it possible to create a Jar file that would effectively become a Java library for you to access throughout the rest of your project. The native code, however will still need to be loaded at runtime, but that's apart of learning how JNI works. A helpful link I found for JNI is http://jnicookbook.owsiak.org/ (for as long as it's still a functional link).
One of our clients here where I work has a project written in Java and needed to implement our code that is unfortunately all written in C. So we needed a way to access this C/C++ code from Java. This is the way we went about solving this issue without rewriting our code in Java. But we had the benefit (?) of having already written our code in C.
This solution to write a bunch of extra code last minute in another language that I may or may not be familiar with doesn't sound like particularly fun time.
I would be curious to learn what possible problems others might see with this solution.

Java for a perfect Media Player?

I am looking forward to build a media player with java, and basically what I found was JMF. But, then again, this API is not upto date and doesn't support latest formats such as MKV. On more research, I stumbled upon
Any simple (and up to date) Java frameworks for embedding movies within a Swing Application?
Got all excited, but then digging some more, left me with this
Adding other video codecs / DVD support to JavaFX 2.2
Now, I am disappointed and in a fix that how all the good media players (VLC, KMPlayer etc) been able to support all video and audio formats. They must be build using a programming language, IMHO !
So, my question would be, in-order to build a complete media player which supports all kind of media files:
Is JAVA incompetent ?
Has one ever build a good media player using JAVA ?
Is it just Java or no modern language can do it ?
Do I have rely and choose C, C++ to do this ?

Well, Java is a programming language that was created to support multiple platforms (like Windows, Macintosh and Linux). It works with a virtual machine: a sandbox. So there are a few constrictions, that are based on this sandbox system: Everything, that you want to use in Java must be compatible with ALL platforms, java is created for. And because playing media is very near to the system and of course the hardware (soundcard, graphics board etc), Java may get problems on getting this compatible to all platforms. Another big problem is: Many codecs, you have to read and play (e.g. OGG-Vorbis) are not open sourced, so you will get problems on finding a good API to work with them. Of course there ARE APIs, but I have no experience with them.
Is JAVA incompetent ?
No, but Java was not created, to do system work. Of course, media playing is not a system work, but is near to the system. And Java does not implement codecs for playing music or videos, so you need custom APIs, as I said before.
Is it just Java or no modern language can do it ?
Well the problem is Java: Try a language, that supports more system- and hardware functionality.
Do I have rely and choose C, C++ to do this ?
In my opinion, this is your best opportunity. You may even use VB or VB.Net or whatever, but I think, you will get bigger problems with Java. Of course, this is just my experience, and other people may say you something different, but I think: Yes, C++ is a better language for a media player.
Hope, that answer helped you, greetings
Cydhra
P.S. Sorry, if my English is not that good, it is not my mother language...

The main problem with including more formats in Java by default is licensing restrictions - many of the popular formats are absolutely encumbered with patents and licenses, and for a company like Oracle to support lots of them as part of the JRE just isn't cost effective (in all likelihood.)
However, as mentioned before JFX8 is now open source, and you can thus compile in extra GStreamer plugins if you so choose. I did this recently with MKV, the process is described here if you want to do it with another format.
Since MKV is an open format, I also see no reason in theory why it can't be included in the default classes, so I created a ticket along with the patch - hopefully it may be included as standard in the not too distant future (absolute earliest 8u40.)
If you just want good media support in Java now however, and don't mind having VLC as a dependency, I'd use VLCJ - I use it in my application and it works a treat.

My Java GUI interfaces with my uber-cool proprietary dll. How can I prevent 3rd parties from interfacing with this dll?

I'm writing my process in C++.
Now I want to write its GUI.
I was thinking of using Java in order to do this and link it using JNI, but then I thought of a security problem...
Suppose I have my GUI.exe file written in Java, and I also have my Engine.dll file written in c++.
What would prevent evil evil people from taking my DLL and linking it to their program?
I do use a license validation stuff in my C++ dll, but it can be broken by these evil evil people.
I know every program can be cracked, but I don't want to just GIVE them my engine for easy use.
Is there a way to secure this link?
Or should I use C++ for writing the GUI as well?

The most portable solution probably involves encrypting the data entering and leaving your DLL by whatever means seems appropriate. Obfuscation of the C++ side isn't necessary at that point. This would require the encryption keys to be embedded in both the C++ binary and whatever you are compiling your Java to; you could take extra steps to make this inconvenient to find by hiding it with a large slab of random junk and indexing into it, for example.
Another alternative is to pay up for a licensing system that would be checked at call or link time by ubercool.dll.
Ultimately you're trying to perform a bit of a doomed defensive action. If your ubercool function is genuinely valuable or useful and someone wants to use it in ways you'd rather they didn't, they'll work out how. Can anyone think of any commerical software that hasn't been cracked?
Lastly, you can run your software on a system which is impractical for the end user to fiddle with. Mobile devices with locked bootloaders, TPM modules and so on are one way to do this; the other is to run your ubercool stuff as a hosted service to which people may connect if they have appropriate credentials which you can of course control.

Consider using obfuscator for your Java or C# code that will use your dll. This will not solve all the problem, but it will be more difficult to reverse engineere your programm.
Also, if your project is written in C++, you may consider using C++\CLI for your GUI part of application.

Text to speech converter

I am going to create a Text to speech converter, which can be executed in both Windows, and Linux based systems. Can someone please help me answer the following questions;
What language should i use; Java, C++ or any other?
The program i am going to create should be able to read large chunks of data.
There should be good sound quality.
What are the libraries available to achieve this?
Please share your experiences as well.

Use the language you're most comfortable with. I learned the hard way when I tried to re-code my raytracer in C++, coming from a Python background. It took me weeks to get it to function...
Basically, you'll get frustrated by the nuances of a new language before you can get to coding something, so I suggest you stick with what you know.
That's independent of the language. Just makes sure to read the data in chunks (like 2048 kilobytes at a time). Reading a big file to RAM is not a great idea, as you can't be sure your end user has enough RAM (audio files can get BIG).
This is trivial. I can't help you program good sound quality. That's up to you.
There exist a few implementations of TTS for Linux, so that's all I can recommend. Look at Festival, as it is one of the ones you can actually understand.

Long time ago i had that same idea. I think it is not too complicated and can be done. This is how i would do it:
1- I would use Java, because it is platform independent.
2- If you are going to create an standalone application, it will be the local computer that will do the processing an not an application server, as in the case of web apps. Also i suppose that your program, will be used only by one user at a time. I think you will not have big issues with the amount data to process, if u implement some buffering mechanism.
3- The quality of the sound will depend in various factors such as: noise when recording,format, speed of the sound... Notice that many text to speech applications that exist on the web, the sound quality is ok, but you will never get the feeling that it is a real person, who is reading. (I recommend you a female voice, it sounds better).
4- Regarding to the libraries and another gadgets, this is what i think you might need:
-Java Standard Development Kit(To be able to work with java)
-A good IDE: There a many out there you can get for free. My favourite is eclipse but if you are a beginer with java, you might like to start with netbeans many people say it is more intuitive for learning.
-JLayer Mp3 library This will help you play the sounds in java.
-javax.swing Is a java library that is included in the development kit and allows you to create rich graphical user interfaces. Also if you are new to swing, i would recommend you a great swing IDE, called JFormDesigner, have a look at it, im sure it will speed your development alot(It is a great tool).
I hope my answers can give you some tips.
Update
I think it would be correct to mention also, that the only minimum requirement the users of your app will have in order to run the app is:
JRE(Java runtime enviroment)

This project of text to speech can be made using computer generated voice
so no problem of storing a database for each word and its pronunciation.
Just use the language in which u feel master to urself and apply the concept.....

I do not know anything about text to speech except that it's not easy. That being said, I suggest you stick with the language you are most familiar with. I'm sure Java and C can do it.

How to deal with the most common classes missing on J2ME

I'm trying to code an application which runs un different java platforms like J2SE, J2ME, Android, etc. I already know that I'll have to rewrite most of the UI for each platform, but want to reuse the core logic.
Keeping this core portable involves three drawbacks that I know of:
Keeping to the old Java 1.4 syntax, not using any of the nice language features of Java 5.0
only using external libraries that are known to work on those platforms (that is: don't use JNI and don't have dependencies to other libs which violate this rules)
only using the classes which are present on all those platforms
I know of ways to overcome (1): code in 5.0 style and automatically convert it to 1.4 (retroweaver - haven't tried it yet, but seems ok).
I think (2) is a problem that I just have to accept.
Now I'd like to know what's the best workarround for (3), especially collection classes, which I miss the most. I can think of those:
Most programmers I know just don't use Set, Map, List, etc. and fallback to Vector and plain Arrays. I think this makes code ugly in the first place. But I also know that the right choice between TreeSet/Hashset or LinkedList/ArrayList is crucial for performance, and always using Vector and Arrays can't be right.
I could code my own implementations of that classes. This seems to be reinventing the wheel, and I think I could not do it as good as others have done.
Since Java is open source, I could grab the sourcecode of the J2SE Collections framework and include into my application when building for J2ME. I don't know if this is a good idea, though. Pherhaps there are good reasons not to do this.
Maybe there already are libraries out there, which rebuild the most important features of the collections framework, but are optimized for low end systems, pherhaps by not implementing functionality that is used infrequently. Do you know any?
Thanks for your answers and opinions!
Edit: I finally found a (complex, but nice) solution, and I thought by providing my own answer and accepting it, the solution would become visible at the top. But to the contrary, my answer is still at the very bottom.

J2ME is brutal, and you're just going to have to resign yourself to doing without some of the niceties of other platforms. Get used to Hashtable and Vector, and writing your own wrappers on top of those. Also, don't make the mistake of assuming that J2ME is standard either, as each manufacturer's JVM can do things in profoundly different ways. I wouldn't worry much about performance initially, as just getting correctness on J2ME is enough of a challenge. It is possible to write an app that runs across J2ME, J2SE and Android, as I've done it, but it takes a lot of work. One suggestion that I'd have is that you write the core of your application logic and keep it strictly to java.lang, java.util and java.io. Anywhere where you're going to be doing something that might interact with the platform, such as the file system or network, you can create an interface that your core application code interacts with, that you have different implementations for the different environments. For example, you can have an interface that wraps up HTTP stuff, and uses javax.microedition.io.HttpConnection with J2ME and java.net.HttpURLConnection on Android. It's a pain, but if you want to maintain an app running on all three of those environments, it can get you there. Good luck.

It's been a while since I asked this question, and I while since I found a nice, working solution for the problem, but I had since forgotton to tell you.
My main focus was the Java Collections Framework, which is part of the java.util package.
I've finally taken the source code of Suns Java 6.0 and copied all the classes that belong to the Collections framework into a project of my own. This was a Java 6.0 project, but I used the jars from J2ME as classpath. Most of those classes that I copied depend on other J2SE classes, so there are broken dependencies. Anyway, it was quite easy to cut those depensencies by leaving out everything that deals with serialization (which is not a priority for me) and some minor adjustments.
I compiled the whole thing with a Java 6 compiler, and retrotranslator was used to port the resulting bytecode back to Java 1.2.
Next problem is the package name, because you can't deliver classes from java.util with a J2ME application and load them - the bootstrap class loader won't look into the applications jar file, the other bootloaders aren't allowed to load something with that package name, and on J2ME you can't define custom classloaders. Retrotranslator not only converts bytecode, it also helps to change name references in existing bytecode. I had to move and rename all classes in my project, e.g. java.util.TreeMap became my.company.backport.java.util.TreeMap_.
I was than able to write actual J2ME application in a second Java 6.0 project which referenced the usual java.util.TreeMap, using the generic syntax to create type-safe collections, compile that app to Java 6.0 byte code, and run it through retrotranslator to create Java 1.2 code that now references my.company.backport.java.util.TreeMap_. Note that TreeMap is just an example, it actually works for the whole collections framework and even for 3rd party J2SE Jars that reference that framework.
The resulting app can be packaged as a jar and jad file, and runs fine on both J2ME emulators and actual devices (tested on a Sony Ericsson W880i).
The whole process seems rather complex, but since I used Ant for build automation, and I needed retranslator anyway, there only was a one-time overhead to setup the collection framework backport.
As stated above, I've done this nearly a year ago, and writing this mostly from the top of my head, so I hope there are no errors in it. If you are interested in more details, leave me a comment. I've got a few pages of German documentation about that process, which I could provide if there is any demand.

We faced exactly this situation in developing zxing. If J2ME is in your list of targets, this is your limiting factor by far. We targeted MIDP 2.0 / CLDC 1.1. If you have a similar requirement, you need to stick to Java 1.2. Java 1.4 language features are definitely not present (like assert) and in general you won't find anything after 1.2 in J2ME.
We did not use external libraries, but, you could package them into your deployed .jar file with little trouble. It would make the resulting .jar bigger, and that could be an issue. (Then you can try optimizers/shrinkers like ProGuard to mitigate that.)
I did end up reimplementing something like Collections.sort() and Comparator since we needed them and they are not in J2ME. So yeah you might consider doing this in cases, though only where necessary.
We used Vector and Hashtable and arrays since there is no other choice, really, in J2ME. I would just use them unless you have a reason not to, and that would be performance I guess. In theory JVM makers are already optimizing their implementation but that doesn't mean you couldn't make a better one... I guess I would be surprised if it is worth it in the vast majority of cases. Just make sure you really need to do this before putting in the effort.

To answer part of your question another collections library would be Javolution which can be built for j2me.