Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (741)
Games in Android Showcase (225)
games submitted by our members
Games in WIP (823)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1] 2 3 ... 43
1  Discussions / General Discussions / Re: Move to Kotlin? on: 2017-11-16 21:18:42
For example you could share a String between annotations, which isn't possible in Java.

What makes you think you can't use String constants with annotations in Java?
2  Discussions / General Discussions / Re: Move to Kotlin? on: 2017-11-16 11:04:24
a language shouldn't need a specific IDE to be adequately grokked (it's like there's a link between Kotlin and Intellij or something!  Grin )

I beg to differ. I started to look into building some small DSL with Kotlin, and I find it incredibly helpful to get that much assistance.

That noise was the point swishing past your head!  Wink  Yes, IDE's exist to make life easier, no doubt about that.

You never had, in the computer programming history, a brand new language with a first class IDE support.

a ha ha ha ha ... hubris ... Smalltalk comes to mind for a start, had this in the 70s!

... because Jetbrains has the whole pipeline under his hands: from the IDE to the language, that's really powerful and incredible if you think about it.

So does (did) Snoracle with Java!  But having other peoples' solutions around too is a healthy thing.
3  Discussions / General Discussions / Re: Move to Kotlin? on: 2017-11-16 09:34:45
Man did I really not mention that virtual type rendering from the IDE? I should have.

@spasi did.  I personally like var / val, but I think you're missing the point others were making - a language shouldn't need a specific IDE to be adequately grokked (it's like there's a link between Kotlin and Intellij or something!  Grin )


Nice!  Does remind me of one thing I really dislike though - I hate removal of
new
4  Game Development / Newbie & Debugging Questions / Re: how to get artifacts built with Intellij IDEA to find included res directory? on: 2017-11-14 21:58:06
the path will resolve to the path where the JAR exists

Yes, but this bit is incorrect.  It will resolve to where you launch the JAR from (ie. if from terminal the pwd, not necessarily where the JAR is).  Add in the possibility of users setting up symlinks, etc. and relying on the relative path can be a bad idea.  See this old message with a bash launcher script that works around this issue (from the Linux / OSX NetBeans launcher) http://www.java-gaming.org/topics/cannot-run-a-program-by-clicking-on-its-icon-whereas-it-works-in-command-line/36811/msg/350522/view.html#msg350522


Or, as mentioned above, in your Java code you can use
1  
URL jarLocation = MyClass.class.getProtectionDomain().getCodeSource().getLocation();

see https://stackoverflow.com/questions/320542/how-to-get-the-path-of-a-running-jar-file
5  Game Development / Newbie & Debugging Questions / Re: how to get artifacts built with Intellij IDEA to find included res directory? on: 2017-11-14 09:22:02
You are passing a relative path to File so it's resolving that against the directory you're running the JAR from to get the absolute paths you posted.  This is what you're telling it to do!  What path are you expecting?

Using relative paths with a JAR is error prone unless you have a launching script (or use the getprotectiondomain().getcodesource().getlocation() workaround) - the path will be wherever you launch the JAR from, not the location of the JAR itself.

If you want to put the resources in the JAR you'll need to switch to getClass().getResource()
6  Game Development / Performance Tuning / Re: Simple way to show quickly-changing values on: 2017-11-13 17:33:17
One problem with the invokeLater() approach is you really want to coalesce all these values - there's no point in running a Runnable that's setting the text if you already have another Runnable on the queue.

An option might be to pass the strings into a concurrent queue, and drain it within your Runnable, only setting the last available String value (some Runnable will see an empty queue).

Another option, if you know the value is always changing, would be to poll from a Swing Timer.

If you have another thread you want to poll values from that are more complex (or just want to communicate with), it's also worth implementing an equivalent of invokeLater().  You can call with a Runnable that queries values and posts them back to the EDT.  Lock free and asynchronous ftw!

