Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (475)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (530)
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] 5 6 ... 10
  ignore  |  Print  
  Things you disagree with in the java language  (Read 37841 times)
0 Members and 1 Guest are viewing this topic.
Offline Roquen
« Reply #90 - Posted 2012-09-04 17:02:09 »

none of this makes a squat of difference to whether you can produce good code in language X.
But it can make a huge difference in the amount of time you spend creating it...or led to choosing to use language Y instead of X.
Offline princec

JGO Kernel


Medals: 339
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #91 - Posted 2012-09-04 19:54:13 »

The features in Java that are as they are tend to lead it towards being bashed by individuals with an agenda, balanced by increasing praise as the number of programmers in a group* increases.

Cas Smiley

* what is the collective noun of programmers? A mess? A business? A bag? An arraylist? (ho ho)

Offline sproingie

JGO Kernel


Medals: 201



« Reply #92 - Posted 2012-09-04 20:10:18 »

* what is the collective noun of programmers? A mess? A business? A bag? An arraylist? (ho ho)

Redundant Array of Inexpensive Developers
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Online delt0r

JGO Knight


Medals: 26
Exp: 18 years


Computers can do that?


« Reply #93 - Posted 2012-09-04 21:54:38 »

Given that Java started at Sun.......

I have no special talents. I am only passionately curious.--Albert Einstein
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11


Game Engineer


« Reply #94 - Posted 2012-09-04 22:00:09 »

It would be nice to simply be able to lot of things in more of a shorthand way. Writing getters and setters is a bit of a pain, and it's nice in languages like Objective-C where you simply define a variable as a "property" and then you've got your getter/setter created and it can be treated with dot syntax as if it were a public variable. Long sentence. But it is a pain sometimes how much I need to explicitly write out.

I really despise using Javascript, but I have to say it's pretty amazing to just say myObj.whateverTheHell = whateverTheHellElse. Whenever I want. Anywhere. So easy, so fast. But obviously extremely error prone.

And I can't even count the number of ways that Java is better than C++. Seriously. So. Much. Better. Working in C++ makes me feel like I'm going to have to program on a punch card next and feed it into the DVD drive. It's just so old and backwards.

Java's biggest problems are also in many cases its biggest strength - extreme verbosity in variable and method names means a lot of typing but also means self-documenting code; extreme restrictiveness on what you can do means being forced to code a certain way but also means being forced to code a certain way... etc.

Stuff like operator overloading is great, but is so often abused I tend to avoid it. I know exactly what list.add() means, but list + x is not immediately clear. And if you've ever used Unreal Engine, you'll know why operator overloading can go so very wrong. Although I think they have improved this since.

See my work:
OTC Software
Offline kaffiene
« Reply #95 - Posted 2012-09-04 22:59:24 »

