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.

way to debug java frameworks on console

I am a C++ dev, working in java technology for about a year. Forgive my ignorance, but I have tried to search for following two questions.
What is the best way to debug in console for a java application (ala gdb in good ol' C++).
It seems jdb is below par.
Eclipse is the way to go for its IDE. But Eclipse is a GUI and I do develop in console on unix servers.
What is the best way to tame huge jave open-source frameworks. eg, camel, hibernate, spring, logback, blah, blah

I do most of my debugging in the console.
I have found that for the majority of bugs, Java stack traces are sufficient to identify the bug and develop a fix. This of course means that it's critical to allow stack traces to be seen on the console. For most applications, I've found that it's best to allow unchecked exceptions to propagate until they terminate the thread, with a stack trace showing up in the console; unchecked exceptions should normally indicate programming errors or uncontrollable conditions where the thread should be terminated anyway.
In cases where the stack trace is not sufficient, I've found that using System.out.println() during the debugging process is actually more effective than using an interactive debugger. Having a full log of a run is for me more useful than running a debugger where I may easily step past an issue that later turns out to be important.

Wat is the problem in setting up the project in eclipse IDE, you can always get the source code and set up your workspace??
Using sysout is great for small java programs but as the code grows or for big application (according to my understanding you plan to debug something big :P) it would really be a headache placing all those sysout and then removing them once you are done with the debugging.
I would suggest you to set up your own workspace by choosing 'import existing project in workspace' option of IDE, though it would be tiring first but will help you in long run.

I would say that there is no need for such a tool, because Java supports remote debugging.
You need to start your (server) JVM with remote debugging enabled - this will work for newer JDKs:
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005
After that you connect to it from the IDE, and set breakpoints or conditional breakpoints wherever you like.
See this question for more details
Also, this is a personal preference, but I would say that IntelliJ IDEA is the way to go as far as Java IDEs go.

How to start out hand coding Java

I've just started with Java and I have been using Netbeans. I have tried Eclipse but it kept crashing on me and I gave up. Since then I have produced a small application, but I find that I feel very restricted within the development environment, and I see lots of generated code that I really don't understand, and which seems to bear little resemblance to any code I may find while researching a problem.
With this in mind, and having seen many suggestions, I would rather begin to code by hand so that I understand exactly what is going where, and why.
My question(s):
I have seen and read through a great many tutorials but most of them assume a certain level of competency. I've built a small desktop editor in Netbeans, but I've never coded Java by hand. With that in mind could you suggest a good "getting starting" tutorial for me?
I would also like some advice on a coding environment. I will be creating desktop applications and am already familiar with Geany through coding in Python, but I've seen very little information about Geany and Java.
I'd appreciate any suggestions about this, because there seem to be a great many editors available, but please note that I am using Ubuntu on my development machine. Open source is not a requirement, but being free is.
BTW, I have no problems with trying Eclipse again if that seems to be the general consensus, I am currently just a little jaded on it since I have never successfully even tested anything without a cataclysmic crash.
Many thanks for any advice that you can give.
MVK
A Little Update
Many thanks to those of you who have taken the time to give an answer. I am currently playing about with the Sublime editor, suggested by user1432824, having had another try at Eclipse. Unfortunately though, Eclipse has a habit of crashing when saving files which is rather inconvenient. I plan to chase this up and see if there is a fixable reason, but it still feels a little heavyweight and integrated and I really want to move away from that if possible.
Thanks for the tutorial links, I've seen most of them already in my travels, but I'm happy to get more.
Finally
Many thanks for your input, I think that I have come to a comfortable result, with a few loose ends that Ill check on later. Here are my findings so far:
The Sublime Editor:
This was a tricky one. The Sublime editor is actually an excellent little app (despite how it looks out of the box!) and I have little doubt that I will use it at some point, but for now it lacks something for me, although I would be hard pressed to explain exactly what. Thanks for the suggestion though, its always good to find new editors.
Eclipse:
So I took the plunge and tried Eclipse again, and, just like the first time I used it I've been rather impressed with the overall look and feel of it, however, just like the last time it crashes at the most inopportune moments and despite much searching I have yet to discover the reason or the cure, which leaves Eclipse out of the running. Besides, although I like the feel of Eclipse it is still a bit on the heavyweight side for what I want to do.
BlueJ:
I admit that I did not try this program, although thanks for the suggestion. It seems to me like just another IDE and I really want to move away from the whole IDE thing for a while, at least until I understand a little more about how Java actually works.
Many thanks for your suggestions, but I think for now that I will go with Geany for a few reasons: As a very lightweight editor it can compile and run Java from the menu or keyboard, which just saves some time, and I have become addicted to the Snippets function which comes in handy once you have learned the basic syntax of whatever commands you add to it.
The only other choice now is between ANT and Maven and I think that the only way to decide between the two is to use both and see which one 'feels' better to me.
Many thanks to all who responded and my final question must be: Since you have all helped me reach my final decision, how to I go about accepting this question? Any advice on that front would also be helpful!
regards,
MVK

In my opinion, if you are new to Java, don't start with GUI. Start with simple text application. The best resource for beginners in my opinion is the official Java tutorial.
http://docs.oracle.com/javase/tutorial/
Good luck!

Have you looked at BlueJ ? From the website:
BlueJ is an integrated Java environment specifically designed for
introductory teaching.
BlueJ was developed at a University specifically for the purpose of
teaching object orientation with Java.
BlueJ is free!
I would strongly recommend using some form of IDE. It'll provide interactive debugging, hints, completion, code colourisation and useful error highlighting.

have you tried the Java online trainings?
http://java.sun.com/developer/onlineTraining/awt/contents.html

As for editors, I started out with a simple plain text editor like those that come on Mac and Windows. I also use Eclipse for Java Developers, and Sublime Text. Sublime has a free, unlimited trial, but will bug you every few saves to buy the premium version.

I would recommend that you get familiar with a build tool, like Ant or Maven. Once you have a project with more than 1 class in it, using a variety of libraries, it's good to have some help managing dependencies, running tests, building jars, etc.

Combining Java and C without gcj -- move C to Java or Java to C?

First, I have no experience doing this. But like the beginning of any good program, I have problem that I need to fix, so I'm willing to learn.
So many of you are probably already familiar with pdftk, the handy utility for handling various pdf-related tasks. So far as I can tell, most of these features are available in much newer, lighter libraries/extensions, except the one I need (and probably the only reason it still exists): merging form data files (fdf and xfdf) with a form PDF and getting a new file as the output.
The problem is that my server doesn't have gcj, which is fundamental to build/compile pdftk. I don't know if it's because I'm on Solaris or if it's for some other sysadmin-level reason, but I'm not getting gcj anytime soon. And there are no pre-compiled binaries for Solaris as far as I can find.
So I'm thinking that the MAKE file and C code can be rewritten to import the Java library (very ancient version of itext) directly, via javac.
But I'm not sure where to really start. All I know is:
I want a binary when I'm done, so that there won't be a need for a Java VM on every use.
The current app uses GCJ.
So my first thought was "Oh this is easy, I can probably just call the classes with some other C-based method", but instead of finding a simple method for doing this, I'm finding tons of lengthy posts on the various angles that this can be approached, etc.
Then I found a page on Sun's site on how to call other languages (like C) in a Java class. But the problems with that approach are:
I'd have to write a wrapper for the wrapper
I'd probably be better off skipping that part and writing the whole thing in Java
I ain't ready for that just yet if I can just import the classes with what is already there
I'm not clear on if I can compile and get a binary at the end or if I'm trapped in Java being needed every time.
Again, I apologize for my ignorance. I just need some advice and examples of how one would replace GCJ dependent C code with something that works directly with Java.
And of course if I'm asking one of those "if we could do that, we'd be rich already" type questions, let me know.

I'm not sure what you are looking for exactly, so I provided several answers.
If you have java code that needs to run, you must:
Run it in a jvm. You can start that vm within your own custom c-code, but it is still using a jvm
Rewrite it in another language.
Compile with an ahead-of-time compiler (eg gcj)
Incidentally, you could compile a copy of gcj in your home folder and use that. I believe the magic switch is --enable-languages=java,c (see: here for more)
If you have c-code you want to call from java, you have four options:
Java Native Interface (JNI). It seems you found this
Java Native Access (JNA). This is slower than JNI, but requires less coding and no wrapper c-code. It does require a jar and a library
Create a CLI utility and use Runtime.Exec(...) to call it.
Use some sort of Inter Process Communication to have the Java code ask the c-code to perform the operation and return the result.
Additional platform dependent options
Use JACOB (win32 only: com access)

I am not sure if I understand what you are looking for.
If you are looking to incorporate the C code into Java to make a native binary without the gcj, I think you are out of luck. You can include the C in Java, but it would be a primarily Java program meaning you would need the JVM on each run. Is there anything stopping you from compiling the gcj yourself?

Baffling Failure to Call External Executable From Within Java Program

All right, I've hit a bug that has simply confused the bejeebus out of me. I'm looking for ideas about what it could be that I can investigate, because right now, I got nothing. It goes something like this:
I have a standalone Java application that occasionally needs to twiddle the Line-In volume of the computer it's running on (a WinXP machine). It does this by calling a pair of external executables (written in VB6*) that can get and set various component volumes. (They can handle Line-In, Mic, Wave, CD, and the master volume control.)
There are several hundred units in the field, running on hardware (Dell machines) that my company provided and controls. At least several dozen clients are using this feature, and it works perfectly -- except for one instance.
For this one troublemaking machine, it simply doesn't work. I watch the volume sliders when the app is running, and when the volume is supposed to drop, they stay put. When I check the app's log file, it throws no errors, and appears to be executing the code that drops the volume. When I run the executables from the command line, they work perfectly.
I can't vouch for this machine being 100% identical to all the ones that are behaving properly, but we've been buying the same line of Dells for quite some time now; at a bare minimum, it's very, very similar.
So, turning my confusion into a bullet list:
If I'm doing something stupid in the Java code (i.e., not clearing my STDOUT/STDERR buffers), why is it only an issue on this machine?
If there's something broken in the VB6 executables, why do they work on every other machine and on this machine from the command line?
If there's some sort of hardware oddity on this machine, what sort of oddity could cause the volume control executables to fail only when called from within a Java application?
I am very confused. I do not like being confused. Anybody have any suggestions that may lead to my enlightenment?**
-* -- I know, I know, VB6, 1998 called and they want their obsolescent proprietary bug generator back, etc. Wasn't my decision. But the code works. Usually.
-** -- Insert Buddhism joke here.
Update Edit: Customer service may have stumbled onto something; it may be something to do with client configuration settings in the database. New evidence suggests that either something's misconfigured for that client or my software is doing something stupid in response to a specific configuration. And the problem may be more widespread than we thought, due to this particular feature not being as commonly used as I thought.
Responding to the comments:
Debugger: Theoretically possible, but looks like a massive headache given our setup.
High Verbosity Logging, Java: Good idea this, particularly given than the problem may be more widespread than I originally believed. Time to start revisiting some assumptions. And possibly clubbing them. Like baby seals.
High Verbosity Logging, VB6: A possibility; will need to be rolled-into the high-verbosity Java logging to trap the output, since my VB6-fu is so pitiably weak I don't know how to output text to a file. But, yeah, knowing whether or not the script is even getting called would be valuable.
Window Event Viewer: Not familiar with this tool. May have to correct that.
PATH problem: Doesn't feel likely; the Java code constructs a relative path to the executable that doesn't look like it's relying on any environment variables.
My thanks for the suggestions people have provided; at the very least, you've gotten my brain moving in directions that feel promising.
Solution Edit: And the winner is ... That's Not A Bug, That's A Feature! A feature gone horribly, horribly wrong. A feature that will now be neutered so as to stop bothering us.
A batch of invalid assumptions kept me from seeing it sooner, not the least of which was "I don't need to tool the code with more debug statements -- the statements already in there are telling me all I need to know!" DaDaDom, if you'd like to turn your comment into an answer, there's a shiny checkmark in it for you.
Thanks to everybody who chimed in with a suggestion. Now if you'll excuse me, my head is late for a meeting with my desk.

Here goes an answer:
Can you create a version of the software with verbose logging or could you even debug the code? At least then you can tell if it's in the java or the VB part.

Hmmmm. I've been told that executing programs from Java is either easy or hard. The easy part is starting them up. The hard part is dealing with the I/O streams (see my earlier question on using Runtime.exec()). Maybe the VB program is doing or expecting something weird on these particular machines that the Java code isn't working with properly.
edit: I also found a link to Jakarta Commons Exec:
Rationale
Executing external processes from Java is a well-known problem area. It is inheriently platform dependent and requires the developer to know and test for platform specific behaviors, for example using cmd.exe on Windows or limited buffer sizes causing deadlocks. The JRE support for this is very limited, albeit better with the new Java SE 1.5 ProcessBuilder class.
Reliably executing external processes can also require knowledge of the environment variables before or after the command is executed. In J2SE 1.1-1.4 there is not support for this, since the method, System.getenv(), for retriving environment variables is deprecated.
There are currently several different libraries that for their own purposes have implemented frameworks around Runtime.exec() to handle the various issues outlined above. The proposed project should aim at coordinating and learning from these initatives to create and maintain a simple, reusable and well-tested package. Since some of the more problematic platforms are not readily available, it is my hope that the broad Apache community can be a great help.

Have you considered the possibility that the authenticated user may not have permission to edit volume settings on the workstation? Does the program run correctly if you run as an 'Administrator'?