Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (578)
games submitted by our members
Games in WIP (499)
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 4 ... 10
  ignore  |  Print  
  Things you disagree with in the java language  (Read 36270 times)
0 Members and 1 Guest are viewing this topic.
Offline nsigma
« Reply #30 - Posted 2012-08-31 17:35:17 »

@Riven - +1!

Something Roquen said earlier I think is key

... to make something reasonable fast within time and budget constraints.

Java ain't perfect, but what was delivered was pretty darn good - if you're waiting for a programming language without any annoyances you'll be waiting a long time.

Or to paraphrase Winston Churchill -

Quote
It has been said that Java is the worst form of programming language except all the others that have been tried.

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Offline sproingie
« Reply #31 - Posted 2012-08-31 18:37:09 »

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' ?

Indeed.  When it comes to java gripes, I could go on and on ... but I already have in threads past.  All noise, no signal.
Offline Oskuro

JGO Coder


Medals: 32
Exp: 6 years


Coding in Style


« Reply #32 - Posted 2012-08-31 18:47:05 »

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

Mind you, no one said that missing C++ features are easy to use or that they can't lead to disaster, and given the scope of Java, is understandable why they aren't available.

It's just things I've noticed I could do with in certain frequent situations, but it's not frequent enough, or I'd just code in C++.


Quote from: nsigma
function pointers (of a sort) are coming with lambdas in Java 8 I believe.

Sweet!

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Orangy Tang

JGO Kernel


Medals: 51
Projects: 11


Monkey for a head


« Reply #33 - Posted 2012-08-31 19:07:25 »

Mind you, no one said that missing C++ features are easy to use or that they can't lead to disaster, and given the scope of Java, is understandable why they aren't available.

It's just things I've noticed I could do with in certain frequent situations, but it's not frequent enough, or I'd just code in C++.

Headers are not a 'feature', they're a side effect of the first C compilers being one-pass compilers and therefore requiring all functions/etc. being declared up front. Splitting code into header and source files then just becomes a convention as it's the most sane way to not duplicate declarations everywhere.

They should have been ditched ages ago, but by then they were being (ab)used for all kinds of evil so they've kind of stuck around despite being a horrible temporary hack.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline badlogicgames
« Reply #34 - Posted 2012-08-31 20:04:28 »

I only miss functions as first class citizens and a better native interface.

I'm doing a lot of C++ work at the moment, and it's incredible how compile times can make your mood super bad. I hate compile times. Any language that doesn't have that "feature" wins for me. My productivity is more important than 10% more execution speed.

http://www.badlogicgames.com - musings on Android and Java game development
Offline Oskuro

JGO Coder


Medals: 32
Exp: 6 years


Coding in Style


« Reply #35 - Posted 2012-08-31 20:07:49 »

Meh, I still like prototyping, even within the same source file. I usually manage through interfaces or abstract base classes, though. Guess it's just how I mentally organize code.

I also like templating like mad, and in C++ use namespaces like you'd use interfaces in Java (and I use interfaces in java to define constant structs like you'd use structs or enums), so it could also be that I'm mentally imbalanced.


One thing I do hate with a passion from C++ (just because I love it so much in Java) is the inability to interpret code, so you can refactor, look for references, or even decompile easily.

Offline nsigma
« Reply #36 - Posted 2012-08-31 20:12:07 »

and a better native interface.

JNA is a good stab at this (though not the only one).  Android support is there (though a bit experimental atm)!  Wink

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 605
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #37 - Posted 2012-08-31 20:18:57 »

Moved to Misc for obvious reasons

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline matheus23

JGO Wizard


Medals: 97
Projects: 3


You think about my Avatar right now!


« Reply #38 - Posted 2012-08-31 20:20:02 »

Moved to Misc for obvious reasons
Is this possible? :O Did I just see moderation? :O *donttakemeserious*

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

« In padded room »



TUER


