Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (534)
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
  ignore  |  Print  
  Java 7 to get Closures!  (Read 21632 times)
0 Members and 1 Guest are viewing this topic.
Offline xinaesthetic

Senior Member


Medals: 1



« Reply #90 - Posted 2009-11-26 22:47:27 »

euh... Shocked no you are crazy it is necessary ?! imagine how much error it will introduce : like in mathematical, stuff will be cast from double to int/float or even String<=>int ? but also in many other case. casting is IMO necessary to avoid lot of confusion. With auto-casting Java may become as php/javascript very hard to be used in area that requiere high precision/smartness.

and why not making all variable type "var" , but hey ! wait the language you define already exist and its name is JavaScript not Java ! Tongue

EDIT :and when it is absolutly clear there is already no need to cast it like :
1  
2  
float f=3;
double d=f;

works without any warning when the inverse dosen't


Well, C# has 'var', which must be assigned at the same type as declaration and type is inferred from the first use, at which point it is static.  Nice little sweetener to avoid irritating boilerplate, particularly with complex generics.  So unlike Javascript, you can't have
1  
2  
var s = "Hello";
s = new Array();

or whatever, since 's' is a string.  Same with Scala, I think.  Compiler says no.

C# is also introducing a new 'dynamic' type, "The type is a static type, but an object of type dynamic bypasses static type checking.".  I haven't tried it out.

Automatic casts sound like a world of pain.  Maybe they wouldn't be so bad.  One thing I will say is that the way co&contravariance has been handled in C# is less good than Java, which seems to lead to more casts being needed in my experience (again, this is being revised in C# 4, not entirely sure of the new spec).  So I guess it could be nice to save having to type them manually...  It tends to make me feel a little wrong inside having to cast things in certain situations, and I wouldn't want any genuine potential wrongness to be hidden.

As for how closures help with parallelism.  I guess it has something to do with lazy evaluation, and allowing the runtime to more easily come up with a strategy of when the function should be executed, for example for each element of a list in parallel.
Offline OverKill

Junior Member




Java games rock!


« Reply #91 - Posted 2009-11-27 00:19:59 »

euh... Shocked no you are crazy it is necessary ?! imagine how much error it will introduce : like in mathematical, stuff will be cast from double to int/float or even String<=>int ? but also in many other case. casting is IMO necessary to avoid lot of confusion. With auto-casting Java may become as php/javascript very hard to be used in area that requiere high precision/smartness.

and why not making all variable type "var" , but hey ! wait the language you define already exist and its name is JavaScript not Java ! Tongue

EDIT :and when it is absolutly clear there is already no need to cast it like :
1  
2  
float f=3;
double d=f;

works without any warning when the inverse dosen't