I'd stay away from invokeAndWait() unless you really need it - it's deadlock prone!  Notable that they didn't implement the same in JavaFX.
7  Discussions / General Discussions / Re: Move to Kotlin? on: 2017-11-12 17:01:05
But I honestly don't get why people get excited about switching on types... since when is that considered good practice? OK, sucks when you have to do it without syntactic support, but if the support is there, it's a huge magnet for novice programmers writing shitty code. Much more so than local type inference.

Because structural pattern matching is great (and a bit more than just switching on types).  We've been fooled into thinking using the type system isn't good OOP, rather than the reality that it's currently error prone (compile-time safety isn't just syntactic support) and Java just isn't very good OOP!  Wink

- Now that @princec mentioned it, I would love to see a thread about Clojure and the practical pros and cons of using it. Also, any tips on how to get used to the alien syntax?

+1.  Now interestingly in the context of what I said above (Java not good OOP), I've been looking at the history of OOP a bit recently - I've read multiple people claim that Clojure is more in line with the original idea of OOP than Java is.  Grin
8  Discussions / General Discussions / Re: Move to Kotlin? on: 2017-11-10 21:08:59
In Java, one would have to change the return type of the doSomething() method and return a wildcard type.

No, you wouldn't, you'd not create the wrong list in the first place (in your contrived example!).  Of course there are real-world examples where this feature is necessary, but they're thankfully quite rare, particularly with Streams, lambdas and better inference

eg. this works (peek is horrible, but so are side effects  Wink )

1  
2  
3  
List<SuperClass> doSomething() {
  return Stream.of(new SubClass()).peek(SubClass::subClassMethod).collect(toList());
}


Now, in the context of writing things like (reactive) stream APIs then this feature (JEP 300) would be great.
9  Discussions / General Discussions / FXGL (JavaFX Game Library) looks like it's coming along nicely on: 2017-11-10 19:42:33
I remember the author posting something a while back, but can't find any other mention of FXGL (pure JavaFX game library) on here?

Saw this video tweeted earlier -

<a href="http://www.youtube.com/v/N5cNqypBN4k?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/N5cNqypBN4k?version=3&amp;hl=en_US&amp;start=</a>

Not tried it, but the library is at https://github.com/AlmasB/FXGL
10  Discussions / General Discussions / Re: Move to Kotlin? on: 2017-11-10 19:21:23
If you never had any issues with wildcards, then all the better xD I tried to say that there are cases where you need variant collections. ... May look like an artificial example for some

I didn't say I hadn't had issues with wildcards, or didn't understand the reasoning behind adding this (hey, I'm looking forward to JEP 300  Wink ) ... but that you were providing examples of doing things that are either not a problem to implement already or don't make sense to do (including your last example).
11  Discussions / General Discussions / Re: Move to Kotlin? on: 2017-11-10 10:13:19
"Oracle is not Sun.  Oracle wouldn't have open-sourced Java."

I find that extremely easy to believe and it's part of the reason I don't like them.

I can dislike leisure-suit Larry and his yachts as much as the next person, but I'd rather have their blatant commercialism than Sun's token lip-service to open-source.  At least when Oracle does open-source it does it properly, even if it is in its own self interest (like the massive contribution to the Linux kernel, rather than Sun's licensing everything GPL incompatible so Linux can't "steal" it).  Java (and the JVM) feels in a far healthier position now than under the last few years of Sun.

And don't think that JetBrains' development of Kotlin is some sort of altruism - it's the same blatant commercialism to strengthen sales.
12  Game Development / Performance Tuning / Re: for loops on: 2017-11-10 09:56:46
There should be a good possibility the iterator is removed by escape analysis and so not be a GC concern.  Premature optimization is bad, relying on profiling to tell you what's happening can be worse - I refer you to this message from earlier this year where @spasi talks about this exact issue (and recommends JITWatch)

Of course, there's another option with collections these days -

1  
2  
3  
list.forEach(item -> {
  // do something with item
});


That uses an internal for loop.  Internal iteration has the potential to be faster than anything else.
13  Discussions / General Discussions / Re: Move to Kotlin? on: 2017-11-09 16:34:13
The good bit of news about java is that oracle is handing a lot of it over to the community, j2ee will be moving to the eclipse foundation, java (from what i understand) will be more managed by the openjdk project and the netbeans ide is moving to Apache (alpha release of the open sourced version should be released soon).