« Reply #39 - Posted 2012-08-31 22:33:01 »

I don't like Oracle and Google, I don't want the former to kill Java with a crappy business model and I don't want to the latter to do the same by fragmenting it (imagine what will happen when Android DVM is fully supported on x86, people might have 2 Javas on desktop environments :s).

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline pjt33
« Reply #40 - Posted 2012-08-31 23:32:35 »

Wildcards in generics suck, or maybe I suck at them.
How to say this diplomatically? You suck at them.

It is possible to write overly complex types with wildcards, but when I started using C# I found the generics lacking, because I was couldn't write the complex types I could in Java.
Offline badlogicgames
« Reply #41 - Posted 2012-09-01 02:09:41 »

and a better native interface.

JNA is a good stab at this (though not the only one).  Android support is there (though a bit experimental atm)!  Wink

JNA is nice, but as with all automagic pproaches it has quiet a few drawbacks. I want them to unf**k JNI and leverage VM internals. JNA is just a fancy wrapper around JNI as far as i am concerned. Still cool.

http://www.badlogicgames.com - musings on Android and Java game development
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #42 - Posted 2012-09-01 10:39:53 »

The CNI ("C" native interface) that they had in GCJ was a step in the right direction - a simple 1:1 mapping to arbitrary library code as I recall.

Cas Smiley

Offline Roquen
« Reply #43 - Posted 2012-09-01 12:46:27 »

JNI.  How did I forget JNI?  (die! die! die!)  Has anyone followed any of the proposed official replacements?

Another trivial thing is "abstract final".  Simplifies the language and nukes the now required uncallable constructors of static utility classes.
Offline matheus23

JGO Wizard


Medals: 97
Projects: 3


You think about my Avatar right now!


« Reply #44 - Posted 2012-09-01 14:26:02 »

Another trivial thing is "abstract final".  Simplifies the language and nukes the now required uncallable constructors of static utility classes.

Abstract final seems to be not very logical. Why not use final and a private constructor? (or only a private constructor)

See my:
    My development Blog:     | Or look at my RPG | Or simply my coding
http://matheusdev.tumblr.comRuins of Revenge  |      On Github
Offline Roquen
« Reply #45 - Posted 2012-09-01 15:48:43 »

That's what you do.  The constructor serves no purpose.  final & abstract are the only mutually exclusive root level class modifiers.
Offline matheus23

JGO Wizard


Medals: 97
Projects: 3


You think about my Avatar right now!


« Reply #46 - Posted 2012-09-01 16:11:42 »

That's what you do.  The constructor serves no purpose.  final & abstract are the only mutually exclusive root level class modifiers.
Oh... so it's really possible to make a class abstract final?

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

JGO Kernel


Medals: 322
Projects: 2
Exp: 4 years


I'm the King!


« Reply #47 - Posted 2012-09-01 21:23:57 »

Oh... so it's really possible to make a class abstract final?
... final & abstract are the only mutually exclusive root level class modifiers ...

Mutually exclusive = unable to both be true at the same time Wink

Roquen was suggesting that since it's *currently* not possible to use both abstract and final together, the Java devs *should* add that possibility for a different behavior: true uninstantiable classes. I disagree because the naming itself is weird. Using a private constructor is good enough Smiley

Offline matheus23

JGO Wizard


Medals: 97
Projects: 3


You think about my Avatar right now!


« Reply #48 - Posted 2012-09-01 21:37:22 »

Oh... so it's really possible to make a class abstract final?
... final & abstract are the only mutually exclusive root level class modifiers ...

Mutually exclusive = unable to both be true at the same time Wink

Roquen was suggesting that since it's *currently* not possible to use both abstract and final together, the Java devs *should* add that possibility for a different behavior: true uninstantiable classes. I disagree because the naming itself is weird. Using a private constructor is good enough Smiley
I agree to your disagree

See my:
    My development Blog:     | Or look at my RPG | Or simply my coding
