In my java apps, I always comment my classes and methods to indicate what they are all about. The problem I often have however is documenting a complete process whereby the process is spread over several classes. I need to document how all the pieces work together to give an easy overview of how something works.
What I find problematic is WHERE I write this documentation. I could just as well write it in a separate file such as a Word document but the documentation tends to become alienated from the actual code and it is possible to get out of sync. On the other hand, if I document it in a single java code file, it makes it difficult for someone reading one of the dependent classes to know how that class fits into the overall process unless they are aware of the documentation in the class where I wrote it. A possible solution is just to include a reference in each class that makes up the entire process and just designate one of the classes as the "primary" class where the documentation originates from.
Or is there a better alternative approach on how I should be doing this?
EDIT:
An example is where you have a mobile app that uploads data to the server and then you download data from the server to another device. You have a process that covers three components (a sending mobile device, the server and the receiving mobile device). None of these can be really considered the "starting point in the overall data transfer process, so when documenting this process, where would this documentation go?
Related
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.
I am writing multiple protobuf messages to a file in C++.
int fifoPipe = open("/media/my_pipe", O_WRONLY);
MyModel *model = new MyModel();
// Write to fifo pipe.
model->SerializeToFileDescriptor(fifoPipe);
I had read that the message size is written to the file automatically before the message data. Apparently this is not the case:
https://developers.google.com/protocol-buffers/docs/techniques?hl=en
So in Java it should be possible to read the message like so:
MyModel.parseDelimitedFrom(fileInputStream);
However there are questions here:
Cannot deserialize protobuf data from C++ in Java
Are there C++ equivalents for the Protocol Buffers delimited I/O functions in Java?
That say the message size must be written manually.
Since the questions are kind of old this procedure may have changed.
What is the proper way of writing multiple messages in C++ and reading those messages in Java?
Also consider how Java would respond to a half written message. In theory it should wait for data the size of message size to be present before returning.
Unfortunately, the parseDelimitedFrom() and writeDelimitedTo() methods still have not been added to the C++ library.
The code I wrote in the answer to one of the questions you referenced is still the best way to implement this in C++:
https://stackoverflow.com/a/22927149/2686899
The main reason why Google with all its resources hasn't gotten around to adding these in C++ is because Google internally does not use this format at all. For network communications, Google uses its internal RPC protocol (very similar to GRPC, which they open sourced recently), and for storing messages to disk they usually a variety of internal formats that are a bit more featureful than this "delimited" format (you might consider using sqlite, for example).
In fact, when Protobuf was first open sourced, parseDelimitedFrom() didn't exist even in Java. I added it later specifically as a stopgap for users of the open source library -- a lot of people asked us how to write multiple messages to a file, and telling them "you should develop your own framing library" didn't seem very nice.
Google may be a huge company, but at that time I was the only person working full-time on Protocol Buffers. Unfortunately, for reasons that I don't quite remember, I only implemented the functions in Java, and never got around to adding them in C++ as well. In retrospect it seems a bit silly -- writing C++ code wouldn't have been very hard, as you can see at the link above. But I had a lot to do, as you might imagine.
The current Protobuf team took over in 2010, and I moved on to other things (and eventually left Google). I don't know for sure why they haven't added this code to the C++ library, but my guess is that not enough people have asked for it and they are focused on other things. I bet if you file a bug, and link to my code -- or better yet, submit a pull request yourself -- they might just take it. (I would submit a pull request myself, but right now I don't have time to write the necessary unit tests, etc...)
EDIT: OK, against my better judgment I took the time to prepare a pull request: https://github.com/google/protobuf/pull/710
Looking through the Java "low level" API to access the Google AppEngine DataStore, it seems to do a lot of heavy lifting and tons of type-checking, parsing, flattening, object creation, etc. which my App doesn't really require (it's wayyyyy too general for my needs).
Therefore, I'd like to get "even lower-level" access to the underlying functions (e.g. by calling com.google.apphosting.api.ApiProxy.makeSyncCall(...) directly) to skip a lot of the (for me) unnecessary overhead, and (who knows) maybe even discover some additional performance-features in the process that aren't accessible otherwise.
For this, I would need to use the classes inside com.google.storage.onestore.v3 directly to build the raw binary request packets and interpret the reply packets.
Of course, it's possible to examine the way things work (roughly) by looking through the source code of the classes inside com.google.appengine.api.datastore, which use these classes, but things would be so much easier if I could also get a hold of the JavaDocs for the classes inside com.google.storage.onestore.v3. Unfortunately I can't find them anywhere (the source-code isn't available either). Has anyone here maybe come across them somewhere?
I've been doing some programming in Java and some in C but now I need to sort of use both together.
Here's the situation, I'm using Hadoop/Hbase to process and store a lot of data but I'm using C/Cuda to do number crunching on the data. Is there a stable/mature/common way to take data (it's basically a log file) in Java and pass it to a C program, which C processes the data it stores it as a linked list that is then accessible by the Java app?
I might not be searching for the right thing, but so far I found JavaCPP, which is good but seems to involve both programs together. Because Java handles the data flow and C handles the processing of the data, I thought it might be better to keep them as independent programs that can communicate to each other as opposed to a single program that may become confusing. But I'm totally flexible so any suggestions/solutions are welcomed.
You may find it easier to keep the programs testable and clear if you leave them separate and then use a client-server approach, or simply choose a common file format and have the latter steps poll the output directory for new files to process.
To make it easier to define file formats across different languages, consider a package like Apache Thrift or Google Protocol Buffers.
Here what I have on the top of my head
1. run C program using command line from java app.
2. Use JNI/JNA
3. Implement your own "client-server" architecture. It sounds complicated but in some cases it may be the best and the simplest solution.
4. Communicate using Web service, SOAP, REST, whatever.
I hope this is helpful for the beginning.
You are welcome to ask more specific questions once you have.
I'm currently developing a GUI for a Java-application that I've created. I would like to keep the GUI in a separate process from the rest of the client. The rationale behind this is:
Reduced risk of crashing. E.g. a OutOfMemoryError in the GUI won't crash the rest of the client.
I get an API "for free". If I later on want to allow other people to programmatically access the client I can just let them use the same API that the GUI is using.
I'm writing the GUI in SWT and the client is created using IntelliJ. Since Eclipse has a lot better SWT-support it makes sense to keep them separate, so that I can use Eclipse for the GUI-code and IntelliJ for the rest.
My question is now: what technology should I use to expose the client's interface to the GUI? RMI is what came to mind first. However, that has the disadvantages of restricting the API to be Java only. I'm also not sure about how well suited RMI is for large scale deployment (e.g. how does it handle local firewalls?). However, I don't want to rule it out just yet.
I should also mention that I have some deployment-requirements as well:
Must be able to run as non-admin.
Must be able to handle restrictive local firewall-restrictions.
Deployment must be automatic (it's a large scale consumer-app) and work on Windows, Mac OS X and Linux.
Given these restriction what solution would you use?
I faced this same situation a while back, except that the back-end was in Python, and the GUI was in java.
Important points to consider:
how flexible and granular the interface between the GUI and the back-end needs to be. Do you want to be able to do one thing from the GUI? 5 different things? 10? 50? How tightly coupled is the GUI -- will it know about/be calling individual methods in the back-end?
how the output gets from the back-end to the GUI. Can it simply write to STDOUT or to temp files? Does it need something more elaborate?
the format of the output. Ideally, it should be easily parseable, which indicates XML or JSON may be your best bet.
You might find JSON-RPC useful: it's a standard for remote method calls to separate programs.
All in all, it's hard for me to say what would be best for you. I ended up avoiding RPC, and gave the back-end a simple command-line interface; output was written to temp files and STDERR, as JSON objects. I feel that this was a good decision because it kept the interface between the programs very simple and uncoupled.