Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #33884 > unrolled thread

array of HashSet<>

Back to article view | Back to comp.lang.java.programmer

Contents

  array of HashSet<> Roedy Green <see_website@mindprod.com.invalid> - 2016-02-26 16:12 -0800
    Re: array of HashSet<> Arne Vajhøj <arne@vajhoej.dk> - 2016-02-26 20:01 -0500
      Re: array of HashSet<> Arne Vajhøj <arne@vajhoej.dk> - 2016-02-27 10:05 -0500
    Re: array of HashSet<> Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2016-02-26 21:13 -0800
    Re: array of HashSet<> Robert Klemme <shortcutter@googlemail.com> - 2016-02-27 11:41 +0100
    Re: array of HashSet<> Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2016-02-27 11:54 -0800
      Re: array of HashSet<> Lew <lewbloch@gmail.com> - 2016-02-27 15:16 -0800
        Re: array of HashSet<> Lew <lewbloch@gmail.com> - 2016-02-27 15:18 -0800
    Re: array of HashSet<> Roedy Green <see_website@mindprod.com.invalid> - 2016-02-27 23:44 -0800
      Re: array of HashSet<> Lew <lewbloch@gmail.com> - 2016-02-28 01:52 -0800
      Re: array of HashSet<> Arne Vajhøj <arne@vajhoej.dk> - 2016-02-28 08:38 -0500
        Re: array of HashSet<> Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-02-28 08:56 -0500
          Re: array of HashSet<> Arne Vajhøj <arne@vajhoej.dk> - 2016-02-28 12:47 -0500
            Re: array of HashSet<> Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-02-28 13:27 -0500
              Re: array of HashSet<> Sebastian <news@seyweiler.dyndns.org> - 2016-02-28 23:53 +0100
                Re: array of HashSet<> Arne Vajhøj <arne@vajhoej.dk> - 2016-02-28 21:16 -0500
                  Re: array of HashSet<> Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2016-02-28 23:36 -0800
                    Re: array of HashSet<> Roedy Green <inquiry@mindprod.com> - 2016-06-08 20:08 -0700
                Re: array of HashSet<> Andreas Leitgeb <avl@logic.at> - 2016-02-29 13:19 +0000
                  Re: array of HashSet<> Andreas Leitgeb <avl@logic.at> - 2016-02-29 13:27 +0000
    Re: array of HashSet<> Daniel Pitts <usenet@coloraura.com> - 2016-03-06 13:59 -0800
      Re: array of HashSet<> Roedy Green <inquiry@mindprod.com> - 2016-06-08 20:10 -0700
        Re: array of HashSet<> Lew <lewbloch@gmail.com> - 2016-06-10 12:25 -0700
          Re: array of HashSet<> Daniel Pitts <usenet@coloraura.com> - 2016-06-11 12:30 -0700
          Re: array of HashSet<> Roedy Green <inquiry@mindprod.com> - 2016-06-12 02:31 -0700

Page 1 of 2  [1] 2  Next page →

#33884 — array of HashSet<>

I take it is impossible to write a valid Java program containing an
array of HashSet<> s. 

Any ideas for a work around?
-- 
Roedy Green Canadian Mind Products http://mindprod.com
It is tact that is golden, not silence.
~ Samuel Butler

[toc] | [next] | [standalone]

#33885

On 2/26/2016 7:12 PM, Roedy Green wrote:
> I take it is impossible to write a valid Java program containing an
> array of HashSet<> s.
>
> Any ideas for a work around?

You can have an array of references to HashSet objects.

Arne

[toc] | [prev] | [next] | [standalone]

#33889

On 2/26/2016 11:29 PM, Stefan Ram wrote:
> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:
>> You can have an array of references to HashSet objects.
>
>    There are discussions about adding value types:
>
> cr.openjdk.java.net/~jrose/values/values-0.html
> www.beyondjava.net/blog/java-8-types-revamping-javas-type-system/

Sure.

But I don't consider HashSet a good candidate for value object -
deep value object - not just top level as value object.

Arne