http://matheusdev.tumblr.comRuins of Revenge  |      On Github
Offline Roquen
« Reply #49 - Posted 2012-09-01 23:05:42 »

Nah, I'm suggesting it should have been that way from the start.  As is created extra implementation work for compilers and VMs that add nothing to the language.  Changing it now would make very little sense.  abstract & final together seem weird because that choice wasn't made.  abstract = can't instantiate.  final = can't extend.  Perfectly describes static utility classes.  It's illogical to create a private constructor which is never called.
Offline ra4king

JGO Kernel


Medals: 322
Projects: 2
Exp: 4 years


I'm the King!


« Reply #50 - Posted 2012-09-02 00:12:33 »

abstract = incomplete, must extend.  final = can't extend.
FTFY Smiley

Offline Knut

Junior Newbie





« Reply #51 - Posted 2012-09-02 00:18:33 »

Operator overloading for my own classes would be nice  Smiley
Offline ra4king

JGO Kernel


Medals: 322
Projects: 2
Exp: 4 years


I'm the King!


« Reply #52 - Posted 2012-09-02 03:35:03 »

Operator overloading is one of the few things that are actually valid to argue for and possible to implement in Java.

Offline ctomni231

JGO Ninja


Medals: 71
Projects: 1
Exp: 7 years


Not a glitch. Just have a lil' pixelexia...


« Reply #53 - Posted 2012-09-02 05:00:27 »

Ew... operator overloading might be too much of a stretch. It has to be one of the most abused and misused aspects of C/C++. Java doesn't need to add that layer of confusion to its process.  Tongue [/offtopic]

Though having pointer access for primitives is something I miss from C/C++.

Offline sproingie
« Reply #54 - Posted 2012-09-02 05:07:01 »

Implementing operator overloading is certainly not a hard problem in general, no.  But as it stands now, operators are not method calls, so there's likely to be more compatibility issues doing it than are immediately obvious.  Still, I think the main objection to operator overloading is, shall we say, theological rather than technical.


Offline Best Username Ever

Junior Member





« Reply #55 - Posted 2012-09-02 05:59:31 »

What about all the junk objects that would create? '+' for concatenation for things like Lists would make perfect sense, but arithmetic operators would be scary. a = a + 1 + 1 + 2 + 3 + 1 + 2 + 3 + 0; could not be optimized without also expanding/replacing the type system. You could not reduce the number of new objects created, you could not simplify expressions, you could not rearrange the order of operations on objects, and you would have to make a lot of method calls. It would be relatively simple to provide that feature as syntax sugar, but readability would be scary.

c = a + b; would look nicer than SomeObject.add(a, b, c);, but only on the surface. It could mean anything depending on the type of a and b at compile time and their types at run time. Then you would have to jump around between source files to decipher meaning from human-unreadable code. Jumping around that much just to get some information from another person's code that could have been written using a more consistent and fairly self documenting language is dizzying and takes time away from real programming. That's why C++ is so hazardous to your health, as well as any other language with an include directive.
Offline ra4king

JGO Kernel


Medals: 322
Projects: 2
Exp: 4 years


I'm the King!


« Reply #56 - Posted 2012-09-02 07:02:02 »

Still, I think the main objection to operator overloading is, shall we say, theological rather than technical.
Operaters are my Gods and Overloading is my religion! How dare you insult His greatness and power! Grin

What about all the junk objects that would create? '+' for concatenation for things like Lists would make perfect sense, but arithmetic operators would be scary. a = a + 1 + 1 + 2 + 3 + 1 + 2 + 3 + 0; could not be optimized without also expanding/replacing the type system. You could not reduce the number of new objects created, you could not simplify expressions, you could not rearrange the order of operations on objects, and you would have to make a lot of method calls. It would be relatively simple to provide that feature as syntax sugar, but readability would be scary.

