wood burning stoves 2.0*
The moose likes Java in General and the fly likes Need Help with java.lang.NullPointerException Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Need Help with java.lang.NullPointerException" Watch "Need Help with java.lang.NullPointerException" New topic
Author

Need Help with java.lang.NullPointerException

Lou Pellegrini
Ranch Hand

Joined: Nov 11, 2003
Posts: 142
    
    1
Hi All,

I've been trying to run this down for days without success.


Exception in thread "main" java.lang.NullPointerException
at MeasurementTest.main(MeasurementTest.java:24)

I posted all the code posted below.

The problem is somewhere in the puts and gets of
MeasurementDomParser line 133 - measurements.putLabel(labelValue, namesVector);
and
MeasurementTest line 22 - Vector<String> labels = measurements.getLabels(type);

where both methods are accessing Measurements labelsMap.

It to me looks like MeasurementDomParser line 133 is putting a good Vector, but MeasurementTest line 22 is getting a null Vector.

Thank you for taking the time to help.

Lou


MKSFactors1.xml



MeasurementTest.java


Measurement.java


Measurements.java


MeasurementDomParser.java


(Edited by jlacar to break up long lines)
Richard Tookey
Ranch Hand

Joined: Aug 27, 2012
Posts: 971
    
  10

The key used in a Map should be immutable but your line (mangled by the site code formatter)

seems to be using a Map as a key!

This all seems way over complicated for a units conversion program!
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4420
    
    5

Richard Tookey wrote:The key used in a Map should be immutable but your line (mangled by the site code formatter) ... seems to be using a Map as a key!

I don't think so: That just creates a new Map that is backed by the given HashMap
but with thread-safe methods. The key of the resulting map is still a String so he's
fine in that respect.