[toc] | [prev] | [next] | [standalone]

#33887

In article <tbq1dbl7do4o9bdqo98prrmhe8tm4g6710@4ax.com>,
 Roedy Green <see_website@mindprod.com.invalid> wrote:

> I take it is impossible to write a valid Java program containing an
> array of HashSet<> s. 
> 
> Any ideas for a work around?

What doesn't work about it?

If you mean contiguous structures, then no.  Sadly, Java can not pack 
multiple objects in a single block of memory like C/C++ can.  (If you're 
curious what for:  Vectors, pixels, voxels, particles, neural networks, 
database rows, etc.  Millions or billions of identical objects packed 
together for very fast access and efficient storage.)

-- 
I will not see posts from astraweb, theremailer, dizum, or google
because they host Usenet flooders.

[toc] | [prev] | [next] | [standalone]

#33888

On 27.02.2016 01:12, Roedy Green wrote:
> I take it is impossible to write a valid Java program containing an
> array of HashSet<> s.
>
> Any ideas for a work around?

I am not sure what you are asking.

package cljp;

import java.util.ArrayList;
import java.util.HashSet;

public final class ArrayOfHashSet {

     public static <T> HashSet<T> validProgram() {
         @SuppressWarnings("unchecked")
         final HashSet<T>[] arrayOfHashSets = (HashSet<T>[]) new 
HashSet<?>[10];

         for (int i = 0; i < arrayOfHashSets.length; ++i) {
             arrayOfHashSets[i] = new HashSet<>();
         }

         return arrayOfHashSets[1];
     }

     public static <T> HashSet<T> workaround() {
         final ArrayList<HashSet<T>> arrayOfHashSets = new ArrayList<>();

         for (int i = 0; i < 10; ++i) {
             arrayOfHashSets.add(new HashSet<>());
         }

         return arrayOfHashSets.get(1);
     }
}

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#33890

On 2/26/16 4:12 PM, Roedy Green wrote:
> I take it is impossible to write a valid Java program containing an
> array of HashSet<> s.
>
> Any ideas for a work around?

I'm not sure I understand your problem description.  Are you sure you 
need an array, and not some other ordered container?  What is the 
reasoning behind wanting array.

[toc] | [prev] | [next] | [standalone]

#33891

On Saturday, February 27, 2016 at 11:54:45 AM UTC-8, Daniel Pitts wrote:
> On 2/26/16 4:12 PM, Roedy Green wrote:
> > I take it is impossible to write a valid Java program containing an
> > array of HashSet<> s.
> >
> > Any ideas for a work around?

<sscce>
package practice;

import java.util.HashSet;
import java.util.Set;

/**
 * Arrayed.
 */
public class Arrayed {
    public static void main(String[] args) {
        Set<String> [] ahashers = makeArray(new HashSet<>(), new HashSet<>());
        System.out.println(ahashers.length);

        Set<String> [] asetters = makeArray(new HashSet<>(), new HashSet<>());
        System.out.println(asetters.length);
    }

    private static <T> T[] makeArray(T ... items) {
        return items;
    }
}
</sscce>

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#33892

package practice;

import java.util.HashSet;
import java.util.Set;

/**
 * Arrayed.
 */
public class Arrayed {
    public static void main(String[] args) {
        HashSet<String> [] ahashers = makeArray(new HashSet<>(), new HashSet<>());
        System.out.println(ahashers.length);

        Set<String> [] asetters = makeArray(new HashSet<>(), new HashSet<>());
        System.out.println(asetters.length);
    }

    private static <T> T[] makeArray(T ... items) {
        return items;
    }
}

[toc] | [prev] | [next] | [standalone]

#33893

I am not trying to arrange the HashSet fields in order in an array. I
am just trying to do something like this:


         private final HashSet<Long>[] hashSets;
        // actually a <Long>[]
        hashSets = new HashSet[ filesToProcess.length ];
        // allocate hashsets to track what is in the files, one per
file.
        for ( int i = 0; i < filesToProcess.length; i++ )
            {
            hashSets[ i ] = new HashSet<>( ALLOC );
            }


