Home » Language IDEs » ServerTools (WTP) » JIT Concept Question
JIT Concept Question [message #536940] |
Mon, 31 May 2010 15:19 |
Reinhardt Christiansen Messages: 24 Registered: July 2009 |
Junior Member |
|
|
First, let me apologize in advance if I fail to use the correct terminology in this question; I simply don't know the exact correct usage of all the words I need.
One of the most useful things about developing Java in Eclipse is the feature that many coding errors are caught as I type them, rather than waiting until runtime. For example, if I am writing a Java method and type:
String myString = new String(123)
the 123 argument is underlined in red and I get a message advising me - in effect - that 123, an integer, is not a valid argument to use in instantiating a String since no String constructors accept an int parameter.
Am I correct in describing that behaviour as a feature of the JIT (Just In Time) compiler used in Eclipse? Or am I muddling the terminology?
Anyway, the reason I ask is that I would like to accomplish the same effect in one of my methods. I have a method called getRGBColor() which has a single input parameter that is a hex representation of a color. For example, FF0000 is the hex representation of the color Red.
At present, my method defines the method to be a String, just a good ol' garden variety String. After the method has been invoked, the first part of the method does a variety of validations, including verifying that the input parameter is exactly six characters long and that each character is a hex digit, i.e. the digits 0-9 or A-F.
The problem with this approach is that a bad value, like "ABCDEFG" which is too long or "X0X0X0" which has non-hex digits in it, is only detected at excecution time. I'd like to detect that kind of mistake in the same way as the JIT compiler sees that 123 is not a valid value in the constructor of a String.
Unfortunately, I'm not sure how to do that. I tried creating a brand new class called HexColor (extended directly from Object); it has the same error checking for incorrect length and non-hex digits in its constructor and throws IllegalArgumentException if those conditions aren't met. But I'm still just finding out about the problem at run time, this time when I try to instantiate the HexColor class. And that's fair: the input parameter of the HexColor class is still a String so its reasonable for the JIT compiler not to see that "X0X0X0" is not a valid HexColor as I'm typing the code; it's just verifying that I am typing a String and "X0X0X0" definitely qualifies.
So what DO I have to do to make the JIT compiler complain about the invalid values AS I TYPE the instantiation of the HexColor?
I don't understand the technique by which the JIT compiler accomplishes this magic but I'd like to imitate it with my own classes.
I am using Eclipse 3.5.2 on Windows.
|
|
|
Re: JIT Concept Question [message #536997 is a reply to message #536940] |
Mon, 31 May 2010 20:11 |
Konstantin Komissarchik Messages: 1077 Registered: July 2009 |
Senior Member |
|
|
> Am I correct in describing that behaviour as a feature of the JIT
> (Just In Time) compiler used in Eclipse?
No. JIT refers to what happens at runtime inside the JRE. What you are describing is called lexical validation.
> So what DO I have to do to make the JIT compiler complain about
> the invalid values AS I TYPE the instantiation of the HexColor?
Java language does not allow new types of literals to be defined. The Java language spec defines the literals that are allowed (integers, booleans, etc).
You have several options to consider...
Java supports integer literals expressed in hex form. You could change your method to take an int instead of a String. Then you would call it like this:
getRGBColor( 0xABCDEF )
This will catch certain type of typos, but the caller will still be able to specify a number that's too large.
Another alternative is to use Java enums. An enum with 256x256x256 items would be far too large, but an enum with 256 items is not too unreasonable. Your method would then take three parameters instead of one. Let's say you called your enum Hex, your call would look like this:
getRGBColor( Hex.xAB, Hex.xCD, Hex.xEF )
If you use static imports, you can even shorten it to this:
getRGBColor( xAB, xCD, xEF )
Note that you need to pick a prefix for your enum items as enum item names cannot start with a numeric digit. In the above example I used 'x', but you can you can use any other letter.
The enum approach is probably the tightest solution. The only case that you wouldn't be able to catch until runtime is null values being passed into your method.
Hope this helps and for future reference, this question should have gone to a generic Java language forum or maybe to the Eclipse JDT forum. JDT is the Eclipse project that implements Java tooling at Eclipse, including the Java editor.
- Konstantin
|
|
|
Re: JIT Concept Question [message #537007 is a reply to message #536997] |
Mon, 31 May 2010 20:46 |
Reinhardt Christiansen Messages: 73 Registered: March 2010 |
Member |
|
|
"Konstantin Komissarchik" <konstantin.komissarchik@oracle.com> wrote in
message news:hu1551$gs9$1@build.eclipse.org...
>> Am I correct in describing that behaviour as a feature of the JIT (Just
>> In Time) compiler used in Eclipse?
>
> No. JIT refers to what happens at runtime inside the JRE. What you are
> describing is called lexical validation.
>
Thank you for the clarification; I'll have to try to remember "lexical
validation" :-)
>> So what DO I have to do to make the JIT compiler complain about the
>> invalid values AS I TYPE the instantiation of the HexColor?
>
> Java language does not allow new types of literals to be defined. The Java
> language spec defines the literals that are allowed (integers, booleans,
> etc).
>
> You have several options to consider...
> Java supports integer literals expressed in hex form. You could change
> your method to take an int instead of a String. Then you would call it
> like this:
>
> getRGBColor( 0xABCDEF )
>
> This will catch certain type of typos, but the caller will still be able
> to specify a number that's too large.
>
> Another alternative is to use Java enums. An enum with 256x256x256 items
> would be far too large, but an enum with 256 items is not too
> unreasonable. Your method would then take three parameters instead of one.
> Let's say you called your enum Hex, your call would look like this:
>
> getRGBColor( Hex.xAB, Hex.xCD, Hex.xEF )
>
> If you use static imports, you can even shorten it to this:
>
> getRGBColor( xAB, xCD, xEF )
>
> Note that you need to pick a prefix for your enum items as enum item names
> cannot start with a numeric digit. In the above example I used 'x', but
> you can you can use any other letter.
>
> The enum approach is probably the tightest solution. The only case that
> you wouldn't be able to catch until runtime is null values being passed
> into your method.
>
Thank you for the suggestions on how to handle my requirements. Splitting
the parameters into three parts presents some inconvenience but it probably
would be the best solution overall....
> Hope this helps and for future reference, this question should have gone
> to a generic Java language forum or maybe to the Eclipse JDT forum. JDT is
> the Eclipse project that implements Java tooling at Eclipse, including the
> Java editor.
>
Thank you VERY much for your help with both my terminology issue and my main
question!
By the way, since I'm accessing these newsgroups via a newsreader most of
the time, is there any sort of guide or listing that explains what topics
are appropriate for each of the different newsgroups? For example, when I
list the newsgroups on this news server, I get a lengthy list of around 170
newsgroups. In many cases, the names of these groups is pretty cryptic, such
as eclipse.am2 or eclipse.dpsp.vpp. Not one of the newsgroups has a
description in the description column of my newsreader. Looking at those
names, I have no idea what aspect of Eclipse most of the newsgroups support
and I certainly don't know which one I should be posting on for a given
question. If there is some sort of guide or listing describing what each
newsgroup is for, that would be very helpful to me. (It would also reduce
the number of times the Eclipse developers would have to answer questions
that weren't really anything to do with their newsgroup.)
--
Rhino
|
|
| | |
Goto Forum:
Current Time: Fri Mar 29 13:25:53 GMT 2024
Powered by FUDForum. Page generated in 0.03336 seconds
|