My favourite feature of Javascript is array literals, object literals and JSON.  Being able to make an ad-hoc tuple is very handy - and Java could easily implement that with a hashmap (but again, it's the syntactic sugar that makes it work as others have mentioned).
Offline kaffiene
« Reply #96 - Posted 2012-09-04 23:00:30 »

The features in Java that are as they are tend to lead it towards being bashed by individuals with an agenda, balanced by increasing praise as the number of programmers in a group* increases.

Cas Smiley

* what is the collective noun of programmers? A mess? A business? A bag? An arraylist? (ho ho)

Hehe.  A Chaos of programmers?  An Anarchy of coders?
Offline kaffiene
« Reply #97 - Posted 2012-09-04 23:07:03 »

none of this makes a squat of difference to whether you can produce good code in language X.
But it can make a huge difference in the amount of time you spend creating it...or led to choosing to use language Y instead of X.

Yes, obviously I can't claim that *all* syntactic sugar makes no difference otherwise I'd have to be advocating direct machine or byte code programming by reducto ad adsurdum.  And I'm NOT claiming that!!  I'm just saying that people seem to pick on one feature and say "that's one's non-negotiable!".  When you see people say they can't use Java because of Operator Overloading and others say that they couldn't use Java if it DID have operator overloading, you know really that this is just hyperbole: one of these view points might get frustrated but they could both produce code in Java just fine.

I really don't like the C# handles properties with the get/set thing in one place but that hasn't stopped me using it productively on occasion.  That's really my point - yes the body of features is important but people overstate the importance of individual features.  That's all.
Online pjt33
« Reply #98 - Posted 2012-09-04 23:55:07 »

You know, most of these things brought up in this thread are pretty unimportant IMO.  I would imagine most of us have used languages with or without operator overloading, lambdas, various kinds of generics, properties vs getters/setters and none of this makes a squat of difference to whether you can produce good code in language X.

<snip /> For me, the best reason to use Java is that mistakes fail early and verbosely.  When I f**k up, it tells me where and why rather than failing silently like Javascript or crashing the machine like C++. <snip />
I'm not sure that you're being entirely consistent. Generics introduce a whole new class of mistakes which fail early and verbosely rather than by throwing an exception at runtime. AFAIC that makes it easier to produce good code.
Offline appel

JGO Wizard


Medals: 49
Projects: 4


I always win!


« Reply #99 - Posted 2012-09-05 02:48:12 »

Disagree?

I have my idea what could be done to improve Java, but what I disagree with in the Java language?

After thinking about something to whine about, I thought of this:
What I find most ridiculous is that you have Integer, Float, Double, Long, Double, Char, Byte, and even String objects for their respective primitive types. Couldn't they make up their mind? Then they added the auto-boxing feature... great, yet another hidden overhead to their laziness.

Then those objects are "special", you can't pass them around into methods as regular objects, because they are treated as primitives.

And then I see lots of guys using the object primitives instead of the primitives themselves in their code. It's horror seeing people jump from using primitives and object primitives in the same class. Maybe they don't have a choice because there's some library they're using that relies on everything being objects. Well... it's crazy language design that creates this mess.

They should kill off the objects, turn them into non-instanciable classes with static helper methods. We'll all be better off. And why can't I do:
myIntObj.add(anotherIntObj) Huh

Stupid.

Check out the 4K competition @ www.java4k.com
Check out GAMADU (my own site) @ http://gamadu.com/
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline ReBirth
« Reply #100 - Posted 2012-09-05 02:52:52 »

Object primitives? only use their static parse methods. Grin

Offline Damocles
« Reply #101 - Posted 2012-09-05 08:59:34 »

I dont like that bytes are signed.

For what purpose does anyone need a signed byte?
Its a pain and source of errors when doing byte-based operations and networking.

Offline kaffiene
« Reply #102 - Posted 2012-09-05 10:26:21 »

You know, most of these things brought up in this thread are pretty unimportant IMO.  I would imagine most of us have used languages with or without operator overloading, lambdas, various kinds of generics, properties vs getters/setters and none of this makes a squat of difference to whether you can produce good code in language X.

<snip /> For me, the best reason to use Java is that mistakes fail early and verbosely.  When I f**k up, it tells me where and why rather than failing silently like Javascript or crashing the machine like C++. <snip />
I'm not sure that you're being entirely consistent. Generics introduce a whole new class of mistakes which fail early and verbosely rather than by throwing an exception at runtime. AFAIC that makes it easier to produce good code.

Generics solves a problem I've never had: I've never had a collection and wondered what I'd put in it.  I use generics because it's there and it saves me some casts but I wasn't especially worried about those in the first instance.  I come from a C/C++ background, so casts don't seem like the end of the world to me.

Every error that generics catch for me at compile time, I would have seen pretty much immediately with a NPE.  Yes, catching errors earlier is better.  Do I think the language needed a new feature to make a NPE into a compile time error?  Meh.  I don't really care either way.
Offline princec

JGO Kernel


Medals: 339
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #103 - Posted 2012-09-05 11:00:29 »

They have other uses too I expect but I do find that generics save me a lot of ugly cruft when actually using Collections (and Comparators, for that matter). They're also nice for covariant return types. The icing on the cake is the new <> syntax which removes all the verbosity from them as well. Win!

wrt. Integer, Float, etc - they actually do behave similarly to primitives in some ways. The number 1 is the number 1; you cannot change its value to 2 such that 1 == 2, which is what it would mean if you could do one.add(one); - this is why they are immutable. They are also very important as keys in the Map interface, which requires that keys are immutable, and very important in sorted collections as well. There's a whole load of reasons they are designed as they are and once this is fully, completely understood along with the other requirements in Java such as its need to be able to get "close to the metal" when required you also realise why there are separate things called primitives as well - it's what the computer manipulates in a raw form. Etc.

Cas Smiley

Offline gimbal

JGO Knight


Medals: 25



« Reply #104 - Posted 2012-09-05 18:13:18 »

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?

Bit late, but of course that is phantom code. But business requirements + tight budgets tend to lead to code that is not "perfect". As an example: you might just be mapping to some sort of data format of a partner, not something you design yourself...

And on top of that: conventions in APIs like JPA.
Offline i30817

Junior Member





« Reply #105 - Posted 2012-09-06 02:01:16 »

Thought of another.
If doing the language now, i think that the new type inference in generics should be the default.
new ArrayList<>() would be new ArrayList(), and if you want a subclass from the left-value declare the type argument. <> goes away.

Probably wouldn't be accepted because it's not explicit.
Offline princec

JGO Kernel


Medals: 339
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #106 - Posted 2012-09-06 02:43:16 »

Thinking about it there is no sane reason why that isn't already the case. But it's 2am and I wouldn't know a sane reason if it came and bit me on the arse.

Cas Smiley

Offline sproingie

JGO Kernel


Medals: 201



« Reply #107 - Posted 2012-09-06 04:10:27 »

Why not just use type inference for real?  Here's how you do a list of strings in Scala:

1  
val x = List("foo", "bar", "baz")

Offline Best Username Ever

Junior Member





« Reply #108 - Posted 2012-09-06 04:48:30 »

Interesting idea. I assume you're referring to this? The main reason is backwards compatibility. I think you would no longer get unchecked type warnings in some cases because you could not tell if something were legacy code or code using the new semantics.

That's actually a decent proposal. I like it so much better than the ones that advocate chopping off the left half of a variable declaration. I don't think people realize how annoying it would be to try to read or to have to go back and make a declaration explicit as soon as you start changing or reusing your code. Still, eliminating verbosity is a terrible argument. First, its easier to read and programmers tend to type fast. Second, autocomplete saves even more time and accomplishes the same thing. Third, Generics didn't make your code more verbose. It's one line! It made code less verbose. When I was a kid <lie>we didn't have templates or generics</lie> We had to make every function call in the form ((ClassName)object).someMethod((OtherClass)otherObject); Roll Eyes

1  
2  
3  
4  
5  
6  
7  
8  
// New original
Map<String, List<String>> anagrams = new HashMap<String, List<String>>();
// Old original (Why can't we have explicit type safety without the explicit type part??? The new original is so verbose!!!)
Map anagrams = new HashMap();
// Proposed change
Map<String, List<String>> anagrams = new HashMap<>();
// Alternative proposal (not compatible with old code)
Map<String, List<String>> anagrams = new HashMap();


The example he used isn't that great. It would be nicer to have MultiMaps. Then you can write Multimap<String, String> anagrams = new HashMultiMap<>(); And there are ways to make your code cleaner. Its more investment at the start, but it's shorter in the long run, improves readability, and makes it easier to rewrite portions of your library later. And if its not worth doing, maybe its not worth making a language extension. (Although I like that main part of the proposal, even if the alternatives aren't great and his reasoning comes from the wrong origin.)

1  
public class AnagramTable implements Map<String, Collection<String>>

Or
1  
public class AnagramTable extends HashMultiMap<String, String>


If I can find it, I'll post a link to someone's proposal to change the way substring worked because he was unhappy with the way it worked in one specific program of his and because he made a naive assumption about the way it worked.
Offline Danny02
« Reply #109 - Posted 2012-09-06 05:26:47 »

for multimaps and other stuff, zou can build them zour self or use some existing libs like googles guava
Offline Best Username Ever

Junior Member





« Reply #110 - Posted 2012-09-06 05:54:17 »

Found it

Quote
In my opinion, this implementation of substring(...) should be replaced as soon as possible. We recently spent almost one man-month of engineering time tracking down a memory leak that was related to String.substring(...).

String.substring(...) is a very commonly used method and it does not seem too clever to me to choose such a biased implementation for a "general purpose" method. I understand the advantages of simply sharing the char[] and just using a different offset and length. It is fast, and, if both the original string and the extracted substring are supposed to be kept in memory anyway, it is actually also very memory efficient (getting rid of the duplication). However, if the original string is no longer of interest once the substring has been extracted the current implementation causes a memory leakage nightmare extraordinaire.

In our case, the original strings happened to be Java source files (megabytes and megabytes of them), and the extracted substring was the @author tag in the class's javadoc (a few characters only). Instead of just keeping a couple kilobytes of author names in memory the complete set of source files never got garbage-collected and was kept forever. This memory leak cost a lot of time and money to track down.

My main criticism is that we are dealing with a general purpose method whose implementation is optimized towards a certain use case (i.e. both strings are supposed to be kept in memory anyway, or at least the substrings are not significantly smaller than the original strings). I find that such a bias is not acceptable for such a common method.
It also makes me wonder how this implementation choice can be reconciled with Java's general philosophy of simplicity and ease of use. Generally, Java makes it hard for you "to shoot yourself in the foot", but here it seems to offer a pre-loaded pump gun that already points straight to your big toe.

I am aware of the performance implications if such a frequently used method is suddenly replaced with a potentially much slower implementation, but still I'd recommend to get rid of the shared char[] as soon as possible. I wonder how many Java-newbies cause huge memory leaks every day by using String.substring().

If there is a strong opposition against getting rid of the shared char[], maybe there is some clever way solving this with weak/soft references? That might be a good alternative (if it's feasible). Or the algorithm could decide based on the length ratio between original string and substring whether a shared char[] should be used or not (thus hopefully achieving a more balanced memory usage profile).

Did anyone else experience costly memory leaks due to this bug?

So... not to be arrogant, but this is why most suggestions to "fix" the Java language horrify me. I know it's not written in bold in the Java doc, so it's almost a reasonable mistake to make, but the error is in assuming anything when it's reasonable to imagine it implemented either way. If it's not stated whether or not a standard String implements one technique or another, it should be considered undefined. Assuming his organization wasn't cutting corners and it just slipped everyone's mind, then I wonder why it wasn't caught the first hour using debugging or profiling. Extracting the @auther tag is something that could be assigned for homework in an introductory Java class.

Consider what he did. 1) Open a file. 2) Read its entire contents into a byte array. 3) Construct a String containing a copy of that array. 4) Presumably use indexOf and substring to isolate the information he wants. 5) Store lots of duplicate Strings long term without interning them... Then consider the alternative. 1) Open a file. 2) Stream it using StreamTokenizer. 3) Close the file early if the author tag is found or omitted.

