The current java "generics" specification (aka C++ style
templates) does not provide compatibility with primitives.  This
oversight leaves open a long standing problem in java: primitives
must be wrapped in their  customer  peers before being used in
collections and then manually copied back into primitive arrays.
Either "generics" support for primitives or at worst more efficient
methods for avoiding manual array copies between arrays
of wrapped primitives (Integer, Byte, et al) should be provided.

The cleanest method is "generics" support of primitive types.
(Review ID: 129309) 
======================================================================

workaround : Subclass/write your own collection for every primitive type
or
live without them.
======================================================================

Unlikely to be changed at this stage. Also, I'm wondering about process here:
we're filing bugs against specs that are still under development, which
strikes me as odd.

  xxxxx@xxxxx   2001-08-05

see jsr-014 for more info about the generics spec.  

Knee-jerk.  Knee-jerk.  There is no reasonable way of doing this, unless you consider automatic boxing and 
unboxing reasonable.  Don't bother voting for this bug unless you have a detailed proposal on how this could 
be implemented (and I defy anyone out there to come up with one).

If you're looking for autoboxing, I tend to side with the JSR-14 guys who felt it would be abused and that 
people would be surprised by the poor performance, and thus it's better to have to do a little more typing so 
you understand the impact of what you're doing.

Interesting the last user challenged us to come up with a
way without telling us why he feels its so unfeasible.  I
looked at the gj code, it looks feasible to me.  This isn't
a matter of more typing, its a performance consideration,
and a major one!  

Have either of you actually looked at gj?  As for casting
float[] to Object, that is an entirely different issue all
together.  The central issue is something like 

ArrayList<int> 

If primitive types were supported in the upcoming proposal
you could simply use int myint=4;arrayList.add(myint);  At
the end where you type arrayList.toArray() you'd not need
another manual copy.  Research the issue before you naysay.
 Look at GJ and look at jsr-14.  Look at the code behind GJ.

I agree with enicholas. Although support for primitive type 
would be valuable, it seem an impressively complex problem 
to me. For example it is easy to cast a Float[] array to 
Object[], but yon can't cast a float[] array to Object[]. 
The 'float' primitive and a reference to a 'Float' object 
are really two completely different beasts. You can't 
handle both of them with the same code!

Unless you have a detailed proposal about how it could be 
efficiently implemented, I believe that primitive type 
support is impractical for JSR-14. It may be supported in 
some future version however, but it may be necessary to 
explore some other issues first (boxing / unboxing...)

Oliver, I AM USING JSR-14 in my projects for many time now, 
I HAVE LOOKED to GJ and to PolyJ too (which already support 
primitive types), I have used C++ "templates" many years, 
I'm not a Java beginner (I'm actually a JCP participant) 
and I still believe this issue is way to complex for JSR-
14. Of course I way be wrong; this is just my personal 
opinion.


Lets take ArrayList as an example. ArrayList<Float> and 
ArrayList<String> are actually the same class, i.e.:

  ArrayList<String> x = new ArrayList<String>();
  ArrayList<Float>  y = new ArrayList<Float>();
  return x.getClass() == y.getClass();

Will yield "true" (reference: "Adding Generics to the Java 
Programming Language: Participant Draft Specification", 
page 2).

Those two classes share the same implementation at runtime. 
This implementation (the current ArrayList) uses an Object
[] array internally (please look at the ArrayList source 
code, distributed with the JDK). You can store String and 
Float into an Object[] array, but you can't store a 
primitive 'float'! This was my point about array cast in my 
last post. There is no way to magically transform 
the 'Object[]' array into a 'float[]' array without 
creating a new ArrayList implementation (at least not with 
the Java language as it stand today). The current JSR-14 
does not create new class (the same ArrayList 
implementation is used for everybody). Your proposal 
implied automatic generation of new code for each primitive 
type, much like the "template" mechanism in C++. It is 
feasible, but I believe it would be better handled in a 
future JSR.

Again, I'm not against primitive type support. I just 
believe this issue is much more complex than what you 
think, and I would not like to delay JSR-14 for it. If you 
want to prove me that I'm wrong, please share with us a 
working implementation of JSR-14 supporting primitive types.

Well, the current JSR-14 works with the existing Collection 
implementation with no change (JSR-14 use special 
Collection classes for compilation, but the regular JDK 
1.3's Collection classes are used at runtime). Since JSR-14 
final release is delayed to JDK 1.5 (as you rightly point 
out), some changes at the bytecode level are envisaged, but 
I would be surprise if it goes far enough to support 
efficiently generic primitive type.

I support your request for generic primitive type. I just 
believe that a fair amount of research is needed in order 
to do it right, which may be out of the scoop of JSR-14. 
Even if the current JSR-14 does not support primitive type, 
it seems to me that there is nothing in JSR-14 that 
prevents this addition in some future version. I would 
suggest to:

a) Lets the current JSR-14 continue its way (as long as it 
does not prevent primitive type support in some future 
version).

