OS X Leopard Java development annoyances
I've been developing using Java on the Mac for a few years now. Historically (pre-2006 as much as I remember) Apple was pretty slow on getting JDKs working (remember the PPC Blackdown project
), but as long as I've had by MacBookPro (Tiger+) developing has been pretty straightforward. There are some quirks about running various JDKs, but nothing too frustrating.
This changed with my Snow Leopard install. I upgraded to Snow Leopard a few weeks ago and didn't notice any problems until Friday when I tried doing a build to a Java 1.5 target.
My $JAVA_HOME = /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home
(which has worked fine for a few years)
But when I ran an ant task with build.compiler=javac1.5 (or target=1.5 in the <javac> task), I got classes compiled with java 1.6 (I could tell because when I ran "javap -verbose classname" I got major version=50).
Scratching my head for a bit I saw this message from ant "[javac] This version of java does not support the classic compiler; upgrading to modern" which made me think that something was wrong with my jdk.
When I ran "java -version" I got this output:
java version "1.6.0_15"
Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219)
Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02-90, mixed mode)
This kind of made sense because the java in my path was "/usr/bin/java" which symlinked to "/System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/java".
So I added $JAVA_HOME/bin to my path, like so: "export PATH=$JAVA_HOME/bin:$PATH". Now when I run "which java" I get "/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/java". But still when I run "java -version" I get the 1.6 output.
So after some googling, I finally come across this google groups article
describing how Snow Leopard only includes jdk1.6.
This was confusing as if I look in /System/Library/Frameworks/JavaVM.framework/Versions I see:
but when I look more closely, 1.5 and 1.5.0 both symlink to CurrentJDK. Now there is a download that lets you have jdk1.5
, but I found this very counter-intuitive that Apple would do this.
So I thought I would post an article with all the things I googled for an didn't see any matches to perhaps shave some minutes off the next java developer who is getting odd behavior with Snow Leopard. I am sure am glad I got this upgrade for free.
Update [2009.09.28 2251EDT]
: I discovered that if I tried to use some version name other than 1.5.0 I started getting this error:
"Shared archive: uninstalled generation
This was caused because even though I copied a 1.5 jdk to /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0-leopard, when I tried to run java it was loading classes from /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/classes.jar (which pointed to the CurrentJDK). This cased the error above.
I fixed this by symlinking 1.5.0 -> 1.5.0-leopard.
Labels: java, Mac, programming
I've noticed a growing trend with government projects claiming to be open source but then restricting access to source code and binaries. The US government is in an interesting space because technically all of the source code it produces is in the public domain. Of course, being FOIA
able and actually running software in a transparent, open, collaborative manner are two different things.
The fact that the US government is moving toward open source is a good thing, but a few sites are troubling me. For example, ForgeMil
, the DoD installation of sourceforge, but access "requires a valid DoD Common Access Card (CAC) or a PKI certificate issues by a DoD approved External Certificate Authority (ECA).
" This doesn't sound very open to me. Why place these restrictions on viewing "open source" source.
Also, there's CONNECT
, the "open source software gateway that connects an organization's Heath IT systems to the Nationwide Health Information Network." It is excellent, that the new administration (and the previous administration) are developing open standards for HeathIT but why should CONNECT force you to register and be approved before you can view their source code.
I think projects really need to review the Open Source Definition
before they jump on the open source bandwagon. There are many shining examples of open source projects within the US governemnt (caBIG
Open source in government projects allows collaboration across federal, state and local levels and also allows for immediate use by third world nations. But if it is open source in name only, not in practice this removes a lot of the value that transparency provides.
Update 2009.7.14: As of NHIN CONNECT's 2.1 release on July 7th, you can now download the source code without registering as a giant zip
. This is an improvement, but I still can't view the code repository without registering.
Labels: open source
Programmer Classifications by Quadrant
Lately I've been spending a bit of time trying to find and hire programmers (due to having to spend time removing programmers). Hiring programmers is never an easy task as there are really good programmers out there and prying them away from their existing jobs is hard work. How to hire has been written on extensively
But I've been thinking about personality types lately and which ones fit into projects and make good developers. Many years ago my brother, who is a WWII history guy, told me about Kurt von Hammerstein-Equord
's method for classifying his officers. I don't usually take the advice of nazi generals, but this method seems to have resonated with me and every time I tell someone else about it they seem to smile and draw some value.
Basically he had four defining characteristics: smart, stupid, lazy, industrious: "I divide my officers into four classes; the clever, the lazy, the industrious, and the stupid. Most often two of these qualities come together. The officers who are clever and industrious are fitted for the highest staff appointments. Those who are stupid and lazy make up around 90% of every army in the world, and they can be used for routine work. The man who is clever and lazy however is for the very highest command; he has the temperament and nerves to deal with all situations. But whoever is stupid and industrious is a menace and must be removed immediately!"
I think this applies to programmers pretty closely. Regard the quadrant below:
Programmers who are stupid and lazy are all over the place. In large projects there is room for these types as there are always jobs for them to do. More importantly, they aren't dangerous as they'll be wasting time reading 4chan instead of injecting bugs. These are the types that are the reason why project managers micromanage "What do you mean you spent 8 hours editing a label on the welcome screen?"
Next are the smart and industrious programmers. I thought these were the prized employees, the ones you really want. Smart and hard-working is a good thing right? Yes, that's right these are the guys and ladies who will identify the problem and work hard until it's complete. Boy scouts of the programming world.
Closely related are the smart and lazy programmers. These are the guys who really waste time and mess around, but are able to re-use someone else's API to do the work better than spending 20 hours writing it from scratch. The trick here though is to make that they aren't too lazy. I mean you want them coming into work and all.
Finally, you have the stupid and industrious programmers. These are dangerous. These will ruin your project and make you miss dates. "I spent all week-end re-writing the login module so it will only use digital certificates instead of userid and password." or "I wrote a wonder configurator to set the properties in the project. But the configurator only works on a JVM we don't use and there's no other way to configure the project." Stuff like this will make the smart/lazies, stupid/lazies and smart/industriouses work overtime to get back to zero.
Update 2009.06.04 2154EDT: As pointed out below by thecodist, Hammerstein-Equord, although in the Nazi army, was actually against the Nazi party, hated Hitler and spent most of his later life trying to stop the Nazis.
Labels: graphs, job theory, nazis, programming
Web service security through depth
I'm working on a project that uses the Globus Toolkit
as a secure service container. Globus can be more effort than necessary to run services, but it provides a solid security stack that uses digital certs and mutual authentication through SSL for authentication and encryption. Two-way SSL is rather secure and usually doesn't raise too many eyebrows.
However, one of the security analysts insisted this was insecure because you could use an HTTP reverse proxy between the user and the service. His reasoning was that you can't put the service container in the DMZ as it is too much of a security risk. Instead you put a web server (IIS or Apache) in the DMZ and have it proxy all traffic directly to the service container.
This is frustrating for several reasons:
1) increased cost and complexity - I generally like KISS
2) Limited increase in security. A configuration I usually use is to have the app server in the DMZ and the database inside the local network. The external firewall limits all traffic to 443 (or 80 if you have plain HTTP), protects against DoS, etc. etc. The vulnerability is that someone could compromise the app server if there is some exploit that works on 443 or 80. But with a reverse proxy, everything is forwarded on to the app server, so you can still exploit any 443/80 vulnerabilities even if the app server is within the local network. In fact, this is a greater risk because now someone has compromised the app server inside the local network, rather than a server in the DMZ.
3) Having an HTTP server proxy SSL sessions means that there are now 2 SSL sessions. One between the user and the HTTP server and then one between the HTTP server and the service. This is not only a performance problem, but now you have to delegate the user credentials. This means that the service can't use stuff like mutual-authentication with users because the proxy server is a man in the middle (although one under benevolent control).
So, what I've been doing is asking everyone I know who designs web services if this isn't stupid. So far I've had 4 architects from 4 different companies say that this configuration is unnecessary and that they don't do it.
In the meantime, we're going to use web services without an HTTP proxy server. It seems NIST
is on our side, so I'm hoping we'll be able to withstand the "We must triple encrypt stuff" crowd.
Labels: services, SOA
Open Source Secure Projects
A client I work with mentioned that for high security related projects, that developing them in an open source way will actually decrease the security provided by the project. The idea being that if anyone can see the architecture and code while it is being developed they can prepare to compromise the security. This made sense at the time and I nodded, but after chewing on it for a few weeks I think this is not the case at all.
There is certainly the argument that implementations are not open source. Of course that makes sense as no one will open up the server configs, passwords, private keys, etc. But the actual software that is used within an implementation gets more secure if developed as open source software.
So here's the short list off the top of my head of security related open source projects that are pretty widely used:
Of course others
have written on this subject and pretty much conclude that not only does OSS improve a project's security, not being OSS is quite a large vulnerability.
No Cost SOA
One of my clients came to me a few weeks ago with an interesting challenge: They want enterprise SOA, but have no money. This client is an extremely federated organization with multiple IT groups all receiving their own funding.
There's definitely a need for enterprise SOA (governance, infrastructure, practices) but no authority to back anything official.
So in light of these restrictions, we're thinking of a two-pronged approach to assisting SOA efforts:
- Try to convince IT authorities of need for formal SOA
- Collaboratively create SOA practice and standard recommendations that development groups can follow.
Step 1 involves building business cases, roadmap documents and other goodies that help convince those in power that it is worth spending money on SOA.
Step 2 involves documentation developed by the various IT groups building SOA around the organization. These documents include a service development lifecycle recommendation, service definition process recommendation, governance recommendtion and interoperability best practices recommendation. These documents are to be developed in a collaborative fashion (think wiki) and will be the self-selecting SOA community's guide for how to develop and use services.
Step 2 certainly has challenges (who will make people follow the recommendations- answer no one), but should move the organization closer to full SOA while cutting down on the chaos. I like step 2 because it gives an answer to the "no funds paralysis" that makes some architects think that SOA is hopeless.
I'll post updates as to how these approaches end up working.
Labels: SOA Governance EA
Free/Libre Open Source Societies
Chris Anderson published Free! Why $0.00 Is the Future of Business
last month and it got me thinking about some of the business/technical associations I associate with.
Over the years, I've been a member of a few groups: IEEE, IASA, AJUG, NYJSIG, etc etc. I'm also familiar with some of the major professional organizations: PMI, OMG, IETF, W3C, JCP. Some of these were free (IETF, AJUG, NYJSIG) while others required membership dues (IEEE, OMG, PMI). Some started out free and transitioned to membership dues (IASA).
In some of these organizations, the membership fees very clearly show what they go towards. For example, in the IEEE, you get a magazine, group rates on health insurance, etc. In others, I'm not sure what the dues go for: IASA.
Specifically, for architecture and programming groups, I think that the price for admission should be free and have tiers for additional membership if you want magazines, keychains, etc. This will serve to increase membership while keeping leadership in a purely voluntary capacity.
So this ends up being more closely aligned with open source "societies" like the apache foundation where anyone can be part of the community, join listservs, register for conferences, etc.