We Keep Coding

updating Notes document(s) via java

I am re-writing a Domino application with XPages. I have setup a basic CRUD implementation with help of Java classes. I am now at the point that I am creating/editing documents.
Since I am not so familiar in this area my code for now only worked with formats like text and date.
Where can I find examples how to work with other formats like multiple value fields, rich text, attachments, names, authors?
I assume I cannot cover every type of field via getItemValue(String) and replaceItemValue, or can I?

If you want so save yourself a lot of headaches, deploy the OpenNTF Domino API (ODA). It takes care of recycling, provides proper Java collections, allows for easy extraction of MIME and JSON.
There's an intro on openntf.org and you find some YouTube videos on it. Or head to Paul's for more info: http://www.intec.co.uk/ibm-connect-2017/

I tend to use Views wherever I can as I believe it is quicker than getting the document. It can be a little unwieldy though if you have lots of columns.
So using dates you need to convert from Notes DateTime to a Java Date.
Getting
account.setDateExpiry1(((DateTime)entry.getColumnValues().get(17)).toJavaDate())
or
account.setDateExpiry1(((DateTime)entry.getColumnValue("Column Name")).toJavaDate());
If I get the document I would use something like this.
item = doc.getFirstItem("DateApproved");
account.setDateExpiry1(((DateTime)item.getDateTimeValue()).toJavaDate());
or
account.setDateExpiry1(((DateTime)doc.getItemValueDateTimeArray("DateApproved").get(0)).toJavaDate());
Setting
With Dates you have to create a Notes DateTime object.
So something like
Date tmpDate =(Date)account.getDateCompleted();
doc.replaceItemValue("dateCompleted", (DateTime)Session.createDateTime((Date) tmpDate));
Similar concepts apply to Name Fields etc, however, there does not appear to be an easy way or direct 'java' replacement for the XPages upload and download attachment controls. You need a solid understanding of the more advance techniques in Java on this. I have struggled but I do need to revisit it. There are some examples on this forum. The same applies to Rich Text, my understanding is you need to become fully conversant with MIME - which I am not.

Java framework to manage BLOB data outside of database

I want to store my blobs outside of the database in files, however they are just random blobs of data and aren't directly linked to a file.
So for example I have a table called Data with the following columns:
id
name
comments
...
I can't just include a column called fileLink or something like that because the blob is just raw data. I do however want to store it outside of the database. I would love to create a file called 3.dat where 3 is the id number for that row entry. The only thing with this setup is that the main folder will quickly start to have a large number of files as the id is a flat folder structure and there will be OS file issues. And no the data is not grouped or structured, it's one massive list.
Is there a Java framework or library that will allow me to store and manage the blobs so that I can just do something like MyBlobAPI.saveBlob(id, data); and then do MyBlobAPI.getBlob(id) and so on? In other words something where all the File IO is handled for me?

Simply use an appropriate database which implements blobs as you described, and use JDBC. You really are not looking for another API but a specific implementation. It's up to the DB to take care of effective storing of blobs.

I think a home rolled solution will include something like a fileLink column in your table and your api will create files on the first save and then write that file on update.
I don't know of any code base that will do this for you. There are a bunch that provide an in memory file system for java. But it's only a few lines of code to write something that writes and reads java objects to a file.
You'll have to handle any file system limitations yourself. Though I doubt you'll ever burn through the limitations of modern file systems like btrfs or zfs. FAT32 is limited to 65K files per directory. But even last generation file systems support something on the order of 4 billion files per directory.
So by all means, write a class with two functions. One to serialize an object to a file; given it a unique key as a name. And another to deserialize the object by that key. If you are using a modern file system, you'll never run out of resources.

As far as I can tell there is no framework for this. The closest I could find was Hadoop's HDFS.
That being said the advice of just putting the BLOB's into the database as per the answers below is not always advisable. Sometimes it's good and sometimes it's not, it really depends on your situation. Here are a few links to such discussions:
Storing Images in DB - Yea or Nay?
https://softwareengineering.stackexchange.com/questions/150669/is-it-a-bad-practice-to-store-large-files-10-mb-in-a-database
I did find some addition really good links but I can't remember them offhand. There was one in particular on StackOverFlow but I can't find it. If you believe you know the link please add it in the comments so that I can confirm it's the right one.

