Advancing Talkwards…
November 30th, 2008 — Links
November 29th, 2008 — Links
November 29th, 2008 — Programming
Looking around for an easy way to create applications with text GUIs for running over SSH terminals I came across CHARVA. CHARVA’s API copies Swings, it unfortunately is not built on top of Swing but is a copy of Swing. This forces implementers to import classes in the charva.awt and charvax.swing packages instead of traditional awt and swing classes. However, the result is rather nice, at least if you’re looking to run applications off a server on a simple Point-of-Sale or Point-of-Service (POS) terminal that may not even support graphics.
In my case I’m looking into making a simple app that I can use to keep track of passwords, both when I’m at home (regular swing) and when I’m away (at work or similar) and only able to access the application via SSH (CHARVA).
For more info, check out CHARVA here: http://www.pitman.co.za/projects/charva/index.html
November 28th, 2008 — Links
November 27th, 2008 — Links
November 26th, 2008 — Links
November 24th, 2008 — Links
November 23rd, 2008 — Links
November 22nd, 2008 — Computer Architecture, Programming
I’ve just had the rather unsettling experience of trying to deploy a new jar file (one I recompiled after some changes). This file were to be deployed on a rather old set up of Java 1.4.2. On first try everything broke with the classic “Unsupported major.minor version 50.0″.
So I went back to the drawing board. I installed java 1.4, and made sure my development Tomcat was running it. Then I did some research and found out how to make Eclipse compile 1.4 compliant code. I started and I got the same error still.
Once I figured out what was wrong I realized I was an idiot (Doh!). The error I’ve gotten wasn’t for any file part of the jar I was trying to deploy but for “index_jsp”. The thing is my Tomcat compiled my JSP:s into class files and never looked at them again until they were changed. I am sure there’s several ways to solve the problem, I just went and deleted the files in the “work”-directory (those pertaining to my Context).
The preferences window for setting source and target versions for Java compilation
Now over to how to make Eclipse code projects to a certain Java version.
There are two values you will want to keep track of. The source version and the target version. The source version tells what version your source code is written in. Whereas the target version tells what version of Java you want your class files in.
If for instance you have a project written in Java 1.4 source style, but you have to run it on a Java 5 you’d set the source version to 1.4 and the target to 1.5. You are now compiling Java 1.4 source into Java 5 class files. Unfortunately you’re not able to do the opposite, compile Java 5 source code into Java 1.4 class files. This is probably due to API incompatibilities, Java 5 has a larger API than Java 1.4.
Now, in Eclipse you have two settings in three places that controls the source and target versions of your compilations. Under Window->Preferences->Java->Compiler (Eclipse 3.4) you’re able to set the versions for the whole IDE.
When you create a new project you’re able to determine what version of Java (source and target you want) and right clicking on a project and choosing Properties->Java Compiler, you have the same dialog as before.
You set the target level in the select box “Compiler compliance level”, and optionally by unchecking the “Use default compliance settings” you’re able to change the target (“Generated .class files compatibility”) and source respectively.
If you experience other problems you may want to “clean” your project(s). Cleaning a project means all compiled files are removed and all source files are recompiled (something the IDE will do by itself when you change compilation versions, but if you want to be sure, you can do it manually). This is done by choosing Project->Clean. In the dialog you can chose to clean all projects or just those you select.
November 18th, 2008 — Links