To be clear, NetBeans was pretty much always open source.  And just because it's moving to Apache, don't assume Oracle are less invested - I've heard there are more people working on NetBeans related work since the move than before.

Likewise, "handing" a lot of Java over to the community suggests they're disinvesting, and I'm not sure that's the case.  I've heard this multiple times now (paraphrased) "Oracle is not Sun.  Oracle wouldn't have open-sourced Java.  But as it is open-sourced, we're going to make the most of that".

And there are some massively good things happening to the language ...  Grin
14  Discussions / General Discussions / Re: Move to Kotlin? on: 2017-11-09 14:37:55
Can you try this with List<? super SubClass> and List<? extends SuperClass> ? Smiley

Why?  Like, seriously, provide an example of why you'd be doing that?  I do get the thoughts behind this feature, but your screed up there is either things I can't understand any reason for doing, or are an example that I just showed works fine in Java thanks very much.  Grin
15  Discussions / General Discussions / Re: Move to Kotlin? on: 2017-11-09 14:04:28
for example a method that adds a list of subclasses to a list of superclasses.

I'm sure there are good examples of this feature, but unless I'm missing something that doesn't seem like one?

1  
2  
3  
List<SubClass> subClasses = new ArrayList<>();
List<SuperClass> superClasses = new ArrayList<>();
superClassses.addAll(subClasses);
16  Java Game APIs & Engines / JavaFX / Re: Off screen rendering, drawing images onto themselves and other shenanigans on: 2017-11-09 12:27:06
There's way too much NIH with Java. Why JavaSound when there was OpenAL?

In general I sympathise with that, although JavaSound is more low level than OpenAL - PortAudio would be a better comparison - I actually believe something of the complexity of OpenAL belongs outside.  But where I think JavaSound is better than the other media examples (similar to File vs nio2) : there are two ways to approach the cross-platform thing - one is to target the lowest common denominator, the other is to provide the ability to query, access and plugin to the features of the underlying platform.  The new java.awt.desktop stuff in Java 9 is another example.

But in general, the NIH stuff is more about not exposing it than not using it, in which case I wish there would be more of a move to have the implementations outside the JDK or JavaFX eg. using service providers / modularisation.  That way the "default" implementations or the alternatives are working on a level playing field, and there's no hidden access.
17  Java Game APIs & Engines / JavaFX / Re: Off screen rendering, drawing images onto themselves and other shenanigans on: 2017-11-09 10:38:06
Yes, IMO JavaFX is a dead end.  It's still not possible to do some things you can do with Swing (don't see either Swing-based IDE upgrading!), while there's less access to low-level stuff.  The Swing-JavaFX interop is also "funky", which means evolving projects is hard - rather important to increasing use.  I think it would have been better to have an up-to-date replacement for AWT, and let the actual UI development happen outside of the JDK (not that JavaFX is really in it).

I agree with @Riven about many of the poor clientside API choices.  Inside most JavaFX builds is GStreamer, but with access to about 1% of its functionality.  As the maintainer of the Java bindings for GStreamer I find that disappointing (if fruitful!), but that you then can't hook into the JavaFX rendering in any useful way, or even easily overlay rendering in a JavaFX UI, is a real pain.

Disagree on the JavaSound API - that's the one I think is well designed (if the backends a bit crusty).  People dislike it because they don't read the docs properly!  Wink  An API that doesn't try and abstract differences across platforms, but provides the ability to query abilities, is IMO far more useful.
18  Discussions / General Discussions / Re: Move to Kotlin? on: 2017-11-08 17:38:52
Kotlin has those casts already and Something called sealed class, representing a fixed hierarchy. In whens over sealed classes, No else part is needed.

That's the plan on the Java side too.  The best thing about Kotlin is that in a year you won't have to move to Kotlin!  Grin
19  Discussions / General Discussions / Re: Move to Kotlin? on: 2017-11-08 14:13:45
That'd be a massive boon for Java. And when you think about it, it's like a best-of-both-worlds approach to my particular bugbear with casting assignments.