Actually I was thinking more along the lines of casting objects that are instances of.
F.i.
StringBuffer implements Serializable, Appendable, CharSequence and extends Object.
So any of these would be ok (presuming Object is also a StringBuffer:
StringBuffer sb = object;
Serializable ser = object;
Appendable append = object;
... (you get the idea)

Now Writer also implements Appendable, so :
Appendable append = object;

for me it is just a short form of
if (object instanceof Appendable )
  Appendable append = (Appendable) object;

Think about it, does anyone do this?
interface A
interface B extends A
interface C extends A

A a = (C) o; (basically casting to the top-level object)
Not really or? If o is an instance of A then just use A.
If it is not, you are SOL anyway.

Though maybe I am seeing it wrong (been a loooong week)

I was NOT talking about casting objects between types that are of different types.
(cept in certain cases)
Offline DzzD
« Reply #92 - Posted 2009-11-27 01:23:48 »

Quote
for me it is just a short form of
if (object instanceof Appendable )
  Appendable append = (Appendable) object;
ha yes, this one make more sens, and would have be less boring than generics with a CCE  throws when requiered.

but the problem it introduce maybe is that type will be then checked at runtime and no more at compil time

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Roquen
« Reply #93 - Posted 2009-11-27 15:14:46 »

WRT: Make Java pure OO.
Quote
A compliant ahead-of-time compiler may not perform transforms across compilation-units.
Nothing to do with what i said.

Then the only option (in general) available to the ahead-of-time compiler is to unbox on incoming edges and box on outgoing. Not good.

WRT: Operator overloading.
Consistency between compareTo and equals or between equals and hashCode can't be enforced. That doesn't stop consistency being in the contract.

I'd call these examples of style recommendations, not contracts.  Your examples of "(a+b)-b = (a-b)+b = a" and "(a*b)/b = (a/b)*b" require certain algebric properties and that simply doesn't make sense to me.  As a simple counter-example: vector analysis cannot meet the second requirement.  My basic thinking here is that you cannot dicate good style.  And, of course, good style is subjective.  It's in the nature of high level languages to provide features which can be abused.

WRT: Closures.  I have no feeling one way or the other about adding them to Java.  However there seems to be some confusion..they are not the simply sugar for anonymous functions.  Faking a closure in Java requires a fair amount of boilerplate code.

WRT: Generics.  I don't understand the complaints against.  They don't do anything, other than allow additional user-defined type checking.  I also like being able to drop tons of casts.  My compliants would be: I don't know how to properly define a generic type which is cyclic.  They really should have been enforced by the VM instead of only being used by the ahead-of-time compiler.  And the new inferrence (on creation) should have been in the first release.

WRT: Other language additions.  Stuff like closures, tuples, dynamic invoke, et al. have all been on the table for a long time.  It simply takes awhile for a small team to build the design and implement each.

WRT: Inferred type assignments.

The original argument would be that the cast is an indication that the assignment may potentially cause an exception.

but the problem it introduce maybe is that type will be then checked at runtime and no more at compil time

The ahead-of-time compiler may not remove type assignment checks anyway.
Offline Markus_Persson

JGO Wizard


Medals: 14
Projects: 19


Mojang Specifications


« Reply #94 - Posted 2009-11-27 16:05:19 »

How is it 'fake'? 

I assume by fake you mean it's syntactic sugar, and there is nothing wrong with syntactic sugar IMO.

Do you also prefer to define Iterators instead of using the for(Obj o : collection) loop?

-Ido.

No, but I prefer to do
1  
2  
3  
4  
5  
6  
7  
for (int i=0; i<entities.size(); i++) {
   Entity e = entities.get(i);
   e.tick();
   if (e.destroyed()) {
      entities.remove(i--);
   }
}

rather than to use enhanced for which insists on using an Iterator on an ArrayList, and doesn't expose any way to remove (or add) entries while iterating over it.
Enhanced helps keep code short in some cases, but it doesn't make the language more powerful in any way, shape or form.

Closures would, except now they're just hacks to provide single function class interfaces. Why just make them synthetic sugar which eats up extra resources when one could change the JVM to make the language ACTUALLY support it instead of just faking it.
I could write a preprocessor for basic, then claim basic supports closures as well.

Sun's been doing this a lot lately. Generics are deeply flawed because of it.

Play Minecraft!
Offline pjt33
« Reply #95 - Posted 2009-11-27 16:24:57 »

for me it is just a short form of
if (object instanceof Appendable )
  Appendable append = (Appendable) object;
I'd like to keep explicit instanceof checking and make the compiler track known instanceof information: so
1  
2  
3  
4  
5  
6  
Object foo = foo();
if (foo instanceof Appendable)
{
    // In this scope and while foo has not potentially been assigned to I can call
   foo.append(bar);
}
But I suspect it would be hard to do this in a way which didn't make maintenance a pain.

WRT: Operator overloading.
I'd call these examples of style recommendations, not contracts.  Your examples of "(a+b)-b = (a-b)+b = a" and "(a*b)/b = (a/b)*b" require certain algebric properties and that simply doesn't make sense to me.  As a simple counter-example: vector analysis cannot meet the second requirement.  My basic thinking here is that you cannot dicate good style.  And, of course, good style is subjective.  It's in the nature of high level languages to provide features which can be abused.
Can you define * and / for arbitrary vectors (other than component-wise)?
Offline Roquen
« Reply #96 - Posted 2009-11-27 16:53:41 »

Can you define * and / for arbitrary vectors (other than component-wise)?

Only by moving to a higher level algebra (for want of a better term).   

Rewriting the second to use a single binary operator:

(a*b)*(1/b) = a*(b*(1/b))

Requires the existance of a unqiue multiplicative inverse and that the product associates.  These are not generally true.
Offline ewjordan

Junior Member





« Reply #97 - Posted 2009-11-27 17:39:45 »

WRT: Closures.  I have no feeling one way or the other about adding them to Java.  However there seems to be some confusion..they are not the simply sugar for anonymous functions.  Faking a closure in Java requires a fair amount of boilerplate code.

+1 to that - I think a lot of people seem to think that a closure is just a shorter syntax for an anonymous class, which is not the case.

At the moment it's not clear whether what they're proposing actually qualifies as a "closure" or not, though; plenty of folks are, in fact, pushing for no more than a simpler anonymous class syntax, and I really have to take issue with calling that a closure, since the more powerful things you can do with closures are not possible if that's all we get.

And FWIW, none of this stuff is even remotely new, even in OO languages, so I don't really buy the complaint that Java is trying to "keep up" or anything like that.  It's more that computing is necessarily pushing towards parallelism, and functional style becomes vastly more important there, so Java has to make some concessions in that direction to remain viable.  Without a serious effort to ease parallel programming, Java will fall further behind productivity-wise as we need to scale horizontally, which would be a shame.  Real closures would allow a lot of the important logic and optimization to be put into easy to use libraries instead of the rather low level concurrency support we have today, and I think that will be a major win if it's done right.

The current syntax seems kind of bizarre, though, and some of the discussions on the mailing lists make me worry that this implementation will be pretty seriously crippled, so I don't know how I feel about the addition overall...I'll have to see how the finalized proposal looks, I think.

Cas, as far as automatic conversions, Scala does lets you do that (basically, just write a conversion function and mark it implicit, and then it Just Works), and it is extremely convenient - it makes dealing with unit-ful values a breeze, whereas it's a major pain in the ass in Java because of the explicit conversions all over the place.

It would never make it into Java, though, because people in the Java community are psychotically paranoid about potential abuse of language features, and this one actually has some real potential for confusion and bug-hiding.

Can you define * and / for arbitrary vectors (other than component-wise)?
(Roquen already correctly noted that division requires a unique inverse, which is definitely true)

Sure, you can do anything you want, but it wouldn't necessarily have all the properties you might want from those operators, or a particularly natural meaning.  With vectors in N dimensions, there's the inner (dot) product, which returns a scalar, and an outer product, which returns an N-dimensional matrix in the obvious way.  Neither of these permit division as the inverse, since they don't create vectors.  If you want vector*vector = vector, then in 3D we usually use the dual of the exterior or wedge product of 2 vectors (which boils down to the cross product), but this doesn't generalize to other dimensionalities, since you need N-1 vectors as inputs to make the dual of a wedge come out as a vector (Google "exterior algebra" if you care what any of that means).  In 2D you can use complex multiplication, but that may or may not let you do something useful, depending on context.

Usually people define * and / between vectors and numbers, but not between vectors themselves, when operator overloading.  If you're dealing with complex numbers, you define them all.  Matrices get * defined, but oftentimes not /, because the operation of inverting a matrix can fail sometimes and it's usually best not to hide that by making it look like regular old division.

This is pretty much exactly how mathematicians use the objects and symbols as well, at least for these simple cases, except that sometimes it's implicit that if you multiply two vectors you're taking the inner product, which is a lot more clear in written math because you use a dot for multiplication anyways.

Personally, I'd love to see Java get some built in primitives (preferably stack-allocated and immutable) for vectors, matrices, and complex numbers, with these overloadings baked in; if that happened, I wouldn't care about operator overloading one bit, though I'd also like the big/arb. precision number classes to get the same treatment.  I can't come up with many other compelling or common use cases for operator overloading that make sense, but those ones cause a lot of pain if you work in areas that require them...
Offline Roquen
« Reply #98 - Posted 2009-11-27 18:13:28 »

Short and inaccurate history: 

1) Hamilton liked 3D, so he invented Quaterions (which a 3-bivector plus a scalar)
2) Around the same time Grassmann was into multiple dimensions, so he tossed out an algebra in n-dimensions that has the vector and bivector parts.  Cool syntax...too bad he was just a high school teacher...oh well
3) Clifford came along: grokked Quaternions, grokked Exterior algebra.  Figure how to merge them, fills in the missing parts and works for topologies other than Euclidiean.  Then he died young.  He wasn't a rock star, so he was promptly forgotten...oh well.
4) Gibbs comes along and doesn't really understand 1 or 2, but like the bits that he does and probably never heard of 3. (FYI: He also didn't like operator overloading)  So he created a broken version of Quaternions after stealing syntax from Grassmann.  And calls it vectors. Yeah!  Too bad that the 'vector' part of a quaterion is not a Gibbs vector...oh well.  It takes the world by storm.  The best tech as well as math always wins

