Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (133)
games submitted by our members
Games in WIP (603)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 ... 3 4 [5]
  ignore  |  Print  
  Lots of doors are being closed for Java  (Read 18406 times)
0 Members and 1 Guest are viewing this topic.
Offline zammbi

JGO Coder


Medals: 4



« Reply #120 - Posted 2011-02-14 20:35:06 »

Quote
China statistics are interresting too, this represent a lot of people.... http://gs.statcounter.com/#browser-CN-monthly-201001-201101
55% still on IE6 wow...

Current project - Rename and Sort
Offline philfrei
« Reply #121 - Posted 2011-02-15 04:53:29 »

Ah you must live in a world of early adopters and risk taking geeks.
The rest of the world is about 3-4 years behind you I'm afraid. I only just started using Java 5 about a month ago because of the number of OSX users still on JDK1.4 - now at an acceptably low 10% or so, so I can live without their money.

Cas Smiley

So true. I've run into a more than a few of folks that can't run my little 2D puzzle work-in-progress, thanks to my using Java 1.6. And they are unwilling (nervous/lack confidence) to navigate the existing Java upgrade process. If there is one thing that Flash has really done right, it is that it has made upgrading something just about ANY user both can do and is both comfortable and willing to do. That little pressure point is like a Spock-hold on Java's client-side neck.

"It's after the end of the world! Don't you know that yet?"
Offline princec

« JGO Spiffy Duke »


Medals: 435
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #122 - Posted 2011-02-15 13:30:30 »

Still, JL235's assertion is that browser tech is kept up-to-date much more than Java tech, and that's cool, the proof of the pudding will be in the tasting and all that. Just not quite a risk I want to take just yet. I was an "early adopter" with Java and look where it got me.

Cas Smiley

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

JGO Coder


Medals: 10



« Reply #123 - Posted 2011-02-15 14:05:59 »

Still, JL235's assertion is that browser tech is kept up-to-date much more than Java tech, and that's cool, the proof of the pudding will be in the tasting and all that. Just not quite a risk I want to take just yet. I was an "early adopter" with Java and look where it got me.

Cas Smiley
More companies are also pushing the browser for client-side apps then was/is the case with Java. That's partly why I believe early adoption is going to be more successful.

Even Microsoft is now pushing JavaScript + HTML5 over it's own Silverlight. That's really something!

Offline JL235

JGO Coder


Medals: 10



« Reply #124 - Posted 2011-02-15 16:47:10 »

Google have also just added the canvas to GWT (announcement is here). So now it would be easier to build Java games with GWT and deploy to the browser.

Offline BatKid

Senior Newbie





« Reply #125 - Posted 2011-02-15 18:00:05 »

This is pretty awesome stuff.  I don't have much experience with GWT, but I believe that it essentially translates your java code into javascript so that it can execute in the browser.  What are the restrictions?  I suppose it only implements a subset of the java libraries?

Learn Java in 3D with env3d
Offline krasse
« Reply #126 - Posted 2011-02-16 05:54:04 »

This is pretty awesome stuff.  I don't have much experience with GWT, but I believe that it essentially translates your java code into javascript so that it can execute in the browser.  What are the restrictions?  I suppose it only implements a subset of the java libraries?

Here are some facts about the JRE simulation:

http://code.google.com/intl/sv-SE/webtoolkit/doc/latest/DevGuideCodingBasicsCompatibility.html

Quite a lot of useful classes are emulated but you can't do multithreading and full reflection.

Offline JL235

JGO Coder


Medals: 10



« Reply #127 - Posted 2011-02-16 08:35:35 »

What is really cool though is that you can setup remote method invocation (so you can seemlessly call methods on the server from the client) and be able to pass across instances of stuff from one to the other and GWT will automatically work it all out. But you can get some very strange error messages when it goes wrong.

In a topic about how 'Java doors are closing' this is certainly one that helping to make the language more popular for the client (in some ways anyway).

Offline krasse
« Reply #128 - Posted 2011-02-16 09:21:11 »