Yes, my first post of the link was in response to your bugbear!  Tongue

Also planned to be supported in switch - eg.

1  
2  
3  
4  
5  
6  
7  
8  
9  
String formatted;
switch (obj) {
    case Integer i: formatted = String.format("int %d", i); break;
    case Byte b:    formatted = String.format("byte %d", b); break;
    case Long l:    formatted = String.format("long %d", l); break;
    case Double d:  formatted = String.format("double %f", d); break;
    case String s:  formatted = String.format("String %s", s); break
    default:        formatted = obj.toString();
}


That examples a bit odd, but I like one of the aims (as I said before) to get rid of the damn visitor pattern.
20  Discussions / General Discussions / Re: Move to Kotlin? on: 2017-11-08 14:00:10
1  
2  
3  
MyClass a = ...;
if(a is SubClassOfMyClass)
   ((SubClassOfMyClass)a).useSubClassMethod();

This is just a small visual thing, I would really like that for Java with instanceof operator Smiley

How about ?

1  
2  
3  
if (a matches SubClassOfMyClass s) {
  s.useSubClassMethod();
}


If you read the pattern-matching link I posted earlier, that's what's on the cards, hopefully for Java (10 / 18.03) in March.
21  Discussions / General Discussions / Re: Move to Kotlin? on: 2017-11-07 23:05:09
Princec actually brings up a good point, there's 0 reason (from what I can think of right now) to declare the type of a variable and then have to retype the type when you're trying to cast. You're clearly in the camp of "less syntax", so why is what Princec said hilarious?