b) Wait for more research to be done on primitive issues 
(boxing / unboxing, etc.).

c) When research on primitive issues has matured enough, 
submit a new JSR for extending generic type to primitive.

What do you think?

I think the collections will all have to receive some
tweaking one way or another for generics support.  I was
using ArrayList as an example it was not meant to imply that
you'd use the array list as it is today in the jdk suddenly
with generics and/or primtives and it would automagically
work.  Secondly, As far as I know they aren't actually
including generics until jdk 1.5.  Personally I feel thats
plenty of time.  I realize the complexity of it (though I
don't agree with you on the magnitude), I just feel it is so
worth doing and would be best done sooner then have reverse
compatibility issues (With the previous implementation of
"generics") later.  

I think that when you sit back and think about how long it
is between jdk releases, you'll realize that there is no
reason not to just go ahead and make whatever significant or
insignificant updates as part of JSR-014-final.  JDK 1.2 was
released, I beleive in the latter part of 97 or early part
of 98.  JDK 1.3 was released at least a year and a half
later and had little new other than hotspot.  So you're
telling me that nearly two years (jdk 1.5) is not enough
time to do this?  My opinion is if its worth doing, its
worth doing right.  When you consider the likely and
probable timeline...  do you still feel so strongly against
it?  The scope is not so sweeping.

I do agree with you about the extra work on primitives. 
However, that is outside the scope of this bug.  I'd suggest
it might be well suited for jdk 1.5 as well.  That being
said: better primitives, generics.. . not a tall order for
(probably) two years and countless developers.   What do you
think?

Its obvious we're not going to come to an agreement on this.
 JSR-014 still needs work in my opinion, but that is a
seperate issue entirely.  Namely, "generics" support should
be, imho, at a lower level.  While I understand the desire
to provide binary backward compatibility, I think it is a
bit misguided (you do not want to mix class files from the
different major versions of the jdk unless you want to be up
at 2am one night tracking down a "bug" that mysteriously
goes away when you recompile a particular class).  

I also understand the desire not to make sweeping changes,
but imho if you are for "generics" then you should be for
the adequate full implementation (including what polyj calls
"basic types" which it does support btw).  

I don't quite understand your point if you say you are for
primtive type support but not "now" (now being two years
from now).  
I do see your point and perhaps this bug should be amended
to include "and do what is necessary to support them
properly".  

One last clarification.  Primitive type handling WILL be a
special case, I'm not saying it will be clean.  Why? 
Primitive types are a special case in java and are not
handled cleanly.  I still hold that it can and should be
done within the scope of jdk 1.5.

JSR-14 has been possible because a lot of work have been 
done with GJ and PolyJ before the JSR started. GJ started 
in 1996, PolyJ in 1997 and JSR-14 in 1999.


I agree with the expert group's argument: "A homogeneous 
translation similar to the existing proposal can be 
extended to support primitive types. However, such an 
approach does not address one of the primary arguments made 
for abstracting over primitive types, which is to increase 
the performance of numerical codes. Rather, it creates a 
situation where users may be radically misled as to the 
performance characteristics of a generic class. Given the 
conceptual problems associated with supporting primitive 
types in generics, a solution that does not provide 
the "expected" performance benefits seems unattractive."

Reference: jsr-14-public-draft.html, "Treatment of 
Primitive Types".

P.S. Reading the above document again, I may have been 
wrong when I said that there is nothing in JSR-14 that 
prevent primitive type support. Efficient primitive type 
support require heterogeneous translations scheme, which 
have been rejected for pretty good raisons.

Support for generics with primitive types is not as hard as
people seem to think.  There are basically only two ways of
implementing it: automatic boxing/unboxing (similar to what
programmers already do by hand in Java) and compiling
specialized versions (similar to C++ templates, but without
the complex interactions of template expansions and
overloading).  People argue at length about which is better,
but the answer is: neither is. Both are essential for a
broad spectrum programming language. If you fail to provide
either, programmers end up having to emulate the other by
hand.

What Java should do is continue to offer its current
generics.  To that, it should add automatic boxing/unboxing
when those generics are instantiated with primitive types.
In addition, it should provide an additional keyword that
allows programmers to declare that they wish the compiler to
generate specialized code for a particular combination of
primitive type arguments for template instantiation.

This is not a big project.  Compiling specialized versions
of template instantiations on request is easy to do.

Without this feature, Java's generics are essentially
useless for high performance code.  If Sun doesn't provide
this feature, it will only encourage the use of C++ native
code linked to Java code, the proliferation of incompatible
Java variants, or the move to a future variant of C# with
generics (which Microsoft has promised).

I agree with tbreuel.  As for the evaluation, it seemed
odder to wait until afterward to complain. 

I would like to second the two former authors:
  providing generics without primitive types means only
cleaning
  up syntax a little bit, but is not really useful.

What is needed for using Java in numerical high performance
computing as for example in Data Mining are 
efficient data structures that are normally build from 
simple data structures as array lists, linked lists, ordered
lists, trees, graphs, etc. 

Clearly such data structures cannot be implemented by
boxing/unboxing, as performance is prohibitive here, but 
they have to be implemented by instantiating new class
objects for each combination of parameters. 

I do not know if it is possible to do this with the actual
JVM. But if limitations of the JVM are the reason to 
hold back full support for generics in Java, this should
be clearly stated.

As normally only a few combinations are used per program,
I cannot see any memory issues here as sometimes mentioned
by others.

The plethora of projects that aim to add this type of
generics support to Java is a clear evidence that something
is severly missing here! 

Generally speaking, I've been incredibly disappointed with 
the current generics proposal and this 'bug' is just one 
more problem I have with it.

Java 'templates' absolutely need to support primitives for 
high-performance code. 

No - Writing a separate implementation of HashMap each time 
I want to support one more primitive type is not 
acceptable. 

No - Automatic boxing/un-boxing is not an acceptable 
alternative for high performance code which needs 
to 'traverse' data structures large numbers of times.

Yes - Separate instantiations of templates are acceptable 
for primitives. In fact, more than being acceptable, it's 
exactly what is desired.

Yes - The effort to support primitives is feasible, and 
easily implementable within the 1.5 time frame.

I can't begin to express my frustration with Sun's choice 
to provide such poor support for generics. Programmers 
don't need a mechanism for safe type-casting - we need a 
mechanism for true parametric polymorphism with little 
penalty.

I understand that Sun has been doing great things with 1.4, 
and I've been tremendously impressed with the progress 
there, but please, don't disenfranchise the entire 
developer community by ignoring their pleas for a well 
understood and respected method of supporting generics.

God bless,
-Toby Reyelts

I agree with MartDesruisseaux

Like tbreuel wrote, an extension to javacc (or an extra 
application) for supporting a special template syntax is 
what I would highly recommend.
Such templates would be usefull in more situations as only 
those when dealing with primitive data structures, and the 
author still has control over his code, instead of trust 
into what the compiler does...
My suggestion is a template compiler, which compiles a 
template for a given set of parameters to a standard java 
source file.
Template processors are already available. But it would be 
fine to have one which is a real part of the java 
language, in a way, template code can be mixed with 
standard code. And special support integrated into 
Netbeans...yamma!

Currently you have first to process a template, and than 
with javacc the translated output.

A standard template language implemented in the java 
language could be used for a lot of things: Mixing java
with html, xml, sql-statements...

And, of course, for minimizing the coding overhead for the
eight primitive types.

In fact there already are the Java Server Pages, which 
could, slightly modified, be used for such tasks,
but without the bunch of software currently required.

I don't think there is an efficient way to integrate 
primitives into the generics specification, even with 
changes to the JVM. Efficient code for primitive data 
structures needs special attention by the coder, not by 
the compiler, nor by the jvm.

If it is not fixed, Java generics will be close to 
worthless for me.

Support for primitives should be transparent. Support in generic is good, but the best place should be in the base language. Why should the developer care about primitive or non primitive types when we have powerfull compilers. Let the compiler handle this things transparently.

ps. Evolution seems to let us down, for now. ;)