I get this error message:

Warning:(104, 20) java: unchecked conversion
  required: java.util.HashSet<java.lang.Long>[]
  found:    java.util.HashSet[]

-- 
Roedy Green Canadian Mind Products http://mindprod.com
The standard definition of AI is that which we don’t understand.
~ Bill Joy (born:1954-11-08 age:61), co-inventor of Java.

[toc] | [prev] | [next] | [standalone]

#33894

On Saturday, February 27, 2016 at 11:44:42 PM UTC-8, Roedy Green wrote:
> I am not trying to arrange the HashSet fields in order in an array. I
> am just trying to do something like this:
> 
> 
>          private final HashSet<Long>[] hashSets;
>         // actually a <Long>[]
>         hashSets = new HashSet[ filesToProcess.length ];

The right side a raw type base type, so the 'HashSet' doesn't know that it's a <Long>. Hence the error message. The helper method trick I showed is the cleanest way around all that generics/array mashup stuff, but the suggestion made upthread to use a 'List' instead of an array is better.

>         // allocate hashsets to track what is in the files, one per
> file.
>         for ( int i = 0; i < filesToProcess.length; i++ )
>             {
>             hashSets[ i ] = new HashSet<>( ALLOC );
>             }
> 
> 
> I get this error message:
> 
> Warning:(104, 20) java: unchecked conversion
>   required: java.util.HashSet<java.lang.Long>[]
>   found:    java.util.HashSet[]
> 
> -- 
> Roedy Green Canadian Mind Products http://mindprod.com
> The standard definition of AI is that which we don't understand.
> ~ Bill Joy (born:1954-11-08 age:61), co-inventor of Java.

[toc] | [prev] | [next] | [standalone]

#33895

On 2/28/2016 2:44 AM, Roedy Green wrote:
> I am not trying to arrange the HashSet fields in order in an array. I
> am just trying to do something like this:
>
>           private final HashSet<Long>[] hashSets;

>          hashSets = new HashSet[ filesToProcess.length ];

> I get this error message:
>
> Warning:(104, 20) java: unchecked conversion
>    required: java.util.HashSet<java.lang.Long>[]
>    found:    java.util.HashSet[]

hashSets = new HashSet<Long>[ filesToProcess.length ]

should fix that.

Arne

[toc] | [prev] | [next] | [standalone]

#33896

On 2/28/2016 8:38 AM, Arne Vajhøj wrote:
> On 2/28/2016 2:44 AM, Roedy Green wrote:
>> I am not trying to arrange the HashSet fields in order in an array. I
>> am just trying to do something like this:
>>
>>           private final HashSet<Long>[] hashSets;
>
>>          hashSets = new HashSet[ filesToProcess.length ];
>
>> I get this error message:
>>
>> Warning:(104, 20) java: unchecked conversion
>>    required: java.util.HashSet<java.lang.Long>[]
>>    found:    java.util.HashSet[]
>
> hashSets = new HashSet<Long>[ filesToProcess.length ]
>
> should fix that.

     ... for suitable values of "fix."

     JLS 15.10.1, Array Creation Expressions: "It is a compile-time
error if the ClassOrInterfaceType does not denote a reifiable type."

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#33897

On 2/28/2016 8:56 AM, Eric Sosman wrote:
> On 2/28/2016 8:38 AM, Arne Vajhøj wrote:
>> On 2/28/2016 2:44 AM, Roedy Green wrote:
>>> I am not trying to arrange the HashSet fields in order in an array. I
>>> am just trying to do something like this:
>>>
>>>           private final HashSet<Long>[] hashSets;
>>
>>>          hashSets = new HashSet[ filesToProcess.length ];
>>
>>> I get this error message:
>>>
>>> Warning:(104, 20) java: unchecked conversion
>>>    required: java.util.HashSet<java.lang.Long>[]
>>>    found:    java.util.HashSet[]
>>
>> hashSets = new HashSet<Long>[ filesToProcess.length ]
>>
>> should fix that.
>
>      ... for suitable values of "fix."
>
>      JLS 15.10.1, Array Creation Expressions: "It is a compile-time
> error if the ClassOrInterfaceType does not denote a reifiable type."