What is really cool though is that you can setup remote method invocation (so you can seemlessly call methods on the server from the client) and be able to pass across instances of stuff from one to the other and GWT will automatically work it all out. But you can get some very strange error messages when it goes wrong.

Yes, this is really cool!

It is also very straightforward to develop the server and client in Eclipse if you want to deploy your application on the Google App Engine. The JRE on the server-side supports a lot more functionality than the client JS JRE simulation.
You can also test everything offline just as a regular Java application.

Offline gouessej
« Reply #129 - Posted 2011-02-16 09:42:41 »

On my view, Java to JavaScript solution is a possible way, not the single one, I don't see this as a replacement of the current JVM. There is already GWT, I'm not sure Oracle should provide its own solution except if it overcomes some limitations of GWT.

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

Junior Devvie


Medals: 4



« Reply #130 - Posted 2011-02-16 12:12:11 »

How about manipulating the DOM (including the canvas with or without WebGL) from a "headless" Java applet? Of course, it would not get around the need for the user to have a current JRE, but it may work around JavaScript's performance, if that is the performance bottleneck at the client and not the DOM itself, as well as (possibly) the applet loading time. It is possible right now, but currently applets require AWT. Perhaps with the new AWT-free plugin scheduled for Java 7 this would be an interesting solution.
Manipulating the DOM using the Java language isn't fun, but perhaps with a different JVM language, like Visage, it could be done as well as with JavaScript or even better.
Offline dleskov

Senior Devvie


Medals: 10



« Reply #131 - Posted 2011-02-17 09:59:42 »

Will try one more time to pester Excelsior. Last time I asked Dmitry they were looking at a low five-figure sum to get an ARM backend on their incredibly good AOT compiler/VM.
We are dead busy with the x64 port right now, or, more precisely, with paying down the principal of the technical debt accrued for 10 years... But I can tell you that ARM is likely to be the next target, especially if Microsoft keeps its promise to make Windows available on that platform.

Full-fledged iOS port is a different story though.

Dmitry Leskov
Excelsior LLC

Offline kappa
« League of Dukes »

JGO Kernel


Medals: 81
Projects: 15


★★★★★


« Reply #132 - Posted 2011-02-17 10:27:34 »

Full-fledged iOS port is a different story though.

Not sure how profitable it'd be (compared to how much it'd cost to develop) but targeting apple platforms could be pretty cool, especially considering their recent anti-vm stance. Excelsior Jet could get a monopoly to becoming the only way to get java apps on iOS and the Mac App Store Smiley

Many developers would rather just write a game/app once (Android and iOS) and java looks like a perfect fit if the above worked.
Offline dleskov

Senior Devvie


Medals: 10



« Reply #133 - Posted 2011-02-17 11:18:09 »

Full-fledged iOS port is a different story though.
Not sure how profitable it'd be (compared to how much it'd cost to develop)
You nailed it!

The problem is not the compiler, it is the standard library, specifically AWT native methods and L&F. Your app does not only have to be compiled down to native code, it must also look and feel native in order to get accepted in the iOS App Store.

For Windows and Linux, we just use the licensed reference implementation of the standard library. It costs us a hefty sum of money each year, but it is exactly the same code that Sun/Oracle ships alongside the HotSpot VM, so we get as close to 100% compatibility as possible. "Excelsior JET for Mac OS X" has been the #1 feature request ever since Apple's switch to Intel CPUs, but the costs of porting AWT over to Cocoa and reproducing Apple's L&F still looked prohibitive. Maybe something will change as a result of Apple contributing to OpenJDK, but we may face a license incompatibility then...

Offline princec

« JGO Spiffy Duke »


Medals: 435
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #134 - Posted 2011-02-17 11:40:25 »

Aha!

...LWJGL based apps though are nice and easy for you to deal with though Smiley We'll take care of the iOS interface bit. If you could just make JET spit out a .so we can call into from a stub...

Cas Smiley

Offline dleskov

Senior Devvie


Medals: 10