The real problem is that there is no uniform type system. 
In such a world there is no need for this amount of 
hacking; although primitive types will still need to be 
optimized for. But that's a dream of course. I wish some 
future version of Java will be submitted to ECMA or some 
other organization where this could be fixed, but backward 
compatibility is also a major issue and a constant show-
stopper; understandable, but its just a shame that so much 
has to be "patched" due to this other bug (or missing 
feature if you're thinking constructively). Perhaps Java 
and C# could be merged then. Sorry, still dreaming.

How many primitives are there? Last count, about 8, and not 
growing.  How many of the generic classes would this really 
have to apply to?  Not very many.  So imagine that JDK 1.6 
shipped with a few hundred extra classes (have you actually 
counted the classes in the JDK?), and that the compiler 
transparently turns your request for a 
Hashtable<int,String> into a $Hashtable_int_Object<String>.

Problem solved.  OK, maybe not quite, but this problem 
really isn't as hard as people seem to think.  Like 
acoliver says, this solution isn't perfect because there is 
no perfect solution. You just have to do it anyway, because 
it needs doing.

> ps. Evolution seems to let us down, for now. ;)

It has been for centuries :p

"Unlikely to be changed at this stage."

What sort of "evaluation" is that?

"Also, I'm wondering about process here: we're filing bugs against specs
that are still under development, which strikes me as odd."