The end.

(NOTE: I could be confused about the Exterior algebra parts..too lazy to review)
Offline OverKill

Junior Member




Java games rock!


« Reply #99 - Posted 2009-11-27 22:37:43 »

@ewjordan:
If there is any confusion about closures, then this is because the unclear info spread around:

In the first link, the example was that closures make anon classes a lot easier.

The one by the java dev, he talks blabs on about parallel programming but does not really explain what closures have to do with it.
Kinda felt like 'I have this cool feature I want and I need a way to sell it'.

I agree, the now (not future) is parallel programming, but then why not think of a way to actually add it into the java realm instead of creating some kind of cyborg implant and hope the body does not reject it.

Come to think of it, aren't the closures not just like (jython, bsh,...) script files you want executed?

Ok, Java was not designed with parallel programming in mind and if we cannot adapt the design to it, maybe it is better to make something new?
Having 'evolving' languages might not be the best idea.
Once C++ was the cream of the crop, but it was lacking in many departments so some people made Java to overcome those.
Now Java is lacking so why not create something new?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline pjt33
« Reply #100 - Posted 2009-11-27 23:48:43 »

Sure, you can do anything you want, but it wouldn't necessarily have all the properties you might want from those operators, or a particularly natural meaning.
That was my point.

Quote
Usually people define * and / between vectors and numbers, but not between vectors themselves, when operator overloading.
Hmm. Definitely useful, but trickier to do in a generalisable way.