How about because having the same syntax for a standard assignment (which can't throw a CCE) and a casting assignment (which can throw CCE) is a daft idea? Fine make it "less syntax" but at least make it an explicit action to move type checking to runtime.

Now if var in Java supports casts you'll be able to just write the type once without duplicating syntax!  Wink
22  Discussions / General Discussions / Re: Move to Kotlin? on: 2017-11-07 19:26:12
It's never safe, and throws CCE at runtime.

You're missing the point!  Or deliberately ignoring it?  Smiley  You're proposing a syntax where something that can never throw a CCE and something that can are the same.  The pattern matching or Kotlin typecasts actually ensure at compile time that you won't get a CCE.

same about functional languages – fluffy for kids and nightmare for real projects

That made me laugh a lot!  Not only are there loads of real projects in functional programming languages, but most of the big developments in the Java space at the moment are "functional".  One of the reasons being that your 30k-50k line project starts to become something that's 5k-10k.  More succinct and readable expression of program logic is a massive aid to maintainability.
23  Discussions / General Discussions / Re: Move to Kotlin? on: 2017-11-07 18:51:11
My suggestion still has compile-time safety - the cast is just implied. If a cast is impossible the compiler's still going to barf. Can't assign a Float to a String. But in most other cases the cast is totally superfluous repetition of something that you've literally just typed a few characters earlier.

What I mean is you've made the syntax for normal assignment and an explicit casting assignment the same!  With explicit casting you at least have to tell the compiler you think you know better.  That's why I like the implicit casting in pattern matching, because it's effectively an enforced instanceof and cast.  Tighten up the compile-time checks, don't loosen them.  One of the new languages I find most interesting is Rust, and things like the borrow checker.
24  Discussions / General Discussions / Re: Move to Kotlin? on: 2017-11-07 17:48:25
The difference comes when you spend 30 years of your life maintaining some other bugger's code and only 5 years actually writing your own. That's when it becomes painfully obvious why some languages are better than others.

Yeah, usually the ones with compile-time type safety, which is one reason your suggestion above surprises me!

 ... and Americans can't spell colour ... and unfortunately after years of programming languages written in American "English", neither can I!  Wink
25  Discussions / General Discussions / Re: Move to Kotlin? on: 2017-11-07 15:35:01
What would have been much more useful to my mind was implicit casts instead:

In the context of pattern-matching, definitely!  Then we can finally get rid of the damn visitor pattern.

Outside pattern-matching, yuck!

http://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html
26  Discussions / General Discussions / Re: Move to Kotlin? on: 2017-11-07 14:14:27
@princec so I assume you don't use lambdas or explicitly type all the lambda parameters?!  Good self-documenting code also requires sensible variable and method names, so unless your example is actually equivalent to

1  
Gubbin gubbin = thing.getGubbin();


then it's badly written anyway!  Grin
27  Discussions / General Discussions / Re: Move to Kotlin? on: 2017-11-07 12:36:10
They can easily hit a 6 month cadence and just ensure that no feature is ever designed to take longer than 6 months to implement. (If it does - it needs to be broken down into releasable steps)

That's not really the plan, though!  This is worth a read - gives a good insight into why this is different to what's happened before - https://mreinhold.org/blog/forward-faster

In particular as to why it's not about features only taking 6 months to implement!

Quote
New features will be merged only when they’re nearly finished, so that the release currently in development is feature-complete at all times
28  Discussions / General Discussions / Re: Move to Kotlin? on: 2017-11-07 12:12:32
2. "Yes, we actually DO release after 6 months but none of the things we promised would make it into the release actually do, and we just have some bug fixes and small JDK library changes"
It would be the first time in the history of software development, that such a big project actually keeps their release cycle.

Yes, 2.  This is what I meant by the development model also changing.  We will just see features dropping back when not ready.  Remember there's also an LTS aspect to this.  And I can think of a few big projects that do keep their release cycles!

Ah, thats very nice Smiley So you can explain, why Netbeans isn't able (is it?) to handle multi language projects? I tried to do a project in Kotlin and Java and afterwards in Groovy and Java and neither worked. It told me there are symbols that can't be found. Pretty much the only issue I had in an IDE with Kotlin. Sadly, I can't find any info on this and the corresponding issue is ignored heavily.

I believe JetBrains themselves are responsible for the Kotlin support, so perhaps ask there?  In terms of NetBeans issues, better to file in the Apache NetBeans JIRA.  Things a bit in flux at the moment around the old NetBeans site.
29  Discussions / General Discussions / Re: Move to Kotlin? on: 2017-11-07 11:36:03
I guess type on the right was needed also because of inferred types, which I deep use and love

Considering Java is getting inferred types in March, that doesn't seem a correct assertion. Sorry @princec, you'll just have to ignore them!  Wink

I actually think we will get 6-monthly releases this time around, because it's linked to changing the development model.
30  Discussions / General Discussions / Re: Move to Kotlin? on: 2017-11-07 10:47:33
Unless you are a Netbeans user ...

I'm an Apache NetBeans committer.  Grin  And my main project is NetBeans Platform based, so yes not so easy currently.

Kotlin/Native uses LLVM for ahead-of-time compilation to platform-specific executables. This is still a work in progress and early to judge performance-wise. It features both explicit memory management and (currently) a reference-counting GC.

Then of course there's the fun of doing the exact oppositeWink
Pages: [1] 2 3 ... 43
 
Ecumene (110 views)
2017-09-30 02:57:34

theagentd (136 views)
2017-09-26 18:23:31

cybrmynd (245 views)
2017-08-02 12:28:51

cybrmynd (241 views)
2017-08-02 12:19:43

cybrmynd (240 views)
2017-08-02 12:18:09

Sralse (254 views)
2017-07-25 17:13:48

Archive (864 views)
2017-04-27 17:45:51

buddyBro (1008 views)
2017-04-05 03:38:00

CopyableCougar4 (1569 views)
2017-03-24 15:39:42

theagentd (1373 views)
2017-03-24 15:32:08
List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05

SF/X Libraries
by SkyAphid
2017-03-02 06:38:56

SF/X Libraries
by SkyAphid
2017-03-02 06:38:32

SF/X Libraries
by SkyAphid
2017-03-02 06:38:05

SF/X Libraries
by SkyAphid
2017-03-02 06:37:51
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!