Sun is preparing to "fix" something incorrectly,
just as they did for Design By Contract with their
"assert facility".  Surely it is better to point this out
beforehand rather than after.

The evaluation says "we're filing bugs against specs that
are still under development, which
strikes me as odd." There's a good reason for these bugs.
Some of us are concerned that the upcoming generics
implementation is broken and/or useless.

As a follow-up to the comment by joerg.wassmer, I note that 
a custom javadoc doclet can perform this sort of 
preprocessing [1].  For instance, XDoclet [2] is used to 
generate JSP tag library XML description files from servlet 
source files.  And the Swing development team uses a doclet 
to generate beaninfo class source from bean source [3].

[1]
http://developer.java.sun.com/developer/technicalArticles/Pr
ogramming/Javadoc/

[2]
http://xdoclet.sourceforge.net

[3]
See the fourth paragraph.
http://www.javaworld.com/javaworld/jw-03-2001/jw-0302-
doclets.html

My great hope is that we'll get both lightweight objects 
and generics; which would solve the concerns raised above.  
Read more about lightweight objects:

Kava: A Java Dialect with a Uniform Object Model for 
Lightweight Classes 
David Bacon (IBM Watson Research Center)
http://www.research.ibm.com/people/d/dfb/papers.html#Bacon01
Kava

You can do

       Object arr = new int[30];

so why can't the Collection primatives use this for their 
reference instead, and use a boolean and some casting.  
That is what developers are gonna have to do anyway.  It's 
the convienence and consistancy of this that is important to 
developers.

generics support is needed for high performance requirments
only (the most inner cycles). in such case I dont care about
collection framework at all.
i just forget about it and do it just by hand-made code.
direct result is full-control and performance. and half an
hour coding. not that bad to way to wait for feature jsr on
anything...

I've written a proposal for Java unified types via automatic 
boxing/unboxing which is in draft JSR form. I also have 
completed a prototypical implementation for int/Integer based 
GJC which works rather well and makes minimal code changes. 

I've read all the comments here, and like many of you, I agree 
that Generics with unified primitive types become much more 
useful with paramaterized instantiation. However, making a 
change to unified types via boxing/unboxing is the first step. 
Paramaterized instantiation will require changes to the JVM 
and can come later. 

Please see my proposal and send me comments:

http://mozart.chat.net/~jeske/Projects/Java/java_foreach.ht
ml

well I do think that this RFE is solved by auto-boxing in Tiger.

...except that the performance characteristics of an autoboxed ArrayList<Integer> is different from a non-autoboxed ArrayList<int>.

If it was the same, the Trove project wouldn't exist.  As it is, I continue to believe this remains open; Java needs either to have the int<->Integer be zero cost - unlikely - or transparently pick up ArrayList<int> and choose the correct concrete implementation.  Alternately, provide us visible, concrete implementations of those classes, with appropriate API, and let us deal with when to use which - but please supply *something* to solve this problem; it's just not worth the performance penalty.

This wouldn't be necessary if the compiler could look at the code and use an internal int[] instead of an internal Object[] when possible.  Basically the compiler would have to look at the instantiation of a generic type using <Integer>, determine that the reference is never looked at, and then substitute a int[] for the internal array.  

The point I'm making is that if can imagine a really smart compiler that  could do this without changing the API at all, then I'm sure we could get this to work if we allowed for changes to the API. 

The performance characteristics of large collections are just horrible the way they are implemented now.  I hate having to make excuses for the performance of my Java code.  And I don't want to rewrite every class that stores doubles when using a generic class should do.  

Just a follow up to my own post.. 

I would actually prefer things working the way I suggested above.  I just don't think it is practical right now. 

That is, it would be nice if the compiler always used primitive types when the reference values are not ever referenced in the code.  It might not be possible because of reflection, but it would be nice.  Something like Hotspot might be able to do this if it was sufficiently smart.  

It would be nice.
But there is no way to do this (address space would not be able to handle this).

for Integers(longs) i suggest increase offset to 2048 or more:

 public static Integer valueOf(int i) {
	final int offset = 128;
	if (i >= -128 && i <= 127) { // must cache 
	    return IntegerCache.cache[i + offset];
	}
        return new Integer(i);
    }

For others YES there is a solution.
1. Use cached Objects always and thread primitives like boolean as Boolean with not null checking.
2. Make constructor private.


U need explanation ?

Greetings.
http://lasu2string.blogspot.com/