How to invoke applications on BlackBerry

I'm new on this world of BlackBerry and the thing is that i have a byte array of certain file that can be anything (picture, pdf, txt ...) and need to be shown. How can i execute applications related with the specific extention? In other words how can i invoke an application and give it the byte array to be displayed as the original file?
I also have the extention or file type.
I have tried to open the file using browsers but it always return timeout and that's not the idea.
Here is something like my question but it has not a final response. I'm developing for BlackBerry Curve.

I have never used it, but I think the appropriate API for this is the Content Handler API, most commonly referred to as CHAPI I think. Look for documentation of javax.microedition.content. Here is a link that will take you to the ContentHandler class.
I suggest that you look for the chapidemo sample for more information. It should have come with your tooling, if not, here it is on github: chapidemo sample.

How do you Edit MP4 ID3 Tags in Java?

I asked a similar question some time ago, but with python, and have since then decided to switch to Java because there seemed to be more resources to do this sort of thing. Basically I need some sort of library, idea, or instructions that would allow me to edit ID3 tags in an MP4 file like the kind found in iTunes. If anyone knows anything, your help would be greatly appreciated.
So far I've done the following:
I've found this question/answer to a very similar problem: How do you Edit Video ID3v2 Tags in Java (it describes how to use a library intended for audio files called JID3 to edit video ID3 tags), but I can't figure out for the life of me how to actually import it into an eclipse project and use it. I basically unpacked it and added all the packages into the project, but the one time it worked it made the movie file unreadable to any media player afterwards. If anyone has specific knowledge of how to import and use JID3 that would be great.
I've found this site: http://willcode4beer.com/parsing.jsp?set=mp3ID3 which has some seemingly good code for reading and writing ID3 tags, unfortunately it does not work properly constantly returning strings of question marks or telling me that the file is not there spontaneously (it will literally work one time and then not work another time without any changes). Nevertheless I like the idea of simply reading the bytes or ASCII of a file and finding/editing the ID3 tag that way so if anyone knows what to do for that, that'd be awesome.
Thanks in advance.

The metadata in MP4 is not necessarily in ID3 format. There is the possibility to use ID3 but it is not widely used. The ID3 bytes are then in /moov/meta/id32 box.
The iTunes files bear their meta information in /moov/udta/... there are multiple boxes like '#cmt', '#nam', '#des', '#cpy' that contain each a string for (in this case) comment, name, description, copyright. Have a look at http://code.google.com/p/mp4parser/ to visualize, parse and write MP4 files.

If I understand you correctly you want to be able to edit such metadata as: artist, track, cover image etc. and then be able to see your changes in iTunes or QuickTime.
In that case you may want to look at the new API available in JCodec (org.jcodec.movtool.MetadataEditor).
It also has a CLI (org.jcodec.movtool.MetadataEditorMain).
Here's the basic usage:
# Changes the author of the movie
./metaedit -f -si ©ART=New\ value file.mov
or the same thing via the Java API:
MetadataEditor mediaMeta = MetadataEditor.createFrom(new
File("file.mp4"));
Map<Integer, MetaValue> meta = mediaMeta.getItunesMeta();
meta.put(0xa9415254, MetaValue.createString("New value")); // fourcc for '©ART'
mediaMeta.save(false); // fast mode is off
You can find a complete documentation here: http://jcodec.org/docs/working_with_mp4_metadata.html

Creating an uneditable data file in Java