[/quote]Matrices get * defined, but oftentimes not /, because the operation of inverting a matrix can fail sometimes and it's usually best not to hide that by making it look like regular old division.[/quote]
Division can fail in a field, although floating point in Java hides it by using infinities and NaNs. If integer division can get away with throwing ArithmeticException I don't see why overloaded division couldn't throw a SingularMatrixException.

Quote
Personally, I'd love to see Java get some built in primitives (preferably stack-allocated and immutable) for vectors, matrices, and complex numbers, with these overloadings baked in; if that happened, I wouldn't care about operator overloading one bit, though I'd also like the big/arb. precision number classes to get the same treatment.  I can't come up with many other compelling or common use cases for operator overloading that make sense, but those ones cause a lot of pain if you work in areas that require them...
I'm trying to think about how it could be done while still being and feeling like Java and with a bit more flexibility for people who want to play around with surreal numbers, octonions, or an arbitrary field. (I'm assuming that quaternions would be added to your list of basics).
Offline DzzD
« Reply #101 - Posted 2009-11-28 14:55:26 »

Quote
Quote
Quote from: DzzD on November 26, 2009, 07:23:48 pm
but the problem it introduce maybe is that type will be then checked at runtime and no more at compil time
The ahead-of-time compiler may not remove type assignment checks anyway
yes sure but it is better/easier to see it at compil time rather than later when running the programm