« Reply #135 - Posted 2011-02-17 11:50:24 »

Aha!

...LWJGL based apps though are nice and easy for you to deal with though Smiley We'll take care of the iOS interface bit. If you could just make JET spit out a .so we can call into from a stub...

Cas Smiley
Well, a headless port (that is, without screen/mouse/keyboard related parts of the library/runtime) is indeed permitted by the Java license, and we may start with just that on ARM/Linux anyway. An iOS port should not be that difficult then.

Field of use may be a problem though - Java SE is still not permitted on cellphones, and its usage on devices other than general purpose PCs and servers is subject to royalties... I expect the former to change at some point as the line between cellphones and everything else has been blurred by tablets and such.

Offline kappa
« League of Dukes »

JGO Kernel


Medals: 81
Projects: 15


★★★★★


« Reply #136 - Posted 2011-02-17 11:53:33 »

LWJGL + a headless port should be more then enough for any type of game.
Offline gouessej
« Reply #137 - Posted 2011-02-17 15:36:09 »

LWJGL + a headless port should be more then enough for any type of game.
LWJGLJogAmp or LWJGL + a headless port should be more then enough for any type of game.

Offline princec

« JGO Spiffy Duke »


Medals: 435
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #138 - Posted 2011-02-17 15:49:48 »

I thought JogAmp rather required AWT to work?

Cas :0

Offline badlogicgames

« JGO Bitwise Duke »


Medals: 74
Projects: 2



« Reply #139 - Posted 2011-02-17 15:57:03 »

+1 for JET on ARM. Kev is currently looking into XMLVM which is of course far, far, FAR behind anything excelsior has to offer. However, with their upcoming C backend it seems feasible to at least create small GLES games.

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

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #140 - Posted 2011-02-17 18:40:07 »

I thought JogAmp rather required AWT to work?

Cas :0
the NEWT display variant doesn't afaik,

Offline princec

« JGO Spiffy Duke »


Medals: 435
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #141 - Posted 2011-02-17 19:49:55 »

Aha that's the newfangled JDK7 / Prism / JavaFX plugin thingy?

Cas Smiley

Offline kappa
« League of Dukes »

JGO Kernel


Medals: 81
Projects: 15


★★★★★


« Reply #142 - Posted 2011-02-17 19:52:54 »

Aha that's the newfangled JDK7 / Prism / JavaFX plugin thingy?

Cas Smiley
no, NEWT is JogAmp's own native windowing system.
Offline Mordan

Junior Devvie





« Reply #143 - Posted 2011-02-27 15:14:19 »

I will just repeat

1# Java failed on the desktop because Sun never bothered creating an application shop for java applications. You should have been able to launch "Java Control" and find a list of all java applications installed on your desktop and manage them from there. Some kind of  Java OS layer on the top of windows.

2#J2SE is good because of backward compatiblity but it has grown thick and fat. Too many useless classes. Keep it for those who need it.

3#Sun should have taken the J2ME core classes Graphics, Canvas and bases classes like String and build a super lean super light framework. Scrap the LCDUI package. Scrap Vector. Keep backward compatiblity of bytecode.

4# on top of the lean base framework, create a Swing module and Game Interface module. Make it so you can load Base+GameInterface without loading Swing.

Offline ido

Junior Devvie





« Reply #144 - Posted 2011-02-27 15:22:04 »

1# Java failed on the desktop because Sun never bothered creating an application shop for java applications. You should have been able to launch "Java Control" and find a list of all java applications installed on your desktop and manage them from there. Some kind of  Java OS layer on the top of windows.

That is a very minor (if at all) factor IMO. Flash didn't (and doesn't) have an "application shop" and that didn't prevent it from becoming the de-facto standard for web games.

Offline Mr. Gol

Senior Devvie


Medals: 1



« Reply #145 - Posted 2011-02-27 16:33:14 »

1# Java failed on the desktop because Sun never bothered creating an application shop for java applications. You should have been able to launch "Java Control" and find a list of all java applications installed on your desktop and manage them from there. Some kind of  Java OS layer on the top of windows.

