Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (499)
Games in Android Showcase (118)
games submitted by our members
Games in WIP (568)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2 3 ... 10
  ignore  |  Print  
  Things you disagree with in the java language  (Read 39990 times)
0 Members and 1 Guest are viewing this topic.
Offline i30817

Junior Member





« Posted 2012-08-30 20:58:23 »

I was just thinking of this, because of a design decision i find to be absolutely wrongheaded;

I tried to use varargs, because i really really want to make my functions take one or many without having to deal with converting to a list on the case of 'one', and besides i often have to convert.

So i tried varargs. Then i had the problem of 'conversion' or 'mapping' (functional lingo). And then i had the problem that as varargs uses arrays it needs to have the non-generic class type (arrays being covariant and all).

What i'd really like is that varargs created a iterable that could then be easily wrapped in another iterable that could do the mapping (with lambdas or whatever). However due to the fact that arrays are covariant and not lazy i need to pass a collection (for the size()), a class (to instantiate the array) and the factory 'lambda') and waste time and space copying.
I've reached the conclusion that varargs do more harm than good in cases where you need to transform one-or-many into the function arguments expected, and that it's better to do 'asList' on the function arguments that are not on collection form and pass a iterable.

Varargs was implemented targeting the wrong type and is almost completely useless!

Have you got any other pet issues?
Offline davedes
« Reply #1 - Posted 2012-08-30 21:20:34 »

Quote
And then i had the problem that as varargs uses arrays it needs to have the non-generic class type (arrays being covariant and all).
You can use generics:

1  
2  
3  
4  
5  
   public static <T extends Component> void foo(T ... args) {
      for (T comp : args) {
         comp.invalidate()
      }
   }


I don't see how asList is any better... Why do you need collections and size() when you can just use args.length? Maybe you could explain your issue with some code samples?

Funny enough, the asList method is a perfect example of using varargs.

Offline i30817

Junior Member





« Reply #2 - Posted 2012-08-30 21:34:56 »

Quote
And then i had the problem that as varargs uses arrays it needs to have the non-generic class type (arrays being covariant and all).
You can use generics:

1  
2  
3  
4  
5  
   public static <T extends Component> void foo(T ... args) {
      for (T comp : args) {
         comp.invalidate()
      }
   }


Try doing that with a method that takes a collection/array of generic type and returns a array of another generic type (ommit the factory function for the purpose of example). This to be used in a function that takes varargs arrays as a conversion step.

for a iterable argument...
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
    public static <E, T> Iterable<E> iterable(final Iterable<T> it, final Factory<E, T> factory) {
        return new Iterable<E>() {
            @Override
            public Iterator<E> iterator() {
                final Iterator<T> itr = it.iterator();
                return new Iterator<E>() {
                    @Override
                    public boolean hasNext() {
                        return itr.hasNext();
                    }

                    @Override
                    public E next() {
                        try {
                            return factory.create(itr.next());
                        } catch (Exception ex) {
                            throw new AssertionError("factory method shouldn't throw a exception when used in iterator", ex);
                        }
                    }

                    @Override
                    public void remove() {
                        itr.remove();
                    }
                };
            }
        };
    }


for a varargs argument...
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
    public static <E, T> E[] map(final Collection<T> it, Class<E> classE, final Factory<E, T> factory) {
        E[] out = (E[]) Array.newInstance(classE, it.size());
        int i = 0;
       
            for (T o : it) {
                try {
                  out[i++] = factory.create(o);
                } catch (Exception ex) {
                throw new AssertionError(ex);
                }
            }

        return out;
    }