Quote
I agree, the now (not future) is parallel programming, but then why not think of a way to actually add it into the java realm instead of creating some kind of cyborg implant and hope the body does not reject it.
+1

a longer think about how to improve parallele programing in java (maybe with the help of an external library) rather then trying to add fastly every stuff that java dont have may be nice.

"Java have real lack in parralele programming ? yes ? no ? if yes let's found a solution !" would be better than "Java have closure ? no, let's add it ! ... but what for ? hum... he... just to do like other languages, no ?"

what does closure will help us for ? any clear example ?

Offline i30817

Junior Member





« Reply #102 - Posted 2009-12-02 04:51:45 »

http://gee.cs.oswego.edu/dl/jsr166/dist/extra166ydocs/

You see all those Opps in the right side there?
 Roll Eyes
Offline i30817

Junior Member





« Reply #103 - Posted 2009-12-02 04:54:11 »

Really as a java programmer, i'm surprised that you're not sick to death of having to create Runnable inner classes.
(and no exposing the interface in the main class is not a solution).
Offline OverKill

Junior Member




Java games rock!


« Reply #104 - Posted 2009-12-02 09:51:33 »

@i30817:
It is part of the language. Don't like it? Find another language.
Ask a C developer if they like doing malloc.

You know, I get tired of remembering all the names of people so I will just call them Bob from now on.
Plus punctuation and grammatical tenses are also annoying so I'll just leave those out as well.

Seriously, it is the spec and thats the way it is.
Changing the spec because *I* am to lazy to write stuff is the surest path to doom.
Offline Markus_Persson

JGO Wizard


Medals: 14
Projects: 19


Mojang Specifications


« Reply #105 - Posted 2009-12-02 10:25:40 »

What's wrong with wanting to improve your tools?

Of course, one reason for using java is to code for the JVM which is very fast and quite cross platform. If that's your major goal, one might look into alternative languages, like Scala.

Play Minecraft!
Offline xinaesthetic

Senior Member


Medals: 1



« Reply #106 - Posted 2009-12-02 13:17:32 »

Seriously, it is the spec and thats the way it is.
Changing the spec because *I* am to lazy to write stuff is the surest path to doom.
Programmers are lazy.  Programming improves because they put a lot of work into facilitating this laziness.
Online princec

JGO Kernel


Medals: 342
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #107 - Posted 2009-12-02 13:58:47 »

Yup, creating runnable inner classes is a pain. But what I want is readable syntax for making this easier, rather than co-opting random ascii symbols, or introducing annotations to work around quirks. Prize for the first person to come up with a shorthand syntax that looks and reads nicely.

And I really really would like type inference Smiley I can't think of any way to abuse it unless someone could enlighten me.

Cas Smiley

Offline Roquen
« Reply #108 - Posted 2009-12-02 15:04:57 »


@i30817:
It is part of the language. Don't like it? Find another language.
Ask a C developer if they like doing malloc.
I love malloc. So much so, I write multiple flavors for different purposes.

Seriously, faking a good implemenation of closures is very difficult in Java. You would have to write something like what kilim does for continuations.  You really want your enclosed expression to evalulate in a lightweight thread and have to access to its enclosing method's local variables.  However, were I to guess: the latest JDK7 milestone includes a new fork/join framework...the first pass is likely to be sugar on top of this.  I just went back and reviewed Mark Reinhold's blog entry, no local variable access...BOO!

And I really really would like type inference Smiley I can't think of any way to abuse it unless someone could enlighten me.

Ah, but it's like operator overloading. It might confuse people..we can't have that.