That is a very minor (if at all) factor IMO. Flash didn't (and doesn't) have an "application shop" and that didn't prevent it from becoming the de-facto standard for web games.

Agreed. There have basically been two periods when Sun made a serious effort to improve Java on the desktop. The first was around the 1.4 release, and the other was before the release of 6 update 10. In both these time periods the concept of an App Store did not exist yet.
Offline princec

« JGO Spiffy Duke »


Medals: 435
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #146 - Posted 2011-02-27 20:55:34 »

So Java is no longer included in Mac OS... this presumably means that OpenJDK should be generally available for Mac really soon.

Cas Smiley

Offline tberthel
« Reply #147 - Posted 2011-02-28 20:34:48 »

I will just repeat

1# Java failed on the desktop because Sun never bothered creating an application shop for java applications. You should have been able to launch "Java Control" and find a list of all java applications installed on your desktop and manage them from there. Some kind of  Java OS layer on the top of windows.

2#J2SE is good because of backward compatiblity but it has grown thick and fat. Too many useless classes. Keep it for those who need it.

3#Sun should have taken the J2ME core classes Graphics, Canvas and bases classes like String and build a super lean super light framework. Scrap the LCDUI package. Scrap Vector. Keep backward compatiblity of bytecode.

4# on top of the lean base framework, create a Swing module and Game Interface module. Make it so you can load Base+GameInterface without loading Swing.



Wow you can read my mind.  Not only that, but I actually did all those things and more all by myself.  Since, I have no funding I can't really drive my stuff very fast.  I just turtle along with FreeBlisket and the AllBinary Platform.  I only have half a million lines of code and shit to myself.  It is sad really, but I love making software.  Oh wells.

Offline Mordan

Junior Devvie





« Reply #148 - Posted 2011-03-10 10:50:48 »

1# Java failed on the desktop because Sun never bothered creating an application shop for java applications. You should have been able to launch "Java Control" and find a list of all java applications installed on your desktop and manage them from there. Some kind of  Java OS layer on the top of windows.

That is a very minor (if at all) factor IMO. Flash didn't (and doesn't) have an "application shop" and that didn't prevent it from becoming the de-facto standard for web games.


well, at the time it was not called "app shop". I remember when Java Web Start came along. That was brilliant. Why not having a favorite list of JNLPs? A tool to manage downloaded JNLPs? They did nothing else but provide the mechanism of Java Web Start. They didn't bother building the bells and whistles. They might have coined the word "app store" before Apple if they did some end user/desktop work at the time.
Back then I was thinking, build a bloody Java OS layer over Windows. They did not. too bad.

It is like the failed Savaje os/phone. Sun is a failure in end user experience. You can't win it all. Their core competence was server side.
Offline Jacob_

Junior Devvie


Projects: 3



« Reply #149 - Posted 2011-03-20 00:14:50 »

For a highly website-integrated GUI application like my own, Java was the best way to go. .NET ClickOnce sucks and is Windows-only, and system GUI widgets don't work in Flash. The second best way would be to use a custom protocol handler, but that would require an installation... with Web Start you just have to click a link. Putting out updates is a snap too.

Beyond desktop games, I think mobile gaming is where it's at, but Oracle seems more interested in pushing their server technologies than anything else.
Pages: 1 ... 3 4 [5]
  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.

rwatson462 (37 views)
2014-12-15 09:26:44

Mr.CodeIt (31 views)
2014-12-14 19:50:38

BurntPizza (62 views)
2014-12-09 22:41:13

BurntPizza (99 views)
2014-12-08 04:46:31

JscottyBieshaar (60 views)
2014-12-05 12:39:02

SHC (74 views)
2014-12-03 16:27:13

CopyableCougar4 (77 views)
2014-11-29 21:32:03

toopeicgaming1999 (138 views)
2014-11-26 15:22:04

toopeicgaming1999 (127 views)
2014-11-26 15:20:36

toopeicgaming1999 (38 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

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

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

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

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
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!