Ooops.

You are right.

That does not work.

One of the ugly cast and suppress solutions are necessary.

Arne

[toc] | [prev] | [next] | [standalone]

#33898

On 2/28/2016 12:47 PM, Arne Vajhøj wrote:
> On 2/28/2016 8:56 AM, Eric Sosman wrote:
>> On 2/28/2016 8:38 AM, Arne Vajhøj wrote:
>>> On 2/28/2016 2:44 AM, Roedy Green wrote:
>>>> I am not trying to arrange the HashSet fields in order in an array. I
>>>> am just trying to do something like this:
>>>>
>>>>           private final HashSet<Long>[] hashSets;
>>>
>>>>          hashSets = new HashSet[ filesToProcess.length ];
>>>
>>>> I get this error message:
>>>>
>>>> Warning:(104, 20) java: unchecked conversion
>>>>    required: java.util.HashSet<java.lang.Long>[]
>>>>    found:    java.util.HashSet[]
>>>
>>> hashSets = new HashSet<Long>[ filesToProcess.length ]
>>>
>>> should fix that.
>>
>>      ... for suitable values of "fix."
>>
>>      JLS 15.10.1, Array Creation Expressions: "It is a compile-time
>> error if the ClassOrInterfaceType does not denote a reifiable type."
>
> Ooops.
>
> You are right.
>
> That does not work.

     Alas, no.  A continuing and damnable annoyance.

> One of the ugly cast and suppress solutions are necessary.

     Lew's dodge using a variadic function is nice.  Nicer than
casts, anyhow, because it retains type safety.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#33899

Am 28.02.2016 19:27, schrieb Eric Sosman:
[snip]
>
>      Lew's dodge using a variadic function is nice.  Nicer than
> casts, anyhow, because it retains type safety.
>
Well, not really. Java cannot guarantee the type safety, because arrays 
are covariant. Which is why parameterized (non-reified) types are 
forbidden by the compiler, and tricking the compiler as with Lew's 
function is a hack, not a solution (there is none).

What I mean is, you can of course still do the following and bypass the 
array store check:

     HashSet<String>[] ahashers = makeArray(new HashSet<>(), new 
HashSet<>());

     HashSet<Long> longs = new HashSet<Long>();
     longs.add(5L);

     Object[] objectArray = ahashers;
     objectArray[0] = longs;

     ahashers[0].add("x");
     for (Object ahash : ahashers) {
         System.out.println(ahash);
     }

     private static <T> T[] makeArray(T... items) {
         return items;
     }

So I'd say Roedy is right: Clearly it is the intent of the Java compiler 
to forbid creation of generic arrays the component type of which is a 
parameterized type. Which includes HashSet<Long>. Ironically, the reason 
why it wants to forbid that is also the reason why it must fail in the 
attempt...

I guess reified generic types are high on everybody's wish list.

-- Sebastian

[toc] | [prev] | [next] | [standalone]

#33901

On 2/28/2016 5:53 PM, Sebastian wrote:
> I guess reified generic types are high on everybody's wish list.

That and a time-machine so we can go 20 years back and get it in
version 1.0.

Else it is too late. There were too much existing code in 2004. There
is a lot more in 2016.

Arne

[toc] | [prev] | [next] | [standalone]

#33903

In article <nb09ln$1e4b$1@gioia.aioe.org>,
 Arne Vajhøj <arne@vajhoej.dk> wrote:

> On 2/28/2016 5:53 PM, Sebastian wrote:
> > I guess reified generic types are high on everybody's wish list.
> 
> That and a time-machine so we can go 20 years back and get it in
> version 1.0.
> 
> Else it is too late. There were too much existing code in 2004. There
> is a lot more in 2016.
> 
> Arne

I figure eventually there's going to be a compiler version annotation on 
every class to save Java from its legacy burden.

@Compiler(language="java", version=12)