See the additional class argument, narrowed collection interface, allocation, reflection and copy there? All because [] is not able to be lazy.
Varargs blow. There is nothing that they do currently that couldn't have been done better by making their runtime type be a iterable instead of a array except modification of the runtime array argument which i never do and it's filthy coding anyway (that remove() is bad too, assuming that it's only to be used for argument transformation).
It's no accident that the most used varargs method in the jdk is something that turns it into a iterable i guess ('immutable list') - especially with lambdas around the corner i'd advice to cut off varargs from your api's.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline kaffiene
« Reply #3 - Posted 2012-08-31 02:56:14 »

Sounds to me like you're hating varargs because Java isn't a functional language.  If you want lazy sequences, use Haskell.

My biggest gripe with java is that primitves shouldn't exist.  I hate the int/Integer (et al) pairing.  There's no reason why the language couldn't have had 'primitives' as objects, e.g.: 12.toString();

Given that anonymous inner classes is a common Java idiom, Lambdas would have made that better and more flexible if that had been available from the outset.

Offline ReBirth
« Reply #4 - Posted 2012-08-31 02:59:57 »

System.out.println(blalalala);

Offline gimbal

JGO Knight


Medals: 25



« Reply #5 - Posted 2012-08-31 11:52:40 »

My biggest gripe with java is that primitves shouldn't exist.  I hate the int/Integer (et al) pairing.  There's no reason why the language couldn't have had 'primitives' as objects, e.g.: 12.toString();

I don't mind primitives, it was just a nice feature to make it comfortable for C/C++ programmers to switch to Java (including myself). Its autoboxing that is the real sucker to hate. How many times have I had the following situation:

- something blows in production
- I check the log, see line 1546 of sourcefile X
- check ling 1546 of sourcefile X, it is:

1545: entity.setOrderId(modelObject.getOrderId());
1546: entity.setStatus(modelObject.getStatus()); // crash? WHY?

modelObject cannot be null because line 1545 did not produce an error, there is nothing on that line that can produce an NPE! ... Yeah, unless the status of the entity is a primitive and the status of the modelObject is an object which just happens to be null... DOH.
Offline nsigma
« Reply #6 - Posted 2012-08-31 12:03:21 »

1545: entity.setOrderId(modelObject.getOrderId());
1546: entity.setStatus(modelObject.getStatus()); // crash? WHY?

modelObject cannot be null because line 1545 did not produce an error, there is nothing on that line that can produce an NPE! ... Yeah, unless the status of the entity is a primitive and the status of the modelObject is an object which just happens to be null... DOH.


WTF?  Shocked Why would you even write that?  I'm assuming entity status is an int, in which case modelObject status is an Integer?  Why would you mix and match different representations of status at all?  And, most of the time surely an enum would be better?

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Online Roquen
« Reply #7 - Posted 2012-08-31 12:29:53 »

WRT: Using real primitives was a good choice IMHO.  From my perspective primitive wrapper classes should have come in mutable and non-mutable forms from the start.  And mutable primitives wrappers should just have 'worked' as if they were, well, primitives.  Note however, that this implies operator overloading.  I really like pure object oriented (class and prototype based) languages.  I sure they moved away from Self because it would simply been way too expensive (engineering wise) to make something reasonable fast within time and budget constraints.

A time/budget constraint thing I hate is: type erasure (die! die! die!)

Another thing I hate is per object locks.  (WTF!!!???)  Really bad idea then, horrible idea now and burdens every single object with extra (useless) memory overhead. (die! die! die!)

Minor: identity hashing.  Again burdens all object with extra bit(s) and all which have ever called identity hash to be either pinned or potential expand memory-wise to store...just an implementation pain for little usefulness.  Object's hashCode should have just thrown an exception...done.
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #8 - Posted 2012-08-31 12:37:44 »

WRT: Using real primitives was a good choice IMHO.  From my perspective primitive wrapper classes should have come in mutable and non-mutable forms from the start. 

I really wish Java had proper built-in support for defining primitives/objects as immutable or not. A bit like C++'s const but better. Immutable classes or interfaces are a nice workaround but it'd be much nicer built into the language.

I believe Scala has something like this, but haven't played around with that much.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Online princec

JGO Kernel


Medals: 391
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #9 - Posted 2012-08-31 12:45:26 »

Primitives were an excellent idea. It allows Java to get close to "the metal" when you need it to be. At the end of the day in Java you can actually write code that's fast by design explicitly rather than having to hope it's not doing something stupid under the hood. Mostly.

wrt per-object locking: I think it's a great idea. It costs 2 bits* of information for most objects, which is hidden away in the object header and thus effectively free. Only contended locks need to escalate into a bigger structure.

Cas Smiley

* I think. Someone correct me.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Online Roquen
« Reply #10 - Posted 2012-08-31 12:52:17 »

Two bits sounds correct: https://wikis.oracle.com/display/HotSpotInternals/Synchronization agrees with that.
Offline Oskuro

JGO Knight


Medals: 39
Exp: 6 years


Coding in Style


« Reply #11 - Posted 2012-08-31 13:18:21 »

I keep missing the ability to handle memory (pointers) more directly. I understand why it is limited, but miss it nonetheless.

Online Roquen
« Reply #12 - Posted 2012-08-31 13:23:39 »

Yes, lack structures and array of structures is actually a very large problem.  If we open the discussion to missing features, rather than issues with existing...my list would be longish...but that's one of the biggest IMHO.  There's tons of related items here like cache-hints and SIMD access.
Offline Cero
« Reply #13 - Posted 2012-08-31 13:24:31 »

A list of C++ things I hate would be really long.
Fact is in java, most things you dont like you can ignore.

Although I too would like to explicitly define pointers...

Offline nsigma
« Reply #14 - Posted 2012-08-31 13:27:19 »

Although I too would like to explicitly define pointers...

In what way and for what purpose?

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Online Roquen
« Reply #15 - Posted 2012-08-31 13:32:13 »

Actually very little of the things I dislike about Java are things that I can ignore.  Sadly I must sometime dismiss Java as a viable option.
Offline matheus23

JGO Kernel


Medals: 108
Projects: 3


You think about my Avatar right now!


« Reply #16 - Posted 2012-08-31 13:32:47 »

The only thing I miss as a feature in java is something like a "template"
[Edit: I hit "Tab" and "Enter"... accedently]
, as an extension to Generics. So you are able to put primitive types as generics...

So you can make an implementation of "Vec3" (Often brought by me as an example), to be able to cooperate with every "type of number".
You can now use Vec3<float> Vec3<double> and even Vec3<byte> for colors.

See my:
    My development Blog:     | Or look at my RPG | Or simply my coding
http://matheusdev.tumblr.comRuins of Revenge  |      On Github
Offline Oskuro

JGO Knight


Medals: 39
Exp: 6 years


Coding in Style


« Reply #17 - Posted 2012-08-31 13:33:25 »

I like both Java and C++, each have their positives and negatives. And of course, you could argue that through JNI you can get both... but I digress.

Another thing I often miss in Java is, oddly enough, having to define headers (data structure / function prototyes). It is a hassle, yes, but helps tremendously to reduce code bloating and disorganization as a project grows.


As for why use pointers, function pointers are something I miss a lot (Maybe I'm missing something).
I'm not too fond of the limitations on multiple inheritance and on how interfaces work either.

Offline Cero
« Reply #18 - Posted 2012-08-31 13:35:10 »

Although I too would like to explicitly define pointers...

In what way and for what purpose?

Well in what way would be the C++ way:
Object* somePointer = Something.getObject();

Why ? Well sometimes it is unclear if something hold an object alone or is just a pointer. Of course in java everything is just a pointer.

But I had cases in which I did   someObject = new Object() , not knowing that someObject was just pointing to something and that I would need to remove / recreate that, leaving me with 2 separate instances...

Good Code design can help to avoid these problems but most of the time a variable either holds an actual object/value or a pointer... in my code it doesnt happen that these behaviors switch...

Offline Damocles
« Reply #19 - Posted 2012-08-31 13:35:21 »

I miss goto.

Offline Cero
« Reply #20 - Posted 2012-08-31 13:36:36 »

Quote
function prototyes

Yes, it should exist optionally.

Offline matheus23

JGO Kernel


Medals: 108
Projects: 3


You think about my Avatar right now!


« Reply #21 - Posted 2012-08-31 13:37:16 »

Are you kiddin? 4 posts while I'm editing???

See my:
    My development Blog:     | Or look at my RPG | Or simply my coding
http://matheusdev.tumblr.comRuins of Revenge  |      On Github
Online princec

JGO Kernel


Medals: 391
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #22 - Posted 2012-08-31 13:38:05 »

Headers and pointers are the two biggest mistakes in C++ and the two things Java got most right, IMHO.

Cas Smiley

Online Roquen
« Reply #23 - Posted 2012-08-31 13:40:27 »

@matheus23: hygienic macros would be nice.
@damocles:  you have gotos..just not unstructured gotos.
@Oskuro:  fake mixins by composition.

Every class is bound by a single source file is a good thing for Java.

PS:  Give my time to type you heathens!
Offline nsigma
« Reply #24 - Posted 2012-08-31 13:44:46 »

@Cero - no, sorry, still don't understand what you feel is missing there.  It sounds a little like you want pointer to pointer, but maybe I'm not getting what you mean?
@Oskuro - function pointers (of a sort) are coming with lambdas in Java 8 I believe.

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Offline Cero
« Reply #25 - Posted 2012-08-31 13:48:09 »

@Cero - no, sorry, still don't understand what you feel is missing there.  It sounds a little like you want pointer to pointer, but maybe I'm not getting what you mean?
@Oskuro - function pointers (of a sort) are coming with lambdas in Java 8 I believe.

I'm sure you have coded in C++, an asterisk means something is a pointer.
Without looking at more code, I would like to know if a variable is a pointer or holds data itself... Of course, like I said this notion doesn't even exist in Java since everything is a pointer.

Online princec

JGO Kernel


Medals: 391
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #26 - Posted 2012-08-31 14:15:55 »

The same confusion that applies to people with C and pointers also applies to compilers, preventing or making very difficult a whole load of optimisations.

Cas Smiley

Offline nsigma
« Reply #27 - Posted 2012-08-31 14:59:52 »

I'm sure you have coded in C++, an asterisk means something is a pointer.

Yes.

Without looking at more code, I would like to know if a variable is a pointer or holds data itself... Of course, like I said this notion doesn't even exist in Java since everything is a pointer.

Exactly (well, unless they're primitives) - all variables are pointers unless they're a primitive.  What I don't understand is what you feel is actually missing here? 

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Offline Don Kiddick

Junior Member





« Reply #28 - Posted 2012-08-31 15:12:30 »

The rubbish choices for default access modifiers. Fields should default to private, methods to public.

The general verbosity of java sucks, e.g. when dealing with classes with a single method, e.g. ActionListeners, Runnables, Callables etc. This will hopefully get better in Java 8 with lambdas.

Wildcards in generics suck, or maybe I suck at them.

Some of the APIs suck, like Date/Calendar, URL/URI and the decision to bundle so much stuff in the standard distribution (CORBA anyone?). Hopefully remediated in Jigsaw in 8 or 9.

Still Java is awesome. Going back to c++ again feels like going in a timewarp.
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 803
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #29 - Posted 2012-08-31 15:21:04 »

Have you got any other pet issues?
Threads like these, of which we have a bunch. They always end up stating the obvious and feed endless derailments over semantics nobody really cares about but everybody insists them to be phrased correctly from their own point of view. In the end everybody gets tired of the discussion, and nothing of value was added.

Why not keep a thread reasonably limited in scope, as in 'Struggling with generics in varargs' instead of 'Post any annoyance you ever had with Java' ?

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Pages: [1] 2 3 ... 10
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Pippogeek (40 views)
2014-09-24 16:13:29

Pippogeek (31 views)
2014-09-24 16:12:22

Pippogeek (21 views)
2014-09-24 16:12:06

Grunnt (47 views)
2014-09-23 14:38:19

radar3301 (29 views)
2014-09-21 23:33:17

BurntPizza (65 views)
2014-09-21 02:42:18

BurntPizza (37 views)
2014-09-21 01:30:30

moogie (43 views)
2014-09-21 00:26:15

UprightPath (53 views)
2014-09-20 20:14:06

BurntPizza (55 views)
2014-09-19 03:14:18
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!