Applications / Libraries
|Combined application||IDE, java shell, client/server - download|
|Page 1 application||RSS feeds, Atom, blog, with search engine personalization|
|Transparent Random Zip (TRZ)||dynamic zip access|
|utillib package||utility library.|
|appedit||app launching, extracting, parsing, mostly OS/X|
|temporary current jnidirect||Until I figure out a little more cvs keeping this here|
|launch -||Obsolete and discontinued. Mac Classical OS minimal command line|
|Sunday Sudoku Solver||Sudoku solving with a programmatic eraser|
|antdoc||XSLT to HTML for ant build.xml files|
|performSelectorOnMain||JNI callback to java on AppKit 'main' thread|
|LSSpy||Launch Services API application|
|Mail.app signatures||Mail app certificate signature info. (Java/osascript/Bouncycastle)|
|AKS and primes||deterministic time prime number algorithm|
|Mersenne Twist||Prime number benchmarking|
|pdfsign||Crypto signing PDF documents|
|stub||java property based launching frontend stub (see appedit, obsolete 'launch').|
|Astronomy related||Meeus, planetarium, Fundamentals of Astrodynamics - ongoing tinkerings|
|hprof constructor kit||Modifying the Sun hprof sample source code|
|Chess blog||No code, rambling chess related blog, I needed a job - I still do|
|Java Radio Station||Tinkering with the Apple java mp3 streaming code sample|
|Stack Walker||Old attempt at java call chain determination using exception trace|
|PGPTester||El Gamal key generation testing with a little reverse arithmetic|
|Open document||OS X Open document handling and launch options|
|AppleEvents JNI||JNI AppleEvent wildcarding with eawt type interface for get URL events|
|src_index.html cross-reference index of useful downloads and sources|
With so many other fine IDE's available, and no one using this that I am aware of, I have not been doing active uploaded
support. I have continued to use it myself though.
After using the fzap command to post a hex dump of a manifest file to the OS X java-dev mailing list I was reminded that having some way for that to show as a monospaced font in the application terminal window was one of my oldest to-do items. So I added that as well as a little splash of color. One color for log4j info lines another, red of course, for error lines. A different color if a line comes from montioring console.log or system.log. etc. A little fireworks for the 4th of July, so I'm posting the update.
I have had a couple other automation related ideas for the application, if they result in any code that I think could be useful to anyone I may still post another update or two.
extended.jar [OPTIONAL 07.17.05] is sort of the ClassLoader and search engine parts for standalone testing outside the application.
Combined.zip. The application itself.
No really new cutting edge ideas here but a start at some things that interest me. RSS and blog stuff. With some search engine functionality stuck on to allow it to automatically highlight areas of personal interest - sports, music, international news or whatever you like to keep current on. Sort of a personalized newspaper is the vague concept at the moment.
Latest Update 12/3/6
Not a lot of progress. But uploading what there is.
Actually built on "ROME, the premier newsfeed parser library for the Java platform"*
- RSS And Atom In Action, David Johnson
At some point I am still planning on including search engine type support for personalization by allowing selection of content of interest. The intent for now is to base that on Lucene.
I also added in some code indicated on the OS/X java-dev list at The Rabbit Hole
Anyhow, its still interesting so I will probably put more time into it.DOWNLOAD: page1.zip
(Last updated 07.17.05)
11.23.06 Corrected a couple errors preventing the verify application itself from launching and working correctly. Also added a JVMVersion check since JarBundler default setting of this to 1.4* fails with class files compiled at 1.5 or I'd assume later.
03.26.06 Playing around with adding some more functionality to the AppEditVerify application. Quaqua JFileChooser, Bouncycastle message signing using the Apple KeychainStore keystore. The lack of any validity to key retrieval still seems insecure to me. Also some attachment support using the mail API's. Not sure the download verify report as attachment is working correctly. The download other option, where the user can select a file to attach seems ok. It doesn't seem to email back to me at the moment but email has been a little strange for a couple days. It emails fine to my Yahoo email account. Signing seems to work correctly with or without attachments. So a fair amount of new functionality to play with and a few tweaks and refinements still needed for that.
The full download includes plist parsing, double-clicked self extracting jars, stub launching with MRJ Adapter front-end and so on are included in appedit.jar
Application for verifying OS/X java application bundle correctness is AppEditVerify.dmg
Toolkit for doing other things with application bundles. This includes the start at a application to build more complex self-extracting (OS/X) jar files. Accum for now, will probably name it File Drop at some point. It supports the file drag and drop API to a JTree. There is a neon animated image tacked on that is also supposed to accept the file drops but doesn't yet. Trying DnD and doing some kind of neon l&f controls a couple things I've thought about trying in the past. All of this still very simple at this point. Definitely seems to work well enough for wrapping a singe .dmg, see DocumentMonster below as well.
Temporarily trying to keep more current changes here until I get a better idea of cvs updating the SourceForge project
The source is here
Current work in generation of a Cocoa Java type interface - OS/X Terminal usage would be something like...java -cp jnidirect.jar:Linker.jar genns -t "
Update 09.25.05 I probably should mention here that my current JNIDirect project is trying to automatically generate as much of a interface to the Cocoa API's as I can manage. Last changes in brief, handles more non-'int' types better.
Successfully running some Cocoa things off the generated, JNIDirect and jnilib. Bundling it all up in a jar now jnicocoa.jar. That includes a README in the 'jni' folder so more information there now instead of here
06/28/09 Changes to ensure it works reasonably well with a basic OS X XCode Java template generated ant build file, a little more effort into correctly placing comments. Also minor changes to property display, additional documentation links, etc.
Basically just add the following somewhere at the top of your ant, build.xml or whatever, file.
<?xml-stylesheet type="text/xsl" href="test-xslt/ant.xsl" ?>
This shouldn't interfere with execution of the build, or with editing of the build file.
The XSLT file ant.xsl that was just mentioned, as .txt.What it does do is give you a nice HTML view of the build file if you select it with a browser. A little closer to a gui view than the cli ant -projecthelp anyhow. It is also IDE independent. All you need is your browser going. I would of thought someone would of done one for the exercise but a quick search didn't seem to turn one up. So I tried it as a XSL/XPath learning exercise for myself.
It links to the documention for the tasks. You can change that URL to local disk in the ant.xsl here...
<!-- Location of ant documentation, change to local disk if you prefer -->
<!-- <xsl:text>file:///???/apache-ant-1.6.5/docs/manual/</xsl:text> -->
If you have any ant build's that this doesn't display correctly or well, let me know and I'll see if I can improve this.
NSAppleScript execution and possibly other Cocoa Java classes should be run on the AppKit 'main' thread. OnMain.dmg provides a small JNI stub to do a callback to java on the main thread that should provide this.
10/28/2006 - More new functionality. Added Some JNI, generated of course, execution of the AppleScript related
10/22/2006 - Added some additional AppleScript testing and a couple execution option switches. More or less documented in the README file.
A start at a small application using the Launch Services API's. Mainly to verify that LS settings are correct for your application. This might be a good addition to the appedit stuff but that's already messy enough. Possibly I will merge in some of the functionality later. One difference already is it uses xerces instead of MinML to parse the Info.plist XML. The code translated easily, I guess both must conform closely to some API spec. It is initially included with another small bit of code I did earlier that demonstrated some Launch Services functionality along with an early effort at showing the possibility of converting some JNIDirect to a bundled jnilib.
It should support wildcarded file open document events and is I think my first uploaded effort using the technique of putting up a splash screen while it waits to see if it receives any file drops. (Very artistic splash screen no?) If after 'x' time no open documents are received, it throws up a quaqua FileChooser dialog. For another little bit of my own code the quaqua FileChooser includes some modifications of mine to show a slightly larger scaled icon as a file preview. Werner Randelshofer declined to use that when offered, having his own plans for icon previewing, using Cocoa if I remember right, in a upcoming release.
Now I just need a actual application to follow all of that stuff.
Last update a little clean up. I've found a lot of my applications aren't even the ones I think they should be for the creator codes. Didn't expect that. The Launch Services API's aren't real geared toward repairing or updating a lot of this. I was going to go with the old 'duplicate the app' trick to correct losing file assocations but do not think that would fix the creator thing. Not real driven on this one at the moment. Need someone having more problems with it to move up the to do list again.
NEW - 10/15/2008
The JNIDirect SignatureToApp class has been one of my own favorites going back to when it supplied some enhanced Classical JDirect MRJFileUtil capability. The following is a straight JNI version showing how JNIDirect might still work as a JNI 'code generator'. I have trimmed out some of the unnecessary dependencies and have gotten the size of jnilib plus jar well below 300K. I think theres enough API for this to be reasonable overhead
There is nothing wrong with the OS X 'open' command. But it isn't extensible and it isn't open source. Such as it is, this is those things. It does add a couple bells and whistles already that 'open' doesn't do and more functionality could reasonably easily be added.
But for this one, for now, this is it. Enjoy if you wish.
Viewer for Mail.app signatures with osascript Runtime exec of AppleScripts and the BouncyCastle API's for handling the digital signatures. I had added this to my Combined application but it probably makes more sense as a standalone demo.
Changed to use current Bouncy Castle crypto jars and now bundle them in the download. Fixed incorrect 'return' character included in the AppleScript for mailboxes with multiple accounts. Fixed name on certificate information display dialog I Included a launching script with AppleEvent debug environment variables that I didn't get to work right. Download is now a dmg
Mail.app still doesn't seem very good about showing this information itself. I filed a bug this time (ID 6460099). I also put in that Mail.app seemed to require two accounts to set up a signature. I found decent signature set up directions for Mail.app signing certificates here.
Previous of the coding blogs. Follow up curiosity to the MersenneTwist related - sort of.
First, since this is supposed to be a blog of sorts, maybe I should have something sort of anecdotal. Although blogs of the diary type, 'today I stubbed my toe' or whatever, usually seem pretty uninteresting to me.
The year is sometime in the very early 70's. I take the old fashioned telephone handset and stick it in the coupler that passed for a modem at the time. My high school math teacher sticks his head in the small closet sized room housing the dialup network equipment, the coupler and a teletype printer is about all of that, that I'm remembering, and asks what I'm doing. I'm not sure if this is simple curiosity or he suspects me of being the first hacker trying to break into the defense department or in some other way up to no good. I tell him just running my (Basic) prime number program.So, this is one of my first memories of anything 'computer' - with prime numbers being about the first thing I remember that interested me related to computers. So my interest in prime number programs has a little history and some roots anyhow.
Ya know, I'm starting to sound a little like grandpa Simpson on the Simpsons.
Anyhow the main curiosity was could some real prime number crunching with the current state of the JIT be done as quickly as the same algorithm could native compiled. Alas, the answer so far is that compiled is 4x faster at least as far as my first pass programming skill goes. The code is number.jar if of interest.
A few of the related links I came across if any of those of interest
AKS Primes is in P Primes Mersenne Primes For fast square roots More on elementary functions Wouldn't be complete without considering rational approximations Some floating point considerations Yet more functions A floating point TechTip Some of this from a more crypto viewpoint A presentation of how algorithm efficiency, time, complexity, what have you is measured
The internet is in my opinion a tremendous resource. The truth is out there. Sometimes it takes some sifting, sometimes a fair of amount of slogging through, and sometimes you still aren't sure you found the absolute TRUTH. But there's a lot of good, free info and stuff. Really, in my opinion there should be courses just on researching the internet. As it is I'm remembering some interesting pages that are not included above. How does the expression go that the journey is more interesting than the destination. Tracking down these things is usually like that, you almost always find something at least equally interesting along the way to what you're looking for. Thats part of what these code blogs are supposed to demonstrate I guess.
A new coding blog. I became curious concerning questions of the speed of java.util.Random that came up as a topic on the BouncyCastle mailing list (Sign-up URL below with PDF stuff if interested). Sean Luke, who sometimes frequents the OS X javadev list, had done a java replacement for java.util.Random based on the MersenneTwist random number generator. For my coding I grabbed the version included with ECJ although it can be linked to more directly it seems here?.What I wondered was if the MersenneTwist could be used as a java.util.Random replacement for purposes of cyrpto. From the Mersenne Twist FAQ.
Mersenne Twister is not cryptographically secure. (MT is based on a linear recursion. Any pseudorandom number sequence generated by a linear recursion is insecure, since from sufficiently long subsequence of the outputs, one can predict the rest of the outputs.)
To make it secure, you need to use some Secure Hashing Algorithm with MT. For example, you may gather every eight words of outputs, and compress them into one word (thus the length of the output sequence is 1/8 of the original one).
So that is how I proceeded. I decided to first see if native JNI provided any significant performance differences and if performance with a hash included would still be on a par with Random.
Sample numbers arrived at for Sean Lukes 100000000 generated random int's speed test were as follows...
Times in milliseconds, so 19440 is 19.440 seconds. Fast is the everything in JNI version. Cokus is a suggested optimized version from the Mersenne Twist page. Returned state means the 624 int array Mersenne Twist state is returned in one chunk instead of a int at a time. SHA1 w/ state means that first I hash the 624 int array already mentioned and then return the 390 element int array result as one chunk. I translated the BouncyCastle java SHA1Digest class to C for the Sha1 hash.
Something possibly to note would be that unless the state is returned the JNI versions use significantly more time for all those invocations. If state is returned - that is the 624 element int array for the MT state, or the 390 element array for the hashed result - accesses are then done against that until it's used up when another JNI invocation becomes necessary. 'Returned state' thus resulting in considerably fewer JNI invocations, where all that is usually being done is returning an already computed int value. If you get the state all at once you get considerably better time because you are calling JNI considerably fewer times.
The other thing maybe to notice is that if state is returned even with the SHA1 hash the times are faster than Random. This somewhat surprised me but I think may mean this wasn't a totally pointless exercise. Anyhow it isn't complete. I would like to appy some of the standard RNG tests to my hashed results to see if they still seem to be good RNG's. I'd also like to consider what is mentioned on John Savard's page concerning the Mersenne Twister and it's use as a keystream generator for a stream cipher. To throw in one last link on this rather link intensive blog, pLab - a RNG site or so I gather - mentioned AES makes a nice RNG which I find interesting and might look at.
I guess if you're still reading this you might be interested in mt.zip the code
The topic of signing/verifying PDF documents came up on the BouncyCastle mailing list. It seemed sort of interesting to me so I started seeing what I could do with it. Not as easy as it sounds - for me anyhow. Currently I can verify for the /adbe.pkcs7.detached signatures that are included in PRAcroForms. At least I assume what I have would successfully work for any such setups. Testing is limited so far to only a few signed PDF documents I have found. Left to do, I have verifying if not PRAcroForm included, signing support besides verifying, and support for the /adbe.x509.rsa_sha 'raw' signatures.
The first document I've been testing with is xsignarticle.pdf here. This document uses the PKCS7 detached and is included in the PDF PRAcroForm field. What I have should handle it.
The second document is Adobe provided from here. The income tax form. This I do not handle yet but hopefully will shortly. Assuming theis pae is somewhat current this may actually be assumed to be the current recommended method of handling signatures?
Anyhow, what I have currently is PDFVerify to verify
03.01.04 I have somewhat simplistic signing working. That is I can attach a signature to a document I am creating and PDFVerify will verify the signature as valid. AcrobatReader 6.0 will not. It will indicate the presence of the signature but doesn't show it as default certificate type as it shows it's own signed ones. And it doesn't enable validity checking itself of the signature as it does it's own.
Anyhow the stuff included in as far as I've got...
PdfSignature.java modified version of the iText class.
PdfHexString.java an iText addition of my own for this. These seem to get handled elsewhere correctly without requiring this class but I haven't determined how and it seemed simple enough to add one.
What may also be of interest, located here for the moment until I figure out where to leave them.
I used this tweaked iText PdfLister.java for parsing practice
And this modifed BouncyCastle code, ASN1DumpLabeled.java to try to figure out what I was parsing
Thought there was more. But I guess that's it for now
Some reflection launching to handle Open Document events and other Mac specific functionality using Steve Roy's MRJAdapter. Perfanal for hprof output parsing the sample application. For now URL for that and other info available with the download off my iDisk. More time into better info and links here sometime
Share for the heck of it again. Started coding a little java again. I've been doing some reading and it seemed possibly apt to set some of it to code. I then remembered I also had some old sort of related code I'm also throwing in. Might be a bit of an incentive to improve on that.
So basically this includes three different things.
I'm always trying to convert the code from Astronomical Formulae for Calculators into some programming language or other. This would be the Java version as far as it's gotten which is about as far as I've ever gotten.
This also includes the java version of my "Planetarium stuff". This also goes back years and years. Originally probably done in MacForth if that means anything to you. Started off some Astronomy for PC's book I found in the Minneapolis public library. It is supposed to be somewhat similar to Martin Minow's spinning earth applet, or more like Kerry Shetline's code. You can find him and the link in the MRJ archives. Mine is not that far although I now have "Map Projections - A Working Manual" and no excuse really for not getting it working better. Lack of stuff to show other than the hard-coded stars of Leo I usually test with is one problem. Finding and adding in some suitable database support is probably a near top of the list to-do.
Fundamentals of Astrodynamics
The last thing is adding code from another old book I have. I've owned it probably going back decades. The math seemed a bit stiff so I never went through it. Having the time, too much, I started reading it and this was one again where it seemed to me that it really should be set to code. So I started doing that. Not going too badly. I'm also, having too much time, going through some of my college Calculus and Physics books which so far has given me the math and knowledge I need to muddle along. Actually little calculus required up to now. Orbits have always fascinated me for some reason.
OK, enough talk, the code such as it is...
iDisk salvage. Attempt to use the Sun provided hprof demo code to consider a couple things. First, is there any useful distinction to be made in profiling by making a difference between wallclock and cpu time. Second, can the source of potential I/O bottlenecks be determined. Currently some slapped together documentation with maybe some useful hprof and profiling links. I still have to decide if it's worth putting more time into this with JVMPI changes at 1.5.
Tangental free association blog. I've been getting back into Chess a little bit again lately as well. If are yourself into Chess to the extent that you have looked over any Chess books you may of heard of Grigoriev. Grigoriev had probably the most cited and chess book included end game studies. Theres nothing all that unusual in this, someone has to be the most noted in about anything. The somewhat interesting oddity I remembered seeing somewhere was that Grigoriev's real day job occupation was something like a forest ranger who lived in a tower looking out for forest fires. Which I guess goes to show that it is sometimes useful to you to have interests to pursue. Maybe if you're lucky something nice even comes out of following those interests.
Looked at this a bit ago. Might as well 'share' for the heck of it. I tried the kind of old Mac JavaRadioStation sample code. I had to add the following as the first line to the computeLength method in MP3File.java...
if (fBitRate == 0) return (long)0; // mjh
...because 0 lengths crashed it. Might be files with variable bit rates mentioned as not handled somewhere. I put the following MyStation to the same, code base, directory as the sample jar file. I started up iTunes, did an "Open Stream" for http://localhost:8000 and there you go. Sounded as well as iTunes usually does.
There are probably more sophisticated options out there than this by now and it's probably sort of naive of me to think gosh thats kind of cool. But if anyone else has or does do any tinkering with this - I'd be interested in hearing about it.
This one was a suggestion from someone on the list, I forget who, for a stack trace you could access and base runtime action on. That was my thought and is what this does, an exception stack trace is returned in a String . It didn't provide the answer for the problem I was concerned with but may be useful sometime. It won't work applet unless you've figured out how to get past the System.set security restrictions which I haven't yet. [For commandLine IE (local) still is throwing a one line (unidentified) missing class exception at the moment. HotJava agrees with AAR that System I/O re-dirction is a bad thing at this point.]
The following would give you a stripped down stack trace...
String  t = new stackWalker().trace();
for (int i = 0; i < t.length; i++) System.out.println(t[i]);
Finish the year with a little code exercise inspired from this bouncy castle list thread.
Testing showed that it spent most of it's time in the BigInteger prime number constructor. So to improve things you need to improve BigInteger, I've messed with that, not easy. Or change the algorithm, but theres not much algorithm to change. Just the p = 2q + 1 equation - where q is found, and p is determined where both need to be prime. However, it occurred to me the equation could be applied twice. As done above, and then you can take your first prime as p instead of as q and solve in reverse for q = (p - 1) / 2.
Not real complicated math but it does give you another chance at a solution without having to just start over.
For my testing with 1000 trials at key sizes of 512, 768, 1024 and 1280, there were 9 successful p,q's found going forward [p = 2q+1] and 5 found going backward [q = (p-1)/2]. Those results can be seen at pgptester.txt. The test's PGPTester.java sourceNot a bad success increase. Of course the reverse numbers are smaller which tends to be 'less good' in crypto.
However, given Gauss's determination that the number of primes up to any given 'n' approaches...
Prime Number Theorem
π(n) = n/log(n)
which means as I understand it that the bigger the keys you try for the sparser the primes are going to be. So a method that increases the number of successes and actually does so by testing against smaller numbers might not be all that bad an idea. Of course the math for primes this size might just be ruling the whole approach out.
A couple URL's were mentioned on the bouncycastle forum that should improve determination of these "safe primes"
as they are called.
Safe Prime Generation with a Combined Sieve
and Double-Speed Safe Prime Generation
My idea is mentioned in passing, so I guess I'll have to cancel that patent application. Someones been there and done that.
As it turns out, this idea doesn't work anyhow. The algorithm is designed to start out with the 'q' bit length one less than what the resulting 'p' length should be so that the final 'p' bit length value is correct after the 1 bit left shift that always happens from the multiplication by two in p = 2*q + 1.
Taking the original random value as 'p' for going backward [ q = (p-1)/2 ] means that it's length is one bit too short to start out. Which doesn't work for the exact length required by the ElGamal algorithm.
So not only no patent, but back to the drawing board.
A considerably faster version for bouncycastle may be appearing without the need for it
Open document handling for OS X java applications is much better than it was at one point in time, but still has some potential difficulties.
As far as the open document handling itself goes to the best of my understanding the following is true
|Configuration||Open Document||Other events*|
|CFBundleExecutable: is a JavaApplicationStub||WORKS||WORKS|
|CFBundleExecutable: is a Unix script|
which finishes by running a JavaApplicationStub
|CFBundleExecutable: is a Unix script|
which finishes by running exec java or java
For more information on using a shell script instead of a JavaApplicationStub for launch, see Greg Guerin's prelude scripts
The test case that I wrote for this is DocumentMonster.dmg This is a self-extracting jar containing the former .dmg file. Works better with my current ISP setup. See the app Toolkit download above for the application that creates the self-extracting jar. It includes some .dropper file extension files for testing by dragging to the application icon. It issues println messages to Console.app indicating success. If you look in the applications Contents/MacOS folder you will see the Prelude script that may be used in place of the JavaApplicationStub. You might want to look at Greg Guerin's information, from above, before getting much farther along with that.
Currently it is set to the script running java directly, where open document events fail condition. So to see it actually succeed in handling open document events you will either need to change the script or Info.plist to run the JavaApplicationStub instead. Of course, then if it doesn't succeed you need to determine if you did this correctly or Launch Services is now not working. More on that in the following
Launch Services Issues: There are other concerns that figure in when you start changing the Info.plist entries or adding and changing scripts within your OS X application bundles. These changes can break Launch Services functionality for your application in different ways.
NOTE 12/12/7 Since this was originally written further experience has led to a better understanding of this issue. This problem seems to mainly occur following some kind of manual update.
e.g. right clicking the application bundle and using Property List Editor to modify the Info.plist file doesn't update Launch Services and can break functionality.However, if you use a IDE that updates the file as part of it's build process you do not run into the problem. So, the issue is avoidable if you use a less direct process, or a more mainstream process, if you prefer to look at it that way.
More details on the concern follow.
Some OS X java-dev mail list posts reflecting some of the problems and their work arounds
Its sort of insidious knowing if Launch Services being out of sync is actually your problem, or configuration, or something else. The lsregister command can get you more information but I won't get into that for now. Well, someone did something interesting with that recently, trying to get a list of applications, that I will mention. Actually, for some reason I can't locate my own bug on ADC to provide the number. One other bug was mentioned as being filed on open document issues off the current list thread, so Apple probably remains aware of the issue.
To receive other AppleEvents requires JNI. This is some Carbon to accomplish that. It works reasonably well for the simple test included here. My guess is that difficulties would be quickly and maybe frequently encountered as things get more involved. But that for another time maybe.