Given that his team could not find the problem, made some poor design decisions, and spent more time trying to fix problematic code than they would have taken to rewrite it, I assume we are not hearing from an expert. Not that that is a problem or that the documentation shouldn't include a warning, but I'm glad no one took advice from someone saying "This is how I assumed it would work without looking at documentation, thinking about how I would design a String class, looking under the hood, or thinking about the implications of using one method or the other. I don't know what the benefits of the current method are, but I have anecdotal evidence of one specific use case where ignoring the possibility of a problem eventually lead to a problem that was more expensive to track down after the fact than it would have been to do right the first time." Stare Heh. "Engineering." I wonder what they thought the copy constructor of String was for?
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 742
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #111 - Posted 2012-09-06 06:31:28 »

I think it's sad that that proposal (or one along those lines) actually made it, was accepted, implemented and ready to be released.

That new implementation of String will be one of Java7's updates, and I'm sure some applications will see their memory usage explode: this time not from the memory leaks but from the duplications.

I for one have such an application / webservice that makes heavy use of the shared char[] to cut down RAM usage by over factor 20, and with the upcoming JRE I can either choose not to upgrade, or create my own String class, refactoring basically the entire application, creating a mess, and who's going to pay that? So not updating the JRE it is, then...

I'm feeling all dirty that my app will be broken by a minor update. Emo

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline kaffiene
« Reply #112 - Posted 2012-09-06 06:36:01 »