My new job uses Java 8 and I have mixed feelings.  Lambdas are more 
efficient than anonymous classes but the syntax is completely FUBAR.  
Multiple method signatures + Generics + functional interfaces results in 
more compilation permutations than the compiler is willing to guess.  
Last time I checked, it was giving up after trying about 10.  Half the 
methods in the stream package don't compile reliably for Maps.  Imagine 
something more complicated producing hundreds or thousands of possible 
permutations and having more than one possible solution.


C++ had to kill off some old features that brought its evolution to a 
temporary halt.  Java must do the same or die.

-- 
I will not see posts from astraweb, theremailer, dizum, or google
because they host Usenet flooders.

[toc] | [prev] | [next] | [standalone]

#34580

On Sun, 28 Feb 2016 23:36:41 -0800, Kevin McMurtrie
<mcmurtrie@pixelmemory.us> wrote:

> Lambdas are more 
>efficient than anonymous classes but the syntax is completely FUBAR

I would expect a sense of aesthetics, lambda notation would be
modified to look more like existing Java syntax.

Generics had the same problem.
 
One problem is Java wants very much to avoid new keywords. So they
reuse old ones for purposes quite different from their original
meaning, e.g import static, extends in generics.

[toc] | [prev] | [next] | [standalone]

#33905

Sebastian <news@seyweiler.dyndns.org> wrote:
> So I'd say Roedy is right: Clearly it is the intent of the Java compiler 
> to forbid creation of generic arrays the component type of which is a 
> parameterized type. Which includes HashSet<Long>. Ironically, the reason 
> why it wants to forbid that is also the reason why it must fail in the 
> attempt...
> I guess reified generic types are high on everybody's wish list.

The problem with non-reifiable arrays is, that arrays can be casted
to arrays of superclass types and this thwarts all control over what
exactly can get written into an array.

I think there is a loophole that some future version of Java could
in principle use to further avoid reifiable generics...

A *future* version of Java could allow non-reifiable arrays,
but would need to warn against their casting to other array-
types, like:
  Set<Long>[] arrOfSets = new Set<Long>[1]; // fine
  arrOfSets[0] = new HashSet<Long>();
  for( HashSet<Long> item : arrOfSets ) { ... } // fine, too
  // but:
  Object[] arrOfObj = arrOfSets; // <-- some generics-warning here!

I think, as long as such an array would be referenced only by its exact
type, then there would be no way of misuse. It's only when an array is
casted, that all generics-inferred guarantees are necessarily off.

[toc] | [prev] | [next] | [standalone]

#33906

Some correction applied inline...

Andreas Leitgeb <avl@logic.at> wrote:
> Sebastian <news@seyweiler.dyndns.org> wrote:
>> So I'd say Roedy is right: Clearly it is the intent of the Java compiler 
>> to forbid creation of generic arrays the component type of which is a 
>> parameterized type. Which includes HashSet<Long>. Ironically, the reason 
>> why it wants to forbid that is also the reason why it must fail in the 
>> attempt...
>> I guess reified generic types are high on everybody's wish list.
>
> The problem with non-reifiable arrays is, that arrays can be casted
> to arrays of superclass types and this thwarts all control over what
> exactly can get written into an array.
>
> I think there is a loophole that some future version of Java could
> in principle use to further avoid reifiable generics...
>
> A *future* version of Java could allow non-reifiable arrays,
> but would need to warn against their casting to other array-
> types, like:
>   Set<Long>[] arrOfSets = new Set<Long>[1]; // fine
>   arrOfSets[0] = new HashSet<Long>();
>   for( HashSet<Long> item : arrOfSets ) { ... } // fine, too

That should have been:
    for( Set<Long> item : arrOfSets ) { ... } // fine, too
of course. sorry, for confusion.

>   // but:
>   Object[] arrOfObj = arrOfSets; // <-- some generics-warning here!
>
> I think, as long as such an array would be referenced only by its exact
> type, then there would be no way of misuse. It's only when an array is
> casted, that all generics-inferred guarantees are necessarily off.
>

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web