c = a + b; would look nicer than SomeObject.add(a, b, c);, but only on the surface. It could mean anything depending on the type of a and b at compile time and their types at run time. Then you would have to jump around between source files to decipher meaning from human-unreadable code. Jumping around that much just to get some information from another person's code that could have been written using a more consistent and fairly self documenting language is dizzying and takes time away from real programming. That's why C++ is so hazardous to your health, as well as any other language with an include directive.
Well if you know the types of 'a', 'b', and 'c', it would be easy to decipher what a '+' would mean regarding their types and the outcome. It's just like calling the 'add' method, but less verbose.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
public class Vector {
   ...
   public Vector add+(Vector other) {
      return new Vector(x + other.x, y + other.y);
   }
}

...

Vector a = new Vector(5,6);
Vector b = new Vector(2,3);
Vector c = a + b;

Offline pjt33
« Reply #57 - Posted 2012-09-02 10:06:42 »

Implementing operator overloading is certainly not a hard problem in general, no.  But as it stands now, operators are not method calls, so there's likely to be more compatibility issues doing it than are immediately obvious.  Still, I think the main objection to operator overloading is, shall we say, theological rather than technical.
Actually one operator is a method call in some contexts: +. Well, actually it can be a bit more than a method call. I think the use of + for string concatenation is the compatibility reason which prevents adding operator overloading to the language now. If it had been in the language from the start, they'd have done something different for string concatenation, or even eliminated it entirely in favour of using String.format.

And I would categorise the main objection as psychological rather than theological: its essence is "We know the horrors that people will perpetrate with it".

What about all the junk objects that would create? '+' for concatenation for things like Lists would make perfect sense, but arithmetic operators would be scary. a = a + 1 + 1 + 2 + 3 + 1 + 2 + 3 + 0; could not be optimized without also expanding/replacing the type system. You could not reduce the number of new objects created, you could not simplify expressions, you could not rearrange the order of operations on objects, and you would have to make a lot of method calls. It would be relatively simple to provide that feature as syntax sugar, but readability would be scary.

c = a + b; would look nicer than SomeObject.add(a, b, c);, but only on the surface. It could mean anything depending on the type of a and b at compile time and their types at run time.
I think you're making some unwarranted assumptions about how it would be implemented. The most Java way of doing it would be a special interface which defines the methods into which the operators are translated, so c = a + b would be no harder to decipher than c = a.add(b) currently is. Having various interfaces would allow for things like varargs add operators. The technical side of things isn't the problem.
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #58 - Posted 2012-09-02 10:55:52 »

Indeed the real problem is the ability C++ operator overloading gives to programmers to practically redefine the syntax. This makes for syntax that is almost impossible to glance at and understand without all manner of crossreferencing. It gets even more hilarious when two C++ programmers start overloading the same operator in the same project to do different things. And then they bring in some libraries that do it a third way. The theological argument is actually relatively practical for a change.

Cas Smiley

Offline sproingie
« Reply #59 - Posted 2012-09-02 18:05:18 »

It could mean anything depending on the type of a and b at compile time and their types at run time. Then you would have to jump around between source files to decipher meaning from human-unreadable code.

I have heard this exact argument numerous times, verbatim, in opposition to Object-Oriented Programming.
Pages: 1 [2] 3 4 ... 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.

xsi3rr4x (27 views)
2014-04-15 18:08:23

BurntPizza (24 views)
2014-04-15 03:46:01

UprightPath (38 views)
2014-04-14 17:39:50

UprightPath (21 views)
2014-04-14 17:35:47

Porlus (36 views)
2014-04-14 15:48:38

tom_mai78101 (61 views)
2014-04-10 04:04:31

BurntPizza (119 views)
2014-04-08 23:06:04

tom_mai78101 (219 views)
2014-04-05 13:34:39

trollwarrior1 (186 views)
2014-04-04 12:06:45

CJLetsGame (193 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
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!