I agree that the program seems a bit too complicated. I didn't try to find the bug but here's what I would advise:

  • DON'T use the Vector class - IMO, you don't need it. Use another List implementation instead.
  • DON'T unmarshal XML into Java object(s) manually. Use a framework to do the heavy lifting for you instead.

  • For XML marshalling/unmarshalling, there's JAXB. I like Simple because it's, well, simple.

    You seem a bit overly concerned with thread-safety. While it's certainly good to think about thread-safety, you want
    to avoid gold-plating as well. Is there really a need to make that code thread safe?

    You also seem to be optimizing prematurely. Why do you feel you need to call trimToSize() on the Vector?

    Another note: You defined a private no-argument constructor for Measurement and gave a comment to explain
    why it's there. It seems to me that you've misunderstood how constructors work. Constructors in Java are not inherited.
    Since you have provided a constructor that takes parameters, the default no-argument constructor will not be provided
    by the compiler. You can safely remove your private no-args constructor.
    Junilu Lacar
    Bartender

    Joined: Feb 26, 2001
    Posts: 4420
        
        5

    Another comment about complexity and the OO-ness of your code: you only need one conversion factor. fromMks is simply the reciprocal of the toMks value so half of what you specify in your XML file is really redundant information. Note also that your Measurement and Measurements classes essentially have only getter methods. This raises the question of how useful these classes are in representing some kind of interesting behavior which is what an Object really should be about, not just about data.
    Richard Tookey
    Ranch Hand

    Joined: Aug 27, 2012
    Posts: 971
        
      10

    Junilu Lacar wrote:you only need one conversion factor. fromMks is simply the reciprocal of the toMks value.


    Not for all conversions! For example temperature. The parameters that specify the transformation of one unit to another can be used for both directions so the XML file does only needs one entry for each unit.
    Junilu Lacar
    Bartender

    Joined: Feb 26, 2001
    Posts: 4420
        
        5

    Richard Tookey wrote:Not for all conversions! For example temperature.

    I think the problem was limited to converting to/from MKS (Meter-Kilogram-Second) to/from FPS (Foot-Pound-Second). You're right though, temperature conversions are not as straightforward.
    Lou Pellegrini
    Ranch Hand

    Joined: Nov 11, 2003
    Posts: 142
        
        1
    Hi All,

    I still need help finding the NullPointerException. I tried everything I could think of.

    I appreciate all the side comments and I will get to those, but please I would like help finding the cause of the exception.

    Thanks,

    LOu
    Lou Pellegrini
    Ranch Hand

    Joined: Nov 11, 2003
    Posts: 142
        
        1
    Success! I found the answer on stackoverflow.

    I was trying to iterate through java.util.HashMap with java.util.Set.

    Iteration with java.util.Map.Entry was needed.

    Thank you to all who responded! I'll assess those other suggestions now.

    Lou
    Steve Luke
    Bartender

    Joined: Jan 28, 2003
    Posts: 3974
        
      17

    Hey Lou, I am glad you fixed the problem, and that link you posted has good advice. But the reason you were getting the null pointer wasn't because you were iterating the wrong way, it was because you were getting the values from the wrong Map. Take a look at the getLabels(String) method. Can you see why you won't get anything back when you call it with a type?


    Steve
    Junilu Lacar
    Bartender

    Joined: Feb 26, 2001
    Posts: 4420
        
        5

    It also seems odd that the getNames method is accessing the labelsMap rather than the namesMap.
    Steve Luke
    Bartender

    Joined: Jan 28, 2003
    Posts: 3974
        
      17

    Junilu Lacar wrote:It also seems odd that the getNames method is accessing the labelsMap rather than the namesMap.

    No, that is correct. The typesMap maps a type to labels in that type. The labelsMap maps a label to names in that label. And the namesMap maps a name to the Measurement it represents.

    Though maybe more descriptive names would be better: getLabelsForType(), getNamesForLabel(), getMeasurementForName() or something like that. I would also consider having different datatypes for Type, Label, Name as well, to help avoid confusion (would have caused a compile-time exception in this case, rather than runtime null pointer).
    Junilu Lacar
    Bartender

    Joined: Feb 26, 2001
    Posts: 4420
        
        5



    Both methods take a String and both methods use that String as the key to retrieve a value from the same Map. I did not take the time to read the code in detail and understand the semantic difference between type and label but accessing the same map for different purposes seems like a very poor design choice.
    Steve Luke
    Bartender

    Joined: Jan 28, 2003
    Posts: 3974
        
      17

    Right, and that is the problem I described in my first post. The getLabels() method uses the wrong map. It should be accessing typesMap. It looks like he copied/pasted from the getNames() method, changed the name of the method and parameter but forgot to change the name of the map.

    That is also why I suggested using a different type for Type, Name, and Label. If his maps were Map<Type, List<Label>> typesMap, Map<Label,List<Name>>labelsMap, and Map<Name, Measurement> namesMap then he would get a compile time error when he does:

    And would immediately know what and where the real problem is, rather than seeing a Null Pointer at runtime and at some downstream point.
    Junilu Lacar
    Bartender

    Joined: Feb 26, 2001
    Posts: 4420
        
        5

    I would suggest a different nomenclature. If I had a map with lists of Parts keyed on Assembly name, I would name that map "partsByAssembly". By the same token, lists of labels keyed by type would be "labelsByType". It would also follow that I would have "measurementsByName" and "namesByLabel" for the other mappings. Having "Map" in the names is redundant and you should be able to figure that out from the usage and declaration.
    Junilu Lacar
    Bartender

    Joined: Feb 26, 2001
    Posts: 4420
        
        5

    After doing that, I'd probably look at the code and still think that it smells. Further refactoring would probably push the Map<keyType, List> data structure deeper into an object or get rid of it altogether. I think my ideal design would be to have List<Type>, List<Label>, List<Name> as Steve suggested but each element type would have a method that returns a list of its subelements. That is, the higher level methods getLablesForType(), getNamesForLabel() and getMeasurementForName() would get pushed down into the specific objects so that you have Type.getLabels(), Label.getNames(), and Name.getMeasurements().
    Lou Pellegrini
    Ranch Hand

    Joined: Nov 11, 2003
    Posts: 142
        
        1
    Hi Junilu,

    I think my ideal design would be to have List<Type>, List<Label>, List<Name> as Steve suggested but each element type would have a method that returns a list of its subelements. That is, the higher level methods getLablesForType(), getNamesForLabel() and getMeasurementForName() would get pushed down into the specific objects so that you have Type.getLabels(), Label.getNames(), and Name.getMeasurements().


    I think I like your idea, but it's not completely clear to me.

    Can you provide a small code example of that?

    Thanks,

    Lou
    Junilu Lacar
    Bartender

    Joined: Feb 26, 2001
    Posts: 4420
        
        5

    I would go back to my recommendation to avoid manually marshalling and unmarshalling objects/XML. Go with a framework like Simple instead. You'll find numerous examples on that website illustrating how to structure your objects and how to use the framework to marshall and unmarshall. Good luck.
    Lou Pellegrini
    Ranch Hand

    Joined: Nov 11, 2003
    Posts: 142
        
        1
    Hi Junilu,

    I decided to follow your suggestion and try Simple, but I'm having a problem I hope you will help me with.

    At run time I'm getting
    org.simpleframework.xml.core.PersistenceException: Element 'measurement' is already used with @org.simpleframework.xml.Element(name=, data=false, type=void, required=true) on field 'measurement' private java.lang.String TypeList.measurement at line 16


    However when I remove element 'measurement' from TypeList I get
    org.simpleframework.xml.core.ElementException: Element 'measurement' does not have a match in class TypeList at line 12


    I suspect that the problem is related to reusing the measurement tag, but I haven't found a way to correct it.

    Please give it a look and give me your suggestions.

    My code is posted below.

    Thanks,

    Lou

    MKSFactors1.xml


    MeasurementTest.java


    ConversionList.java


    LabelList.java


    MeasurementList.java


    Measurement.java
    Junilu Lacar
    Bartender

    Joined: Feb 26, 2001
    Posts: 4420
        
        5

    Lou,

    Study the examples more closely. When using Simple, it's best to follow the default convention for object names that it expects. This helps keep the object-to-element mapping simple and straightforward.


    If you want to keep all these classes in one source file, say in Conversions.java for example, then you'd have to declare the other classes as private static member classes, as shown in many of the examples in the tutorial.

    Are you able to modify your XML schema? Because if you are, I suggest you change the structure and element names to something like this:

    As I mentioned before, all of the fromMks conversion factors you have are redundant and can be eliminated. As you can see, choosing better semantic names can really help clarify your understanding of the organization and structure of your design.

    Lou Pellegrini
    Ranch Hand

    Joined: Nov 11, 2003
    Posts: 142
        
        1
    Junilu,

    Another comment about complexity and the OO-ness of your code: you only need one conversion factor. fromMks is simply the reciprocal of the toMks value so half of what you specify in your XML file is really redundant information


    Both fromMks and toMks are needed for some conversions, for example temperature Fahrenheit to Celsius.

    ºC = (ºF - 32) / 1.8000

    So not all are reciprocal.

    But your right that some are reciprocal such as Weight and Distance.

    Maybe though I can make a second XML file for those that are not reciprocal.

    Thanks,

    Lou


    Richard Tookey
    Ranch Hand

    Joined: Aug 27, 2012
    Posts: 971
        
      10

    Lou Pellegrini wrote:
    Both fromMks and toMks are needed for some conversions, for example temperature Fahrenheit to Celsius.



    Agreed and everyone (well most people anyway) accept this but you don't need both sets of parameters in the XML file since one can be derived from the other. For example, using your example

    ºC = (ºF - 32) / 1.8000

    and

    ºF = ºC * 1.8 + 32

    so one set of parameters can be used for both directions.
    Lou Pellegrini
    Ranch Hand

    Joined: Nov 11, 2003
    Posts: 142
        
        1
    Hi Junilu,

    so one set of parameters can be used for both directions.


    Now I see what you mean, it's just a two-step process in either direction.

    Thanks,

    Lou
    Junilu Lacar
    Bartender

    Joined: Feb 26, 2001
    Posts: 4420
        
        5

    Not to belabor my point but you folks don't seem to see that there's a fundamental difference between a conversion factor and a conversion formula.

    When you use a conversion factor, you multiply the source units (the system of measure that's NOT MKS) by the factor to get the equivalent value in the target system (MKS). To do a conversion from MKS back to the other system, you divide the MKS value by the same factor or multiply it by the factor's reciprocal.

    When converting from one temperature scale to another, you use a conversion formula, which is not as straightforward as using a conversion factor. Note that with the conversion formula, there is more than one term and constant involved in the calculation. My code/design sense tells me that mixing the two classes of conversion in one XML file will lead to unnecessary complexity.

    If anything, it seems to me that to deal with the complexity, you'd have to introduce a Factory such that you can give it a category name and it will give back an appropriate Converter (an interface). The returned Converter implementations would be the likes of FactorConverter, FormulaConverter, or WhateverElseConverter. The Converter interface and the Factory provide the necessary abstraction to decouple your implementation from the intent so that clients will have a uniform API with which to perform appropriate conversions between different systems of measure. Again, trying to mix two or more classes of conversions in one XML file is going to start emitting a code/design smell fairly quickly, IMO, unless of course you take steps to refactor your current XML schema so you can keep a clear separation between different classes of converters. There are tradeoffs between convenience (perhaps only initially) and complexity that you should consider when trying these ideas out.

    All this of course assumes that you actually DO need to make temperature scale conversions. I did not want to make that assumption before because the XML you gave didn't include it. The only class of conversions you have in there are factor conversions hence my assertion that the fromMks factor is redundant. My approach would be to solve the simpler problem first with a clean design and clean code, then if there really is a need to have temperature (formula) conversions, refactor from there so that it can be added in cleanly.

    My initial cut for defining the Converter interface might be something like this:


    From this starting point, I would test-drive the design and code. Google for "Martin Fowler's Money Class" to see further insights into the type of design thinking that you might want to follow for this exercise.
    Junilu Lacar
    Bartender

    Joined: Feb 26, 2001
    Posts: 4420
        
        5

    Maybe you could show your proposed XML for defining the factors you'd use for converting Fahrenheit to Celcius and vice versa. What about the XML for converting Kelvin, Rankine, and all the other temperature scales listed here: http://en.wikipedia.org/wiki/Comparison_of_temperature_scales#Comparison_of_temperature_scales? Then, when you have that, show some sample code that would use the objects you deserialize from that XML. Would that code have a lot of conditional statements and checks for specific classes of conversions? If it does, then it's smelly, brittle code. That would be my point. Hope this helps clarify my ramblings a little.
    Lou Pellegrini
    Ranch Hand

    Joined: Nov 11, 2003
    Posts: 142
        
        1
    Hi Junilu,

    All you direction is greatly appreciated!

    When using Simple, it's best to follow the default convention for object names that it expects.


    Agreed. I saw that right off.

    Are you able to modify your XML schema?


    Yes.

    Would that code have a lot of conditional statements and checks for specific classes of conversions? If it does, then it's smelly, brittle code.


    How would you accomplish this without a the conditional checks and statements?

    My generic vision uses


    The complexity of this as my first Simple project has been getting in my way. I'm going to make a little package to play with using XML with one child under the root and add children and grandchildren from there building on my understanding.

    Afterwards I'll consider making the XML changes you suggested.

    Thanks,

    Lou

    Junilu Lacar
    Bartender

    Joined: Feb 26, 2001
    Posts: 4420
        
        5

    No problem. I enjoy design discussions like this; it exercises the gray matter and helps develop the ability to see patterns being suggested by the code.

    For example, the getConverter(String type) method you wrote is the start of a Factory Method. Rather than returning null however, I would throw some kind of RuntimeException to signal that the value of the type parameter passed in is not supported at this time. It would be a runtime error because I should not expect an invalid value for type to be passed during normal program execution, which means there is some kind of program configuration error or a programming bug that needs to be addressed.

    Let me know if there's anything I can do to help you with Simple. After you go through some of the examples and write your own implementation to experiment with it a little bit, the going gets a lot quicker; Simple is fairly easy to learn with some experimentation.

    Good luck.
    Lou Pellegrini
    Ranch Hand

    Joined: Nov 11, 2003
    Posts: 142
        
        1
    Hi Junilu,

    My little package to play with xml is now working. I now understand the reasons your restructure of my conversion xml and will use it.

    First a question.

    Would that code have a lot of conditional statements and checks for specific classes of conversions? If it does, then it's smelly, brittle code.


    How would you accomplish this without a the conditional statements and checks?

    The only way I can think of doing it would be using Class.forName(String className) and putting the className in the xml.

    My generic vision uses without returning null (which I wouldn't do anyway) and without Class.forName
    Junilu Lacar
    Bartender

    Joined: Feb 26, 2001
    Posts: 4420
        
        5

    I should have qualified that to make it clearer. You should not have client code that has intimate knowledge about the different types of Converter implementations. If you do, that will be smelly. And by "client code", I mean any code that would use a Converter.

    I use Spring and dependency injection to achieve loosely coupled designs. This might be overkill for your purposes though. If your requirements are simple enough, the simple factory method you have should be fine but when you start adding more conversion types, you start pushing up against the Open-Closed Principle. That's when I would start thinking about refactoring from the simple if-then statements to something like a Map lookup with conversion type names as the keys and concrete factory implementations as the values. Then you'd have to add some kind of "registration" capability so that you can easily add new concrete factory implementations, again without changing code. This goes back to preferring configuration changes over code changes to modify the behavior of a program.

    Lou Pellegrini
    Ranch Hand

    Joined: Nov 11, 2003
    Posts: 142
        
        1
    Hi Junilu,

    If you don't mind it's a good time for a code review before I move on. I incorporated most of your suggestions, and I committed one small sin - my tag names are singular but my list names are plural, so I used the @ElementList(name="singular name") so I could follow my personal convention of using plural names for collections.



    My code posted below.

    Interesting article I found on stackoverflow about using Iterators, especially the answer from sfussenegger where he tested run times.

    Thanks,

    Lou

    MKSFactors1.xml


    MeasurementTest.java


    Conversions.java


    Category.java


    Scheme.java


    Measurement.java
    Winston Gutkowski
    Bartender

    Joined: Mar 17, 2011
    Posts: 7081
        
      16

    Lou Pellegrini wrote:Both fromMks and toMks are needed for some conversions, for example temperature Fahrenheit to Celsius.
    ºC = (ºF - 32) / 1.8000
    So not all are reciprocal.

    Actually, that's only so because you're using that nasty conversion. There's another one, which I've never understood why it isn't taught more in schools (and certainly in Computer Science classes):
    F/C = ((C/F + 40) * K) - 40
    where K is 5/9 when converting from Centigrade to Fahrenheit, or 9/5 (ie, the reciprocal) when converting the other way.

    My dad taught it to me as a kid, and the reason I remember it is you never have to worry about which way you're converting; you only need to remember K.

    Winston

    Isn't it funny how there's always time and money enough to do it WRONG?
    Artlicles by Winston can be found here
    Winston Gutkowski
    Bartender

    Joined: Mar 17, 2011
    Posts: 7081
        
      16

    Lou Pellegrini wrote:If you don't mind it's a good time for a code review before I move on.

    Well, just from what I see, I think you could save yourself a lot of grief by having a "base" unit for each Scheme, and then a single conversion between Scheme base units.

    For example, if your base for Avoirdupois is an 'ounce' and your base unit for metric weight is a 'gram', you only have one "conversion" to worry about: 1 ounce ≈ 28.35 grams (obviously, this should be stored as accurately as possible).

    Since most schemes are going to be made up of units that are multiples (or divisions) of a base unit, the conversion becomes:
    1. Convert to base unit.
    2. Convert to "other Scheme's base unit".
    3. Convert to target unit.

    The only thing is that you need to choose your "base" unit fairly carefully.

    HIH

    Winston
    Winston Gutkowski
    Bartender

    Joined: Mar 17, 2011
    Posts: 7081
        
      16

    Lou Pellegrini wrote:I posted all the code posted below.

    Lou,

    Please DontWriteLongLines. It makes your thread very hard to read.

    I tried to break yours up, and then found that your first post contains tons of them, so I've given up; but for future reference, please remember:
    80 characters max.
    (the SSCCE page actually recommends 62)
    And that includes string literals AND comments.

    My suggestion: Use the 'Edit' key to break up that horrendous first post of yours. I certainly find it very difficult to follow; and unfortunately it affects the whole thread. You might also want to think about using slightly less ferocious indenting.

    Thanks.

    Winston
    Junilu Lacar
    Bartender

    Joined: Feb 26, 2001
    Posts: 4420
        
        5

    Lou, here are a few things I would change:

    1. Replace Vector with an unsynchronized collection like ArrayList -- I see no reason to synchronize these classes since you're only going to read in the XML once and no modifications will be made once the objects have been created.
    2. Don't worry about optimizing memory -- I don't think calling trimToSize() really buys you much.
    3. Use the enhanced for-each loop instead of while loops

    These are just my own preferences though.
    Lou Pellegrini
    Ranch Hand

    Joined: Nov 11, 2003
    Posts: 142
        
        1
    Hi Junilu,


    1. Replace Vector with an unsynchronized collection like ArrayList -- I see no reason to synchronize these classes since you're only going to read in the XML once and no modifications will be made once the objects have been created.
    2. Don't worry about optimizing memory -- I don't think calling trimToSize() really buys you much.
    3. Use the enhanced for-each loop instead of while loops


    1. Ok, good thinking.
    2. Ok.
    3. According to the stackoverflow article I posted for-each is about "60,000 times slower".

    Based on that I think it's best to use an Iterator.

    Thanks,

    Lou
    Lou Pellegrini
    Ranch Hand

    Joined: Nov 11, 2003
    Posts: 142
        
        1
    Hi Winston,

    Please DontWriteLongLines. It makes your thread very hard to read.

    Thanks for the link. I understand the reasoning.

    Actually, that's only so because you're using that nasty conversion.

    Thank you for the formula! Now I can reuse the logic I have for Weights and Mass.

    Well, just from what I see, I think you could save yourself a lot of grief by having a "base" unit for each Scheme, and then a single conversion between Scheme base units.

    That's what the measurement mks attribute about.

    Notice <measurement name="Gram" mks="1"/> Then the conversion logic works with Grams the a base.

    But I think you might be right. adding for example <scheme name="Metric" base="1"> would avoid hard coding the base and Grams will still convert correctly, and the base would be documented in the xml.

    Thank you for your input!

    Lou
    Junilu Lacar
    Bartender

    Joined: Feb 26, 2001
    Posts: 4420
        
        5

    I'm not sure how you got that for-each is 60000 slower from that article; it was comparing use of iterator vs get() method to process a collection, as well as comparing different types of collections based on internal implementation. An enhanced for-each loop will be optimized to use an iterator when it can. You seem to be overly-obsessed with manually optimizing your code. Programmers suck at optimizing code based on gut feel and intuition. Use a profiler if you're really concerned with performance but strive for clarity of code before anything else.
    Lou Pellegrini
    Ranch Hand

    Joined: Nov 11, 2003
    Posts: 142
        
        1
    Hi Junilu,


    I'm not sure how you got that for-each is 60000 slower from that article

    Does this article explain what you mean by for-each loop?
    That's new to me.

    You seem to be overly-obsessed with manually optimizing your code.

    I'll agree to that. I have been developing since a long time before Java, started with COBOL, and optimization was a priority.

    Thanks,

    Lou

    Junilu Lacar
    Bartender

    Joined: Feb 26, 2001
    Posts: 4420
        
        5

    Lou Pellegrini wrote:
    Does this article explain what you mean by for-each loop?
    That's new to me.

    Yes, this is the enhanced for-loop, introduced as a simpler way to iterate over a collection or array. The compiler should be able to generate efficient byte code thus relieving the programmer of having to worry too much about optimizing performance.

    Your job as a programmer is to come up with clean designs and write clean code. Leave the work of generating optimized code to Java; in most cases it does a far better job than you could ever hope to do with gut feel and intuition.
    Lou Pellegrini
    Ranch Hand

    Joined: Nov 11, 2003
    Posts: 142
        
        1
    Richard, Junilu and Winston,

    Here's what I learned.

    Richard's and Junilu's posts about reciprocals are more about units than the mathematical definition of reciprocals, which produced correct results in one direction only.

    (Value / fromMks) = units, then (units * toMks) yields the correct results in both directions.

    Winston's temperature formula will work with units too.

    The only thing is that you need to choose your "base" unit fairly carefully.


    Yes Winston, and you're temperature formula proves that. With that information I have decided that the base units should be the smallest unit available for a measurement. Except I'm not going to get into "atomic mass unit (amu)" because my head hurts enough already, and that would yield some rather massive results for the larger units.

    I earned my first cow working on this project!

    Thanks to all who replied!

    Lou



    Richard Tookey
    Ranch Hand

    Joined: Aug 27, 2012
    Posts: 971
        
      10

    Lou Pellegrini wrote:
    I have decided that the base units should be the smallest unit available for a measurement.


    I can't see the logic in that ! The choice of which unit to use for the base unit is fairly arbitrary but I would have expected that the base unit should be the most normal unit used. For the standard physical units of length, mass, time etc I would expect this to be MKS. You don't really want to be working in microns or angstroms for length do you?

    Of course your code is independent of the base units so you should be able to change your mind later.



     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Need Help with java.lang.NullPointerException
     
    Similar Threads
    Trick question
    Exception Handling
    get the sysmonth and year in drop down box.
    Dom Parser picking up only first tag
    Is it possible to put a button inside autocomplete in jquery ui plugin?