Why not just use type inference for real?  Here's how you do a list of strings in Scala:

1  
val x = List("foo", "bar", "baz")



Yeah, I love the idea of type inference. 

I also like the idea of using a C++ style initialiser - we used to have:

ArrayList<ArrayList<Vector3f>> paths = new ArrayList<ArrayList<Vector3f>>();

which has been shortened to :

ArrayList<ArrayList<Vector3f>> paths = new ArrayList<>();

But I'd much rather have:

ArrayList<ArrayList<Vector3f>> paths();   

...we already know the type, so why repeat ourselves?

Offline Advo

Junior Newbie





« Reply #113 - Posted 2012-09-06 07:42:48 »

@OP I really see no problem with var args, they are convenient in some select situations.

Only things that really irk me with java currently are:
We need better a better alternative JNI.
Additionally, some of the java classes such as the one's involved with screen capturing are horribly slow (pretty sure, havn't looked into it in awhile).

I actually like how Getters/Setters are handled in C# (Properties). Way more elegant and intuitive.
Agreed.
Offline kaffiene
« Reply #114 - Posted 2012-09-06 09:49:30 »

@OP I really see no problem with var args, they are convenient in some select situations.

Only things that really irk me with java currently are:
We need better a better alternative JNI.
Additionally, some of the java classes such as the one's involved with screen capturing are horribly slow (pretty sure, havn't looked into it in awhile).