I am currently writing a program which takes user input and creates rows of a comma delimited .csv file. I am in need of a way to save this data in a way in which users are not able to easily edit this data. It does not need to be super secure, just enough so that it couldn't accidentally be edited. I also need another file (or the same file?) created to then be easily accessible (in the file system) by the user so that they may then email this file to a system admin who can then open the .csv file. I could provide this second person with a conversion program if necessary.
The file I save data in and the file to be sent can be two different files if there are any advantages to this. I was currently considering just using a file with a weird file extension, but saving it as a text file so that the user will only be able to open it if they know to try that. The other option being some sort of encryption, but I'm not sure if this is necessary and even if it was where I would start.
Thanks for the help :)
Edit: This file is meant to store the actual data being entered. Currently the data is being gathered on paper forms which are then sent to the admin to manually enter all of the data. This little app is meant to have someone else enter the data from the paper form and then tell them if they've entered it all correctly. After they've entered it all they then need to send the data to the admin. It would be preferable if the sending was handled automatically, but this app needs to be very simple and low budget and I don't want an internet connection to be a requirement.

You could store your data in a serializable object and save that. It would resist casual editing and be very simple to read and write from your app. This page should get you started: http://java.sun.com/developer/technicalArticles/Programming/serialization/

From your question, I am guessing that the uneditable file's purpose is to store some kind of system config and you don't want it to get messed up easily. From your own suggestions, it seems that even knowing that the file has been edited would help you, since you can then avoid using it. If that is the case, then you can use simple checks, such as save the total number of characters in the line as the first or last comma delimited value. Then, before you use the file, you just run a small validation code on it to verify that the file is indeed unaltered.

Another approach may just be to use a ZIP (file) of a "plain text format" (CSV, XML, other serialization method, etc) and, optionally, utilize a well-known (to you) password.
This approach could be used with other stream/package types: the idea behind using a ZIP (as opposed to an object serializer directly) is so that one can open/inspect/modify said data/file(s) easily without special program support. This may or may not be a benefit and using a password may or may not even be required, see below.
Some advantages of using a ZIP (or CAB):
The ability for multiple resources (aids in extensibility)
The ability to save the actual data in a "text format" (XML, perhaps)
Maintain competitive file-sizes for "common data"
Re-use existing tooling support (also get checksum validation for free!)
Additionally, using a non-ZIP file extension will prevent most users from casually associating the file (a similar approach to what is presented in the original post, but subtly different because the ZIP format itself is not "plain text") with the ZIP format and being able to open it. A number of modern Microsoft formats utilize the fact that the file-extension plays an important role and use CAB (and sometimes ZIP) formats as the container format for the document. That is, an ".XSN" or ".WSP" or ".gadget" file can be opened with a tool like 7-zip, but are generally only done so by developers who are "in the know". Also, just consider ".WAR" and ".JAR" files as other examples of this approach, since this is Java we're in.
Traditional ZIP passwords are not secure, and more-so is using a static password embedded in the program. However, if this is just a deterrent (e.g. not for "security") then those issues are not important. Coupled with an "un-associated" file-type/extension, I believe this offers the protection asked for in the question while remaining flexible. It may be possible to entirely drop the password usage and still prevent "accidental modifications" just by using a ZIP (or other) container format, depending upon requirement/desires.
Happy coding.

Can you set file permissions to make it read-only?

Other than doing a binary output file, the file system that Windows runs (I know for sure it works from XP through x64 Windows 7) has a little trick that you can use to hide data from anyone simply perusing through your files:
Append your output and input files with a colon and then an arbitrary value, eg if your filename is "data.csv", make it instead "data.csv:42". Any existing or non-existing file can be appended to to access a whole hidden area (and every file for every value after the colon is distinct, so "data.csv:42" != "data.csv:carrots" != "second.csv:carrots").
If this file doesn't exist, it will be created and initialized to have 0 bytes of data with it. If you open up the file in Notepad you will indeed see that it holds exactly the data it held before writing to the :42 file, no more, no less, but in reality subsequent data read from this "data.csv:42" file will persist. This makes it a perfect place to hide data from any annoying user!
Caveats: If you delete "data.csv", all associated hidden data will be deleted too. Also, there are indeed programs that will find these files, but if your user goes through all that trouble to manually edit some csv file, I say let them.
I also have no idea if this will work on other platforms, I've never thought to try it.