Search This Blog

Showing posts with label Netbeans. Show all posts
Showing posts with label Netbeans. Show all posts

Friday, October 1, 2010

javac -Xlint And Its Many Friends

-Xlint and its variations - so many to choose from! 1st -Xlint:unchecked

Or should I just use them all? Pick and choose? Just the one I'm interested in? What to do? What to do?  Like many I came across Xlint(*1) when hitting the following message in one of my Ant builds a while back:

[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.  

Huh....I thought to myself....there shouldnt be any errors with my last change. Well looking closer this is just a warning not Ant reporting on a compilation failure.OK. But why does it appear. There doesn't seem to be any location information reporting to me what causes it like a good 'ole stack trace does.  So like countless others I looked up how to use this -Xlint:unchecked thingy and stuck it into my Ant build and re-ran my ant script build.xml......and was promptly swamped by 100's of lines of warning messages (all pretty much saying the same thing) complaining about my absolute poor lack of etiquette in the use (or lack thereof) of generics throughout my (what I thought up until then was) pristine code.  Turns out it wasn't and I was seriously thinking of taking the pesky compile option out since its 'only a warning anyways' and hence thereby effectively getting rid of all that nasty mess and clutter in my build output. 

Now, okay....I didn't go down that path of just sweeping things back under the rug when they happen to fall out ... and furthermore these days things aren't quite that bad and when I write new code generics are used properly and by default as required throughout the code so this really is more of an issue when converting legacy code or upgrading from Java 1.4 to 5/6+ etc. When I do come across these issues I promptly modify the code to resolve them, thereby not only removing a pesky warning from my pristine build output, clearing up my Netbeans GUI of warnings and .... well .... also as a tiny little almost insignificant side note ..... making the code more robust and providing a higher-level of compile time type safety checking (which is really what generics are all about aren't they!!).

-Xlint, naked without its ':unchecked' param!

So now you know all about -Xlint:unchecked for type-checking issues related to generics. It is however possible to simply use just:

-Xlint

....without the :unchecked option. A little naked the poor tool feels now. This effectively says to the compiler use the lint tool (via the -X property) and just call it without any parameters. This has the effect of calling lint and using all of its checks rather than, like in our case above for :unchecked, using just the generic checks/warnings (by passing through the 'unchecked' parameter to the lint tool.

-Xlint and all of :unchecked's many, many friends!

So then, what checks are possible? When calling -Xlint what is it that we are actually doing (besides popping up a huuuuuge amount of warnings in most cases).  Well, calling -Xlint is effectively the same as passing in several parameters to the lint tool. What are these parameters....well Ive listed them below as to what it is that you can add to the -Xlint call as arguments to determine what checks the javac compiler should make when compiling the code and what warnings it should then report back on.

-Xlint:{all,cast,deprecation,divzero,empty,unchecked,fallthrough,path,serial,finally,overrides}


Thats a lot of options. Here is some info about them from the javac compiler options page:

-Xlint
Enable all recommended warnings. In this release, all available warnings are recommended.
-Xlint:none
Disable all warnings not mandated by the Java Language Specification.
-Xlint:-name
Disable warning name, where name is one of the warning names supported for -Xlint:name, below.
-Xlint:unchecked
Give more detail for unchecked conversion warnings that are mandated by the Java Language Specification.
-Xlint:path
Warn about nonexistent path (classpath, sourcepath, etc) directories.
-Xlint:serial
Warn about missing serialVersionUID definitions on serializable classes.
-Xlint:finally
Warn about finally clauses that cannot complete normally.
-Xlint:fallthrough
Check switch blocks for fall-through cases and provide a warning message for any that are found. Fall-through cases are cases in a switch block, other than the last case in the block, whose code does not include a break statement, allowing code execution to "fall through" from that case to the next case. For example, the code following the case 1 label in this switch block does not end with a break statement:
switch (x) {
case 1:
       System.out.println("1");
       //  No  break;  statement here.
case 2:
       System.out.println("2");
}
     
If the -Xlint:fallthrough flag were used when compiling this code, the compiler would emit a warning about "possible fall-through into case," along with the line number of the case in question.

-Xlint:{all,cast,deprecation,divzero,empty,unchecked,fallthrough,path,serial,finally,overrides}-cast,-deprecation,-divzero,-empty,-unchecked,-fallthrough,-path,-serial,-finally,-overrides,none}Enable or disable specific warnings


Links
http://download.oracle.com/javase/6/docs/technotes/tools/windows/javac.html#nonstandard
http://mark.koli.ch/2009/04/configuring-ant-to-use-javacs--xlintunchecked-option.html

*1 - Well not quite....you see thinking back....Ill admit that lint I remember vaguely from my C Programming days back at university (in the dawn of the age in the mists of time back somewhere during the time period range in 1995 - 1999/2000).

Tuesday, August 3, 2010

New Software Releases (Ubuntu-10.04, Firefox-4.0Beta2/3 & Netbeans6.9.1)!!!

Just a short/quick post to note that it seems to be a good time for software releases at the moment:
  • The latest version of Ubuntu, 10.04 (Lucid Lynx), is an LTS(Long Term Support) version, and was released on April 29, 2010. Woot!!! Woot!!! Woot!!! 
  • Firefox released the new Version 4 Beta a few weeks ago and now they've also released an update (i.e: Firefox 4.0 Beta 2....update....and Beta 3 came out on the 11th Aug), here's a link to the release notes and some interesting info: http://www.mozilla.com/en-US/firefox/4.0b2/releasenotes/
  • Netbeans has released the new 0.0.1 version release of Netbeans 6.9.1. The release notes are at: http://netbeans.org/community/news/show/1488.html.
Personally when it comes to large releases from companies I trust (FF, etc) I'm happy to use Beta versions on my PC's and Laptop. So I have a tendency to upgrade to the next version of 'most' bits of software (FF, Linux, JSE/JDK, JEE, etc). Regardless of new versions or even the use of Beta's but I tend to find that I'm OK and don't hit bad bugs from upgrading to early. That's good. So here's my opinions based on actual use of these tools and the new Betas/versions (well FF anyways....bit lazier so far on Ubuntu upgrades.... :-) )

Netbeans 6.9.1 Release

- Release Notes Overview: http://netbeans.org/community/news/show/1488.html

- Further Release Notes 6.9 Overview: http://netbeans.org/community/releases/69/

- List of Bug Fixes For The 6.9.1 Version: http://wiki.netbeans.org/NetBeans6.9PatchesInfo. This contains a list of the bugs fixed in the point release.

- And some EVEN better release notes for 6.9.1 August 4th 2010 Release: http://netbeans.org/community/releases/69/relnotes.html. These release notes kick ass in their detail. I reference these below for the list of some of the changes.


What's New in 6.9.1 - A more detailed list from above.

  • Availability of the latest IDE bundled with JavaFX SDK 1.3.1
  • Improvements to the JavaFX debugger
  • Important usability issues fixed in the JavaFX Composer and Editor
  • Critical bug fixes made to other modules since the 6.9 final release

The following updates to the 6.8 release included in version 6.9 also apply to 6.9.1:
  • JavaFX Composer to simplify and visualize JavaFX development
  • Support for Equinox and Felix OSGi frameworks in NetBeans Platform
  • Spring Framework 3.0 library support
  • Java CardTM 3 Connected
  • Rails 3.0 Beta support
  • PHP Zend Framework support
  • Support for JSR-299, Contexts and Dependency Injection (CDI)
  • Additional Enhancements are listed on the NetBeans IDE 6.9 New and Noteworthy page.
Note: The Java TM SE Development Kit (JDK) 5.0 is not supported on any platform for this release. You must have JDK 6.0 on your system to install and run NetBeans IDE 6.9.1.

Ubuntu Downloads and Free Install CD's


Firefox4.0-Beta2-Updates/New Functionality

- The following link shows the updates and the changes to the functionality from Beta 1 to 2. http://www.mozilla.com/en-US/firefox/beta/features/#feature-switch

- Furthermore I'm always interested in performance improvements. FF4Beta2 works on improving JavaScript, which given the state of the Web in our 'Web 2.0' fancy-shmancy world we live in is now an important feature to improve the speed of: http://blog.mozilla.com/dmandelin/2010/07/19/jagermonkey-update-getting-faster/. And so how does it get this extra performance. Well in a bunch of ways, bug fixes, perf., improvements, etc., etc., etc., but it also points out in dmandelin's blog that they used Ropes for improving the performance of Strings in JavaScript. The primary improvements going to occur when you do a lot of adds, removes from inside the middle of a string, and where in the normal case since a String is immutable you's need to make a new copy of inserts etc. Which gives you at least O(n) performance but Ropes convert a String to a tree structure so an insert in the middle of a string simply points a node to a new location of the new bit of the string we are adding. performance at O(1)!!! Beat that!!! Before you get to excited keep in mind you need to understand WHEN these are to be used or else you'll cost yourself performance but in the right case Speed improvements here we come. Something to keep in mind for the future if I ever need to perf., tune some code manipulating Strings heavily.



Check out http://en.wikipedia.org/wiki/Rope_%28computer_science%29 for an overview discussion of Strings vs. Ropes.

Wednesday, July 14, 2010

Netbeans 6.9 - Adding Basic Code Coverage

Netbeans 6.9 - Adding Basic Code Coverage

Description

Netbeans provides (and has done so for quite some time) good JUnit test functions allowing you to with the click of a button generate unit tests. Due to the ease of using and generating unit tests it has encouraged me to use them and so Ive been adding them into my recent code. However, not long after adopting Unit tests on a broad scale I find myself wanting to know how well I'm doing with the use of tests. I need to have some sort of code coverage information. There are at least two main contenders in this area (in the Open Source market of-course) and these are:

These are both aimed at slightly different areas but both provide code coverage info. However, before going ahead and implementing these within Netbeans (and especially Im interested in Cobertura) I decided to use Netbeans 6.9 inbuilt plugin for code coverage (which is based on EMMA anyway).


Implementation of Code Coverage

It was very simple and what follows are the steps to get it to work:
  1. Go to the plugin manager in Netbeans and download and install the Code Coverage tool.
  2. Run your tests across the whole project.
  3. Right click on the project, go to the new 'Coverage' link and 'Activate Coverage Collection' which will allow your code to be instrumented.
  4. Re-run your tests.
  5. Then go to the 'Coverage' and 'Show Project Coverage Statistics'. These will only work after the code has been instrumented and the tests re-run with the instrumentation in place.

This will then give you a report which will show the code coverage across your project for each class and also for the lines within the class and how many are covered by tests (i.e.: it'll look at the branch points like any coverage tool and check you have tests for each case). Furthermore it'll also highlight in your code, when you activate the coverage collection, highlighting which will paint covered code in light green and non-covered in light red so that at a glance you can see what is and isn't covered by tests in your code. Personally I switch this on, run the project stats, view them, see what classes are poorly covered, and then use the colour highlighting to see where I need more tests. However I don't leave it on all the time as I don't like my code painted red/green all the time.

Example Screenshot

The following is a screenshot of the code coverage project stats page along with how to activate it. The numbers indicate:

  1. The new 'coverage' link which appears as part of the plugin install.
  2. Shows where to start gathering stats (by getting the code to be instrumented) and where to trigger the project stats page to be displayed.
  3. The project stats page itself and some of the stats it displays showing class coverage, individual line level coverage etc.

Final Overview

In a future post Id like to look into implementing / using Cobertura in Netbeans and viewing the reports that Cobertura generates through Netbeans in some simple way, although this tool/plugin for viewing code coverage will be quite ample for the time being as it provides me with the ability to see code coverage across the project, the class level and even down to the line level through the coloured highlighting it provides.  This is enough to show me were I need to test more at this stage, with the future updates I think being more a fancy-shmancy kinda thing.

Monday, July 12, 2010

Adding JUnit / Hamcrest Functionality & Sources To Netbeans

Adding JUnit / Hamcrest Functionality & Sources To Netbeans

Im using JUnit4.5 in Netbeans for my unit testing (which in itself I wont go into detail in this blog post but JUnit and Unit Testing are things that are highly important and that I am all for the use of). Now while the latest JUnit version is up to 4.8.1/4.8.2 currently (20100712) Netbeans is not yet by default implemented to use this so for now Im using the version Netbeans comes with, 4.5, and It may be a future blogpost to upgrade Netbeans to the latest JUnit version (not tonight tho cos its 2:44am, Im still writing about Hamcrest and I got work tommorrow). Furthermore JUnit as of version 4.4 uses a library called Hamcrest internally. This is for performing a number of cool things whereby the assert* set of methods in JUnit are extended by the method assertThat():

http://www.junit.org/apidocs/org/junit/Assert.html#assertThat%28T,%20org.hamcrest.Matcher%29

using a parameter called a Matcher. Using the Hamcrest tutorial as a starting point Im going to go through and describe the Hamcrest library and its functionality. The tutorial I mention along with a number of other links I found interesting are at the end of this post....though you first have to read it before you get to them of course :-).

Now Matchers as provided by Hamcrest allow us to test in a more fluent, spoken word declarative sort of a way and the Hamcrest library comes with a number of useful matchers. Here are some of the most important ones (and its important to note that a lot of these only come with the latest version of hamcrest)

Core
  • anything - always matches, useful if you don't care what the object under test is
  • describedAs - decorator to adding custom failure description
  • evaluate - matches if a specified Boolean condition evaluates to true.
  • given - conditionally matches a value or Matcher
  • isA - matches a specific type
  • throws - matches if a function throws the given exception

Logical
  • allOf - matches if all matchers match, short circuits (like &&)
  • anyOf - matches if any matchers match, short circuits (like ||)
  • not - matches if the wrapped matcher doesn't match and vice versa

Object
  • equalTo - compares objects using ==
  • sameInstance, strictlyEqualTo - compare objects using ===
  • hasProperty - checks that a property exists and, optionally, that it matches the provided matcher
  • hasProperties - similar to hasProperty, but accepts a dictionary of properties and their associated matchers
  • hasPropertyChain - checks that a chain of properties exist and optionally that the value matches a provided value
  • instanceOf - test type
  • notNullValue, nullValue - test for null

Collections
  • array - test an array's elements against an array of matchers
  • arrayWithSize - match an array's size against a number
  • hasItem, hasItems - test a collection contains elements
  • everyItem - test that a matcher matches every item in an array
  • sortedBy - test an array's elements are sorted a single field
  • sortedByFields - test an array's elements are sorted by multiple fields

Number
  • closeTo - test that values are close to a given value
  • greaterThan, greaterThanOrEqualTo, lessThan, lessThanOrEqualTo - test ordering
  • between - test that a value is between two given values

Text
  • containsString, endsWith, startsWith - test string matching
  • re - text matches a regular expression

Date
  • dateAfter, dateAfterOrEqual, dateBefore, dateBeforeOrEqual - date comparisons
  • dateBetween - test that a date is within a given range
  • dateEqual - tests dates for equality


This allows for JUnit tests which are a lot more clearer in their intent. Ill give some examples of this below:

assertThat("chocolate chips", theBiscuit.getChocolateChipCount(), equalTo(10));
assertThat(someObject, notNullValue());



As you can see these are much clearer than the usual case of simply comparing to get a boolean result. In these cases it is much clearer as to the intent of the test even though it For example, the 'is()' matcher is a wrapper that doesn't add any extra behavior to the underlying matcher. The following assertions are all equivalent:

assertThat(theBiscuit, equalTo(myBiscuit));
assertThat(theBiscuit, is(equalTo(myBiscuit)));
assertThat(theBiscuit, is(myBiscuit));



The last form is allowed since is(T value) is overloaded to return is(equalTo(value)). These allow the test statements to 'read' like proper english.

Now Hamcrest has other features, including extensions to Matchers through your own customer matchers, and a bunch of other features (see links below). However, when I went to look at a JUnit test and I added some code to it to use these cool features, using the Netbeans functionality to go to source didnt work as there is no source attached to the code. What gives? Well I did the following.

  1. Download hamcrest-all.jar and junit4.8.2.jar
  2. Then first of all i customised my junit4.5 lirary. I went to sources and added from junit4.8.2 the directory temp.hamcrest.source to the sources for junit4.5
  3. Now while this is fine for the Unit Matches and using Hamcrest in JUnit I was curious about ALL the Hamcrest code and so I also then went and created a new Library called Hamcrest1.1 and added the download jar as the path, source and javadoc as this contains all 3 (the .class files are ther alongside the .java) and then added this to my project which now allows me to play around with Hamcrest.
So with these changes I can now not only use Hamcrest with JUnit, but I can now go and browse to the source as well which I always want to be able to do as I love to be able to go digging around in the implementation and see others code and how tools I love work.

Links

Project -http://code.google.com/p/hamcrest/wiki/Tutorial
JUnit Release Notes - http://old.nabble.com/JUnit-4.4-released-td11677562.html
Tutorial on Hamcrest - http://github.com/drewbourne/hamcrest-as3