I actually like how Getters/Setters are handled in C# (Properties). Way more elegant and intuitive.
Agreed.

I'm also happy with varargs as they are.

Did you realise that there are various alternatives to JNI?  JNA is a popular one.
Offline Roquen
« Reply #115 - Posted 2012-09-06 10:27:26 »

I've never looked at JNA...if it's just a wrapper for JNI, then it doesn't address the real problem.  Don't get me wrong, cleaner is good...but the cost of going across the boundary is the problem.
Offline princec

JGO Kernel


Medals: 339
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #116 - Posted 2012-09-06 10:45:48 »

Yeah... but when you look at how the JVM is specced you realise that the JNI APIs are the way they are for a reason. Some C++ helper wrappers around JNI make would just make things more manageable. I think I did see such a thing maybe 10 years ago.

Cas Smiley

Offline Oskuro

JGO Knight


Medals: 39
Exp: 6 years


Coding in Style


« Reply #117 - Posted 2012-09-06 10:55:49 »

I tried JNA recently. It is easier to manage than JNI, but in my particular case it lacked the flexibility I needed, so I ended up back with JNI.

I'd say that's generally the trade-off. Ease of use reduces flexibility, and vice versa.

Offline Roquen
« Reply #118 - Posted 2012-09-06 11:13:37 »

@Cas: While it's true that some functions do require a heavywait boundary, the vast majority do not.  Be that as it may, they're thinking about a lightweight replacement...I'd expect it sometime after jigsaw and before structs.  Sad
Offline princec

JGO Kernel


Medals: 339
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #119 - Posted 2012-09-06 11:26:49 »

just being able to do
1  
2  
@Native(library = "somelibrary", function="someTrivialCThing")
private native void someTrivialCFunction(int a, int b, float x);

would go a long, long way to making everyone's lives that much easier. That's 50% of the OpenGL API right there. It's rather surprising this wasn't in there from the start perhaps by adding "parameters" to the native keyword but now we've got annotations it's easy to retrofit. A few more syntactic niceties to maybe allow easier marshalling of arrays and Strings in and out would also be a great boon and get about another 40% of OpenGL.

Cas Smiley

Pages: 1 2 3 [4] 5 6 ... 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.

ctomni231 (32 views)
2014-07-18 06:55:21

Zero Volt (28 views)
2014-07-17 23:47:54

danieldean (24 views)
2014-07-17 23:41:23

MustardPeter (25 views)
2014-07-16 23:30:00

Cero (40 views)
2014-07-16 00:42:17

Riven (42 views)
2014-07-14 18:02:53

OpenGLShaders (29 views)
2014-07-14 16:23:47

Riven (29 views)
2014-07-14 11:51:35

quew8 (27 views)
2014-07-13 13:57:52

SHC (63 views)
2014-07-12 17:50:04
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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!