As an aside: When does sugar become "evil"? Taken to the extreme, the only viable language is LISP (well, before they added ' et al, of course!)
Offline pjt33
« Reply #109 - Posted 2009-12-02 15:26:57 »

And I really really would like type inference Smiley I can't think of any way to abuse it unless someone could enlighten me.
I'm not worried about abusing it: I'm worried that it will make unintentional bugs harder to spot. There are some places where type inference could be improved (particularly looking at places where I still have to do Collections.<Foo>emptySet() and at constructs like Foo<A, B> = new Foo<A, B>() which have no ?s), but making all casts implicit strikes me as a bad idea for maintainability of code. It's like auto-unboxing, which is simple in concept but caused me much bewilderment the first few times I got a stack trace showing NPE and the corresponding line in my IDE was "a=b;" or "if (p)".
Offline Roquen
« Reply #110 - Posted 2009-12-02 15:37:11 »

Foo<A, B> = new Foo<A, B>()

This is suppose to be part of the last milestone.
Online princec

JGO Kernel


Medals: 342
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #111 - Posted 2009-12-02 16:40:12 »

This is suppose to be part of the last milestone.
Yep, that's one of Project Coin's offerings. So if they can do it there... why can't we have it elsewhere Smiley C'mon, let's see an example where it could be confusing or have unintended results.

Cas Smiley

Offline pjt33
« Reply #112 - Posted 2009-12-02 17:14:51 »

C'mon, let's see an example where it could be confusing or have unintended results.
Your example from the previous page, expanded for clarity:
1  
2  
3  
4  
5  
6  
7  
Object foo = foo();
// Insert various
// other lines
// here so that foo's
// type isn't
// obvious.
String bar = foo;

If it's inside an instanceof check then, as I said earlier, that would be fine, but as is that's an invitation to bugs. Explicit casts have the benefit of documenting that you know you're doing something unsafe.
Online princec

JGO Kernel


Medals: 342
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #113 - Posted 2009-12-02 17:36:45 »

Why's a cast unsafe suddenly? By saying String bar = foo; I assert that foo is a String. Why do I need to type (String) to say that?

Cas Smiley

Offline Roquen
« Reply #114 - Posted 2009-12-02 17:46:58 »

For argument sake, what should the front-end compiler do when a statically known invalid cast occurs?  Or is your suggestion that if the cast is statically known to be correct, then it's optional?

WRT: Being able to drop the cast inside of an instanceof.  The trick here is your grammar becomes context dependent.  I'm okay with that, but some folks aren't.
Offline pjt33
« Reply #115 - Posted 2009-12-02 17:49:48 »

Why's a cast unsafe suddenly? By saying String bar = foo; I assert that foo is a String. Why do I need to type (String) to say that?
Because you previously asserted that you didn't know it was a String and you haven't given any reason for changing your mind.
Online princec

JGO Kernel


Medals: 342
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #116 - Posted 2009-12-02 18:26:45 »

I don't want to give a reason - that's the work of machines to figure it out. If it's impossible I'd like to be told, but as long as it's legal to cast, I don't see why I should have to go to the effort and clutter of stating it - it's totally superfluous to the meaning of the code. String s = foo; means I think foo is a String and assign it to s; so does String s = (String) foo; - but one is shorter and clearer.

Cas Smiley

Offline pjt33
« Reply #117 - Posted 2009-12-02 18:45:29 »

I don't want to give a reason - that's the work of machines to figure it out.
I don't care what the compiler can figure out: I care what the maintainer can figure out.
Online princec

JGO Kernel


Medals: 342
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #118 - Posted 2009-12-02 18:51:27 »

The less code there is for the maintainer to figure out the less chance he or she has of getting it wrong.

Cas Smiley

Offline kappa
« League of Dukes »

JGO Kernel


Medals: 74
Projects: 15


★★★★★


« Reply #119 - Posted 2009-12-02 19:44:12 »

some more questions and answers on mark reinholds blog regarding closures in java 7

http://blogs.sun.com/mr/entry/closures_qa


and its really 'MEH' that Java 7 is being delay to September 2010.
Pages: 1 2 3 [4] 5 6
  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.

pw (35 views)
2014-07-24 01:59:36

Riven (33 views)
2014-07-23 21:16:32

Riven (21 views)
2014-07-23 21:07:15

Riven (24 views)
2014-07-23 20:56:16

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

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

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

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

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

Riven (56 views)
2014-07-14 18:02:53
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!