Apparently, there is a bug in the Sun JDK 1.4.2 or lower implementation of java.lang.String. This bug has been identified as 4310930, 4546734, 4637640, 4724129 in Sun's Bug Database. I've come across this bug while reading Charles Miller's post, when he was having trouble with the OutOfMemoryError in his JDBC code.
Please download this source code to see what I'm talking about. Try to run the source code, and continue until you reach the OutOfMemoryError state, as seen in my own trial here. Then, change the source code to the working alternatives, and test them out (see my result here).
This bug has been fixed in JDK 5.0 release, but I believe most of us are still working with Sun JDK 1.4.2 or lower. So I guess this is a problem that we must be very careful with.
Thursday, April 28, 2005
Thursday, April 14, 2005
Petals around the Rose Puzzle
A friend of mine send me a link to the Petals around the Rose Puzzle. It's essentially a simulation of rolling 5 dice at the same time, then guess what is the number of Petals around the Rose. It's quite fun actually to guess them. I've had 16 tries (approx. 15 mins) before finding my solution to the problem. The solution has been proven within the next 30 successfull tries.
Try them out for yourself, and let me know how you did it.
Here's my solution in Spanish: (use Google Translator to translate them into English)
No haga caso de todo, a excepción de 5 y de 3. Cada 5 cuentas para 4 pétalos. Cada 3 cuentas para 2 pétalos. Resuma el número de pétalos.
Another friend of mine come up with a smarter (more visual) solution, also within 10-15 minutes time. Here's his solution in Spanish:
La rosa es el punto en el centro de el corto en cubos. Solamente 1/3/5 tiene ese punto. Por lo tanto, 2/4/6 no es se levantó. El pétalo es los otros puntos que rodean color de rosa. Así, solamente 3/5 rosa tiene 2/4 de los pétalos.
Let me know your solution.. :D
It's just a fun way to start the day.. :D
Try them out for yourself, and let me know how you did it.
Here's my solution in Spanish: (use Google Translator to translate them into English)
No haga caso de todo, a excepción de 5 y de 3. Cada 5 cuentas para 4 pétalos. Cada 3 cuentas para 2 pétalos. Resuma el número de pétalos.
Another friend of mine come up with a smarter (more visual) solution, also within 10-15 minutes time. Here's his solution in Spanish:
La rosa es el punto en el centro de el corto en cubos. Solamente 1/3/5 tiene ese punto. Por lo tanto, 2/4/6 no es se levantó. El pétalo es los otros puntos que rodean color de rosa. Así, solamente 3/5 rosa tiene 2/4 de los pétalos.
Let me know your solution.. :D
It's just a fun way to start the day.. :D
Monday, April 11, 2005
Immutable classes
Here's my opinion on immutable classes, answering Bayu's comment which asks for an explanation on when and how to implement them.
Making a Java class immutable usually make the overall design of a system slightly better compared to making all Java classes mutable. Whenever possible, making such class immutable will make it easier to be implemented and maintained.
First, don't provide any mutator methods, i.e. methods which are able to modify the internal of the class. If you have to provide a mutator method, make sure that it's thread-safe.
Then, make all fields private. If you need to expose a constant value through public static final field, make sure that the internal of the constant value cannot be modified. Otherwise, you'll only open a hidden vulnerability. For example, an array or list constant value's elements may be modified without changing the reference of the array or list itself.
Sometimes, making an immutable class is a pleasure by itself. It's almost very easy to test, sometimes it needs no testing because it just cannot possibly break. Then, it's nice also to create constant values which are instances of this immutable class, just like constant values for Boolean.TRUE, Boolean.FALSE, etc.
There are many great examples of immutable class usages. Even the immutability itself can be raised to multiple levels, providing event tighter access on each level, e.g. no methods can be overridden, etc. I suggest you to read Effective Java book by Joshua Bloch. The book discusses immutability in great length.
I hope this short introduction to immutability may lure many future design to favor it whenever possible.. :D
Making a Java class immutable usually make the overall design of a system slightly better compared to making all Java classes mutable. Whenever possible, making such class immutable will make it easier to be implemented and maintained.
First, don't provide any mutator methods, i.e. methods which are able to modify the internal of the class. If you have to provide a mutator method, make sure that it's thread-safe.
Then, make all fields private. If you need to expose a constant value through public static final field, make sure that the internal of the constant value cannot be modified. Otherwise, you'll only open a hidden vulnerability. For example, an array or list constant value's elements may be modified without changing the reference of the array or list itself.
Sometimes, making an immutable class is a pleasure by itself. It's almost very easy to test, sometimes it needs no testing because it just cannot possibly break. Then, it's nice also to create constant values which are instances of this immutable class, just like constant values for Boolean.TRUE, Boolean.FALSE, etc.
There are many great examples of immutable class usages. Even the immutability itself can be raised to multiple levels, providing event tighter access on each level, e.g. no methods can be overridden, etc. I suggest you to read Effective Java book by Joshua Bloch. The book discusses immutability in great length.
I hope this short introduction to immutability may lure many future design to favor it whenever possible.. :D
Monday, April 04, 2005
VB6 no longer supported
Since last Friday, 01-Apr-2005, Microsoft no longer supports VB6. Instead, VB6 will only be supported for another 3 years in a period called extended phase. After 01-Apr-2008, VB6 will no longer be supported. During extended phase, all supports & updates will be charged. All online supports will be terminated during the extended phase. And, no new license can be bought for VB6.
For a complete story, read here:
http://msdn.microsoft.com/vbasic/support/vb6.aspx
For anyone using VB6 to deploy applications for their customers, they must now follow the new rule from Microsoft, i.e. VB.NET Downgrade Policy. This policy is given by Microsoft only on a case-by-case basis (except if it's already included in your EULA). After receiving Microsoft's approval, we must then buy the license for VB.NET, before being able to use VB6 through the Downgrade Policy.
For a complete story, read here:
http://www.microsoft.com/permission/copyrgt/cop-soft.htm#Downgrades
Following is the list of supports for several Microsoft products. Listed are the end date of their mainstream support, prior entering the extended phase like what VB6 did last Friday:
.NET SDK 30-Jun-07
.NET Framework 1.1 30-Sep-08
VB.NET 2003 30-Sep-08
VB6 EE 31-Mar-05
VBA6 31-Dec-08
C#.NET 2003 SE 30-Sep-08
C++ 6.0 EE 30-Sep-05
VSS 6.0 SE 30-Jun-07
VS.NET 2003 EE 30-Sep-08
Web Services 2.0 30-Sep-08
For a complete list, read here:
http://support.microsoft.com/gp/lifedevtoolfam
Because of this EOL issues, several MVP from Microsoft signed an open petition to ask Microsoft to support unmanaged VB (VB6) and VBA. Currently there are already 4739 signatures, including 238 of them are from Microsoft MVP.
For a complete information on the petition, read here:
http://classicvb.org/petition/
Following are some technical issues regarding the migration from VB6 to VB.NET:
1. VB6 code cannot be recompiled using VB.NET compiler
2. Migration Wizard offered by Microsoft for this purpose cannot give a complete working solution, and instead leave a lot of TODO for the developer scattered throughout the migrated code.
3. Since 1975 up to 2001, all code from MS BASIC up to VB6 are still forward compatible (even though they're not necessarily backward compatible). But this history (tradition) has been broken by the migration from VB6 to VB.NET which is not compatible (both forward & backward)
4. The changes frmo VB6 to VB.NET are very fundamental since they change the language of VB itself.
Following are more links regarding the migration issues:
http://classicvb.org/petition/faq.asp
http://www.devx.com/vb/article/16822
http://vb.mvps.org/vfred/Trust.asp
For a complete story, read here:
http://msdn.microsoft.com/vbasic/support/vb6.aspx
For anyone using VB6 to deploy applications for their customers, they must now follow the new rule from Microsoft, i.e. VB.NET Downgrade Policy. This policy is given by Microsoft only on a case-by-case basis (except if it's already included in your EULA). After receiving Microsoft's approval, we must then buy the license for VB.NET, before being able to use VB6 through the Downgrade Policy.
For a complete story, read here:
http://www.microsoft.com/permission/copyrgt/cop-soft.htm#Downgrades
Following is the list of supports for several Microsoft products. Listed are the end date of their mainstream support, prior entering the extended phase like what VB6 did last Friday:
.NET SDK 30-Jun-07
.NET Framework 1.1 30-Sep-08
VB.NET 2003 30-Sep-08
VB6 EE 31-Mar-05
VBA6 31-Dec-08
C#.NET 2003 SE 30-Sep-08
C++ 6.0 EE 30-Sep-05
VSS 6.0 SE 30-Jun-07
VS.NET 2003 EE 30-Sep-08
Web Services 2.0 30-Sep-08
For a complete list, read here:
http://support.microsoft.com/gp/lifedevtoolfam
Because of this EOL issues, several MVP from Microsoft signed an open petition to ask Microsoft to support unmanaged VB (VB6) and VBA. Currently there are already 4739 signatures, including 238 of them are from Microsoft MVP.
For a complete information on the petition, read here:
http://classicvb.org/petition/
Following are some technical issues regarding the migration from VB6 to VB.NET:
1. VB6 code cannot be recompiled using VB.NET compiler
2. Migration Wizard offered by Microsoft for this purpose cannot give a complete working solution, and instead leave a lot of TODO for the developer scattered throughout the migrated code.
3. Since 1975 up to 2001, all code from MS BASIC up to VB6 are still forward compatible (even though they're not necessarily backward compatible). But this history (tradition) has been broken by the migration from VB6 to VB.NET which is not compatible (both forward & backward)
4. The changes frmo VB6 to VB.NET are very fundamental since they change the language of VB itself.
Following are more links regarding the migration issues:
http://classicvb.org/petition/faq.asp
http://www.devx.com/vb/article/16822
http://vb.mvps.org/vfred/Trust.asp
Subscribe to:
Posts (Atom)