[The Java Posse] Multi-threading
It appears (in recent podcasts) that the Posse (Dick only?) equates multi-threading to parallelism. Definitely, if you're interested in calculations and batch processing this is the way to go and Actors/MapReduce/Executors/Futures/fork-join/ etc. help greatly. Concurrency seems to be ignored though... Bruce Eckel brought it up a little (Goetz talk?) but the discussion moved quickly to parallelism (and Scala...). :-( Typically, applications that rely on a lot of interactions and shared data can't use these high level constructs. The current solution is to use a container (app-server?) to deal with the interaction part and hope for some data access layer to deal with the shared data issues. But this breaks down very quickly when performance isn't good. Then these tasks are moved in the application itself and we're back to square one again... So far, I haven't seen many answers to this. The only answer I've found is the excellent MultithreadedTC by Bill Pugh and Nat Ayewah. It is a very good tool but still relies on already understanding the multi-threading issues that you are testing for... If you don't it's a bit of a chicken-and-egg problem... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] DB2 is nowhere?
I've got the impression that the Posse had agreed on the last podcast that DB2 is insignificant in the DB market. All the places I've been were using Oracle, etc. Come on, we are technologists...! So, I thought I might add some related links and numbers: (the numbers on the reports seem to change a little every time... :-/) 1999 - $8 billion - IBM 29.9% ($2.39Bn), Oracle 31.1% ($2.49Bn) http://www.gartner.com/5_about/press_room/pr2503a.html 2000 - $8.7 billion - IBM 30.1% ($2.62Bn), Oracle 33.8% ($2.94Bn) http://www.gartner.com/5_about/press_room/pr20010523b.html 2001 - $8.8 billion - IBM 34.6% ($3.06Bn), Oracle 32% ($2.83Bn) http://www.gartner.com/5_about/press_releases/2002_05/pr20020507a.jsp 2002 - $6.6 billion - IBM 36.2% ($2.4Bn), Oracle 33.9% ($2.25Bn) http://www.gartner.com/press_releases/pr21may2003a.html 2003 - $7.06 billion - IBM 35.7% ($2.52Bn), Oracle 32.6% ($2.3Bn) http://www.gartner.com/press_releases/asset_86529_11.html 2004 - $7.79 billion - IBM 34.1% ($2.66Bn), Oracle 33.7% ($2.64Bn) http://www.gartner.com/press_releases/asset_127553_11.html 2005 - $13.82 billion - IBM 22.0% ($3.04Bn), Oracle 48.6% ($6.72Bn) http://www.gartner.com/it/page.jsp?id=493002 (The 2004 numbers here are very different from before... Maybe they are measuring different things now.) Linux grew the fastest of all the RDBMS platforms (84 percent), driven primarily by Oracle, and the maturation and user acceptance of the Linux platform as a mission-critical DBMS platform. 2006 - $15.21 billion - IBM 21.1% ($3.2Bn), Oracle 47.1% ($7.17Bn) http://www.gartner.com/it/page.jsp?id=507466 Each of the major three vendors continue to dominate their particular platform; Oracle on Unix and Linux, Microsoft on Windows, and IBM on the zSeries. 2007 - $18.8 billion - IBM 21% ($3.95Bn), Oracle 44.3% ($8.33Bn) http://www.pcworld.com/businesscenter/article/147684/idc_oracle_maintains_lead_in_database_market.html (These are IDC numbers) So, DB2 (Almost all of IBM's RDBMS revenue + some Informix) is not *nowhere* out there. For a while it was ahead of Oracle, while it is always ahead of SQLServer. And revenue-wise it hasn't lost ground; it's still growing. Regards, Tasos Zervos --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: Fwd: [The Java Posse] Re: episode 215: reflection and generics
Marcelo,
If instead of GenericTestE you replace with e.g. MapE
what I interpret you are saying is that you can't tell
from the (runtime) Map object what type E it is meant to be used
with.
However, the client of such an object *will* know the type, like this:
public MapString,String map1 = new HashMapString,String();
Wouldn't a client using GenericTestE not include GenericTestString
at compile time?
Am I still missing something here?
On Nov 11, 4:42 pm, Marcelo Fukushima [EMAIL PROTECTED] wrote:
actually my point was that you can only get the generic type
information in the cases where it is there in compile time
but, for instance, imagine that you had this:
public class GenericTestE {
private ListE list = new ArrayListE();
}
even if you create an instance of GenericTest with String, the generic
type of the list field would be ParameterizedType and theres
absolutely no way to get the String parameter you passed in the
constructor - thats because in java, generics are implemented with
erasure instead of reified types, in which case you could fetch the
type information
On 11/11/08, Tasos Zervos [EMAIL PROTECTED] wrote:
Can you please give an example with some bits of code?
I'm not sure what scenario you are trying to solve (or implying you
can't solve).
What are you going to use a Map?,? instance field for?
(Would this be a Generics way of initialise a field?)
On Nov 10, 10:27 pm, Marcelo Fukushima [EMAIL PROTECTED] wrote:
just a quick observation: it only works because the maps you're trying
to extract the generic info from, contains such information in the
containing class file (the GenericTest fields specifically) - try
changing the field types to Map?, ? and you wont the get info
anymore, even tough you created the maps with the type information
-- Forwarded message --
From: Tasos Zervos [EMAIL PROTECTED]
Date: Mon, Nov 10, 2008 at 10:48 AM
Subject: [The Java Posse] Re: episode 215: reflection and generics
To: The Java Posse javaposse@googlegroups.com
If you aren't keen to follow the article try this:
import java.lang.reflect.*;
import java.util.*;
public class GenericTest
{
public HashMapString,String map1 = new HashMapString,String();
public HashMapDate,Date map2 = new HashMapDate,Date();
public static String fieldSignature(Object obj, String fieldName)
throws SecurityException,
NoSuchFieldException
{
StringBuffer signature = new StringBuffer(fieldName);
Field field = GenericTest.class.getField(fieldName);
Type genericFieldType = field.getGenericType();
if(genericFieldType instanceof ParameterizedType)
{
signature.append( is of type
).append(obj.getClass().getName()).append();
ParameterizedType aType = (ParameterizedType)
genericFieldType;
Type[] fieldArgTypes = aType.getActualTypeArguments();
for(Type fieldArgType : fieldArgTypes)
{
Class fieldArgClass = (Class) fieldArgType;
signature.append(fieldArgClass.getName()).append(,);
}
signature.append();
}
return signature.toString();
}
public static void main(String[] args) throws SecurityException,
NoSuchFieldException
{
GenericTest test = new GenericTest();
System.out.println(map1.getClass() == map2.getClass() is
+ (test.map1.getClass() == test.map2.getClass()) );
System.out.println(map1.getClass() is +
test.map1.getClass());
System.out.println(map2.getClass() is +
test.map2.getClass());
System.out.println(GenericTest.fieldSignature(test.map1,
map1));
System.out.println(GenericTest.fieldSignature(test.map2,
map2));
}
}
My quick test shows:
map1.getClass() == map2.getClass() is true
map1.getClass() is class java.util.HashMap
map2.getClass() is class java.util.HashMap
map1 is of type java.util.HashMapjava.lang.String,java.lang.String,
map2 is of type java.util.HashMapjava.util.Date,java.util.Date,
:-D
Tasos
On Nov 10, 12:46 pm, Tasos Zervos [EMAIL PROTECTED] wrote:
The equality test has to return true otherwise you would be breaking
compatibility with older code.
This doesn't mean that there aren't other ways to find the signature
of map1 and map2.
The Reflection API does provide access to the specific types of
generic signatures.
Have a look at this 2005
article:http://www-128.ibm.com/developerworks/java/library/j-cwt11085.html#h2
The article series uses ASM (DRY) also later on.
On Nov 4, 11:05 pm, Christian Catchpole [EMAIL PROTECTED]
wrote:
Here is my analysis of the situation. I could be wrong
[The Java Posse] Re: Fwd: [The Java Posse] Re: episode 215: reflection and generics
Can you please give an example with some bits of code?
I'm not sure what scenario you are trying to solve (or implying you
can't solve).
What are you going to use a Map?,? instance field for?
(Would this be a Generics way of initialise a field?)
On Nov 10, 10:27 pm, Marcelo Fukushima [EMAIL PROTECTED] wrote:
just a quick observation: it only works because the maps you're trying
to extract the generic info from, contains such information in the
containing class file (the GenericTest fields specifically) - try
changing the field types to Map?, ? and you wont the get info
anymore, even tough you created the maps with the type information
-- Forwarded message --
From: Tasos Zervos [EMAIL PROTECTED]
Date: Mon, Nov 10, 2008 at 10:48 AM
Subject: [The Java Posse] Re: episode 215: reflection and generics
To: The Java Posse javaposse@googlegroups.com
If you aren't keen to follow the article try this:
import java.lang.reflect.*;
import java.util.*;
public class GenericTest
{
public HashMapString,String map1 = new HashMapString,String();
public HashMapDate,Date map2 = new HashMapDate,Date();
public static String fieldSignature(Object obj, String fieldName)
throws SecurityException,
NoSuchFieldException
{
StringBuffer signature = new StringBuffer(fieldName);
Field field = GenericTest.class.getField(fieldName);
Type genericFieldType = field.getGenericType();
if(genericFieldType instanceof ParameterizedType)
{
signature.append( is of type
).append(obj.getClass().getName()).append();
ParameterizedType aType = (ParameterizedType)
genericFieldType;
Type[] fieldArgTypes = aType.getActualTypeArguments();
for(Type fieldArgType : fieldArgTypes)
{
Class fieldArgClass = (Class) fieldArgType;
signature.append(fieldArgClass.getName()).append(,);
}
signature.append();
}
return signature.toString();
}
public static void main(String[] args) throws SecurityException,
NoSuchFieldException
{
GenericTest test = new GenericTest();
System.out.println(map1.getClass() == map2.getClass() is
+ (test.map1.getClass() == test.map2.getClass()) );
System.out.println(map1.getClass() is +
test.map1.getClass());
System.out.println(map2.getClass() is +
test.map2.getClass());
System.out.println(GenericTest.fieldSignature(test.map1,
map1));
System.out.println(GenericTest.fieldSignature(test.map2,
map2));
}
}
My quick test shows:
map1.getClass() == map2.getClass() is true
map1.getClass() is class java.util.HashMap
map2.getClass() is class java.util.HashMap
map1 is of type java.util.HashMapjava.lang.String,java.lang.String,
map2 is of type java.util.HashMapjava.util.Date,java.util.Date,
:-D
Tasos
On Nov 10, 12:46 pm, Tasos Zervos [EMAIL PROTECTED] wrote:
The equality test has to return true otherwise you would be breaking
compatibility with older code.
This doesn't mean that there aren't other ways to find the signature
of map1 and map2.
The Reflection API does provide access to the specific types of
generic signatures.
Have a look at this 2005
article:http://www-128.ibm.com/developerworks/java/library/j-cwt11085.html#h2
The article series uses ASM (DRY) also later on.
On Nov 4, 11:05 pm, Christian Catchpole [EMAIL PROTECTED]
wrote:
Here is my analysis of the situation. I could be wrong. But here
goes..
When I got my copy of Java 5 my first question was, do generics really
take the cast out of the equation? I disassembled the code to find
the cast still exists. This implies that when you compile this..
HashMapString,String map = new HashMapString,String()
String string = map.get();
The generated code actually equates to this..
HashMap map = new HashMap()
String string = (String)map.get();
The class returned by map.getClass() does not know the map only
contains Strings. It's actually the reference to the map which
marshals the types.
I did a quick test...
HashMapString,String map1 = new HashMapString,String();
HashMapDate,Date map2 = new HashMapDate,Date();
System.out.println(map1.getClass() == map2.getClass());
true
They use the same class and can't therefore hold the type information
for both declarations.
I can only assume this re-compiler the posse were talking about, scans
the code for the actual cast / type check to determine the types.
--
[]'s
Marcelo Takeshi Fukushima
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups The
Java Posse group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http
[The Java Posse] Re: episode 215: reflection and generics
Episode #166 - Guillaume Laforge on Groovy also included Guillaume describing how Groovy gets the Generics info from Java [class-loaded] classes! Posse, posse... ;-) On Nov 6, 6:53 pm, Casper Bang [EMAIL PROTECTED] wrote: It's actually all described in chapter 7.5 of Java Generics and Collections which the Posse have endorsed in the past. Basically you can introspect it (look for ParameterizedType) and it can help you in a few instances, but in my humble experiences those solutions often turns ugly and fragile (played with that a while ago:http://coffeecokeandcode.blogspot.com/2008/05/type-strategy-pattern.html). /Casper On Nov 6, 3:13 pm, Jess Holle [EMAIL PROTECTED] wrote: Viktor Klang wrote: On Thu, Nov 6, 2008 at 1:49 PM, Jess Holle [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Viktor Klang wrote: Actually guys, referential equality is kind of retarded, so the MapString,Integer.class == MapFoo,Bar.class example is bad. However, MapString,Integer.class.equals(MapFoo,Bar.class) SHOULD return false No, it MUST not -- else loads of things break. If you want to make an omelet, you've got to break some eggs... Yes, but breaking eggs just cause you feel like it is for toddlers, not chefs. Further == and .equals MUST give the same results for Class objects -- else loads of things break. The ConcreteClass noted below would not be a Class -- it would be a new API. Yeah, I realize that, that's why I'm moving away from Java. I'm still missing what the real benefit to having these Class objects be unequal is. It sounds nice in some ivory tower sort of way, but really as long as you have access to the fact that the K parameter is String and the V parameter is Integer (and the compiler can use this as well to do things like new V[]), I don't really see any issue. -- Jess Holle --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: episode 215: reflection and generics
If you aren't keen to follow the article try this:
import java.lang.reflect.*;
import java.util.*;
public class GenericTest
{
public HashMapString,String map1 = new HashMapString,String();
public HashMapDate,Date map2 = new HashMapDate,Date();
public static String fieldSignature(Object obj, String fieldName)
throws SecurityException,
NoSuchFieldException
{
StringBuffer signature = new StringBuffer(fieldName);
Field field = GenericTest.class.getField(fieldName);
Type genericFieldType = field.getGenericType();
if(genericFieldType instanceof ParameterizedType)
{
signature.append( is of type
).append(obj.getClass().getName()).append();
ParameterizedType aType = (ParameterizedType)
genericFieldType;
Type[] fieldArgTypes = aType.getActualTypeArguments();
for(Type fieldArgType : fieldArgTypes)
{
Class fieldArgClass = (Class) fieldArgType;
signature.append(fieldArgClass.getName()).append(,);
}
signature.append();
}
return signature.toString();
}
public static void main(String[] args) throws SecurityException,
NoSuchFieldException
{
GenericTest test = new GenericTest();
System.out.println(map1.getClass() == map2.getClass() is
+ (test.map1.getClass() == test.map2.getClass()) );
System.out.println(map1.getClass() is +
test.map1.getClass());
System.out.println(map2.getClass() is +
test.map2.getClass());
System.out.println(GenericTest.fieldSignature(test.map1,
map1));
System.out.println(GenericTest.fieldSignature(test.map2,
map2));
}
}
My quick test shows:
map1.getClass() == map2.getClass() is true
map1.getClass() is class java.util.HashMap
map2.getClass() is class java.util.HashMap
map1 is of type java.util.HashMapjava.lang.String,java.lang.String,
map2 is of type java.util.HashMapjava.util.Date,java.util.Date,
:-D
Tasos
On Nov 10, 12:46 pm, Tasos Zervos [EMAIL PROTECTED] wrote:
The equality test has to return true otherwise you would be breaking
compatibility with older code.
This doesn't mean that there aren't other ways to find the signature
of map1 and map2.
The Reflection API does provide access to the specific types of
generic signatures.
Have a look at this 2005
article:http://www-128.ibm.com/developerworks/java/library/j-cwt11085.html#h2
The article series uses ASM (DRY) also later on.
On Nov 4, 11:05 pm, Christian Catchpole [EMAIL PROTECTED]
wrote:
Here is my analysis of the situation. I could be wrong. But here
goes..
When I got my copy of Java 5 my first question was, do generics really
take the cast out of the equation? I disassembled the code to find
the cast still exists. This implies that when you compile this..
HashMapString,String map = new HashMapString,String()
String string = map.get();
The generated code actually equates to this..
HashMap map = new HashMap()
String string = (String)map.get();
The class returned by map.getClass() does not know the map only
contains Strings. It's actually the reference to the map which
marshals the types.
I did a quick test...
HashMapString,String map1 = new HashMapString,String();
HashMapDate,Date map2 = new HashMapDate,Date();
System.out.println(map1.getClass() == map2.getClass());
true
They use the same class and can't therefore hold the type information
for both declarations.
I can only assume this re-compiler the posse were talking about, scans
the code for the actual cast / type check to determine the types.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups The
Java Posse group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---
[The Java Posse] Re: episode 215: reflection and generics
The equality test has to return true otherwise you would be breaking compatibility with older code. This doesn't mean that there aren't other ways to find the signature of map1 and map2. The Reflection API does provide access to the specific types of generic signatures. Have a look at this 2005 article: http://www-128.ibm.com/developerworks/java/library/j-cwt11085.html#h2 The article series uses ASM (DRY) also later on. On Nov 4, 11:05 pm, Christian Catchpole [EMAIL PROTECTED] wrote: Here is my analysis of the situation. I could be wrong. But here goes.. When I got my copy of Java 5 my first question was, do generics really take the cast out of the equation? I disassembled the code to find the cast still exists. This implies that when you compile this.. HashMapString,String map = new HashMapString,String() String string = map.get(); The generated code actually equates to this.. HashMap map = new HashMap() String string = (String)map.get(); The class returned by map.getClass() does not know the map only contains Strings. It's actually the reference to the map which marshals the types. I did a quick test... HashMapString,String map1 = new HashMapString,String(); HashMapDate,Date map2 = new HashMapDate,Date(); System.out.println(map1.getClass() == map2.getClass()); true They use the same class and can't therefore hold the type information for both declarations. I can only assume this re-compiler the posse were talking about, scans the code for the actual cast / type check to determine the types. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
