Maybe it is time to move from Java

[Notsonoble]

Why?
Oracle's pissing even more people off...
http://www.javaworld.com/javaworld/jw-0 ... aints.html
Cross platform isn't what it used to be... it's not just mac, linux, and windows anymore, there's OSX, iOS, Android, Linux, and Windows, java doesn't happen on Android, and well, look above...
There's also this project:
http://www.lunduke-sdk.com/index.php?title=Main_Page
which is by http://radicalbreeze.com/ (well more by Bryan Lunduke himself)

Add to this I see more people moving from java, infact MT is the only Java app any of my buddies are using now.

So while 1.4 is in the works and still Java perhaps MT 2.0 and the utilities that go with it should move on?

[wolph42]

And the alternative being...?

[aliasmask]

And the alternative being...?

I was thinking the same thing. So I googled and found these links:

http://stackoverflow.com/questions/4160 ... -desktop-a
http://www.quora.com/Python-programming ... Python-app

[Notsonoble]

Sorry, in this case the Alternative I was suggesting was the Lunduke SDK... It's not ready yet, but by the time 1.4 is "done" and 2.0 is starting the Lunduke SDK should be close to ready.

[username]

The Lunduke forum has 74 posts in total. The GUI builder sells for $50. I don't see any libraries that aid in, for instance, networking. Where's the "anti-catch"?

[jfrazierjr]

To be honest, the answer is likely going to be: no, we will stay with java. Ultimately, it will depend on what the people who have check in access to the code are willing to learn.

Frankly, I really don't see the appeal of trying use Maptool on a mobile device(yes, I have an IPad, and mostly still prefer using my Laptop for most tasks, though I LOVE my wife's(1st gen) Kindle for reading.. even more than using the IPad's Kindle app). CharacterTool, DiceTool, InitTool, those might be other issues though. For me, the more screen I can see, the better when it comes to maps/encounters and there just is not enough size/resolution on a mobile device for me.... not even close...

Another consideration(which may very well be BS and never to appear), Oracle said several months ago that the were planning to try to create a "runtime" which would allow java code built for desktop (ie, Swing/AWT user interface) to be "auto converted" to use iOS's GUI. The biggest issue with non desktop environments is the user interface part of the code.. those user interface code libraries just do not exist on mobile devices.

Also, don't forget HTML5. Currently, there are a lot of things that are done on the server (macro exectution, etc), but if we convert that stuff to the server, then it makes it much easier to write a slimmer client side interface. Frankly, I would see us pushing to HTML5 on the client side FAR more likely than anyone learning a new language(which I would say won't happen)....

[Azhrei]

Agreed. There is no good better cross-platform language that I know of right now. There's Ruby and Python, but their runtime is not widely distributed and they don't have the plethora of third-party support libraries that Java has. C# is proprietary and Mono is always going to be playing catch-up. And it wouldn't surprise me for MS to suddenly change the licensing so that FOSS implementations of new stuff is no longer allowed. That's part of their "embrace and extend" policy.

What other (serious) candidates are there?

In order to really be cross-platform we'd need to go strictly HTML5 on the client. This has some advantages but also a lot of disadvantages and technical challenges. Computers only keep getting faster and more capable though, so who knows...?

[Craig]

Why?
Oracle's pissing even more people off...
http://www.javaworld.com/javaworld/jw-0 ... aints.html

This is nothing new, its pretty much the standard whining and moaning that has gone on for ever it started long before Oracle bought Java and it will go on long after albeit on a different topics. The OSGi backers are just upset that their technology may not be the one selected to do something, on the other hand they haven't really helped themselves in this regard, persistance has been an issue with OSGi for such a long time now and they have done absolutely nothing at all to address it. As for Canonical who knows what they are playing at, the only Java platform on their distribution was OpenJDK before OpenJDK was the reference platform and they stated that was good enough for everybody, but suddenly now that it is the reference platform its not?

Cross platform isn't what it used to be... it's not just mac, linux, and windows anymore, there's OSX, iOS, Android, Linux, and Windows, java doesn't happen on Android, and well, look above...

Java doesn't happen on Android is a bit misleading, since most Android apps are written in Java, sure the GUI library and some other things are different, but you would be very wrong if you thought that Desktop, Tablet and Phone are all going to share exactly the same GUI layout and code. Java 7 will work fine on Windows, Mac OS X and Linux once all the OpenJDK ports have been released, as will Java 8 when that comes out.

There's also this project:
http://www.lunduke-sdk.com/index.php?title=Main_Page
which is by http://radicalbreeze.com/ (well more by Bryan Lunduke himself)

This is not a new concept (far far from it), its ok for writing small and possibly medium sized apps, but there is no way at all you could use this to write something like MapTool you very quickly hit a wall with the complexity of programs you can create with the "cut and paste blocks" method. As username pointed out there is a real problem with libraries as there are very few. So we would have to write a lot of library code ourselves, whats worse you would have to write that code for every target platform/language. So you get a very inefficient program that takes almost the same amount of effort as maintaining a separate code base for every target platform -- possibly even more --, you still have to write separate GUI code in lunduke for each platform type (phone, tablet, desktop), no IDE support, is painful beyond belief to build, and a huge debugging burden. There are no upsides at all, if I had to choose between this as option 1) and maintaining MapTool in Java for Android, Object - C Cocoa for Mac OS X, C# .Net for Windows, and Object - C Cocoa Touch for iOS as option 2) I would choose option 2) without hesitation. I am not saying I would want to do option 2) but that should give you an idea how unlikely lunduke is a workable solution for us. There is a lot about creating a large program above and beyond just writing new code for it and lunduke doesn't adress any of those other areas, love it or hate it there are very good reasons that Java -- including other JVM languages such as scala, etc-- is used in so many large scale projects.

And the alternative being...?

I think wolph42's question is a very good question. If you wan't a good alternative I picture people trying to answer that sitting in a room looking at each other and then watching a tumbleweed roll through the room. For the sake of a discussion though lets try a few...

So the usual candidates are

• C# and .NET/Mono
• Ruby
• Python
• Flash
• Silverlight
• HTML5

C# and .NET/Mono
The problem with this choice is GUI. The only cross platform GUI that would work is wxNet which is clunky and very hard to create custom controls for, the bindings are poorly documented, and then you have the problems of how compatible is mono with .NET and where is it different. What extra does it buy us (nothing really). Does nothing for us in regards to Android/iOS.

Ruby
Its slow, I know people think Java is slow -- its not, but people hear that is and parrot that misconception.
Cross platform GUI? wxRuby no longer maintained. qtRuby? fine if you are on Windows, not so fine on other platforms...
You know what the best supported cross platform Ruby GUI is? Run JRuby and use swing... If you are going to do that
why not just use Java. Does nothing for us in regards to Android/iOS.

Python
Cross platform GUI? wxPython, yeah no thanks, so buggy on Mac OS X. PyQT is pretty good so at last we have a cross platform GUI "winner". Python is also slower than Java, and its multithreading is no where near as good as Java's, MT uses quite a bit of multithreading. Does nothing for us in regards to Android/iOS.

Flash
Slower than Java. The Mac OS X implementation of flash is nothing short of horrible, Linux is better but its still not great. Flash really doesn't have much of a future on mobile devices, and who knows about desktops, sure Adobe says they will 100% support flash on the desktop, but they said that not so long ago about flash on mobile devices and now they have dropped that support.Does nothing for us in regards to Android -- going forward-- /iOS.

Silverlight
Ok this one was to see who is paying attention... It was never a contendor, only older versions run of it on non MS platforms, and there is also the question of if it will be around in the future. MS has refused to commit to the future of Silverlight no matter how many times they have been asked.

HTML5
Well this is really HTML5, JavaScript, CSS, WebGL etc... This is only the front end, the back end would still have to be written in one of the above langues. And WebGL is still suffering some problems on some platforms, especially on mobile/tablet.


I could be wrong, but I think the above is a fairly accurate representation of where things are in regards to other cross platform choices. I can not see anything that makes me think, well you know maybe we should be using this language and toolset for MT instead.

Frankly, I really don't see the appeal of trying use Maptool on a mobile device(yes, I have an IPad, and mostly still prefer using my Laptop for most tasks,

I don't see much appeal with running MT on a tablet/phone -- I am sure several people will though -- one thing I think would be nice is if I could could connect to MT and run just certain parts, maybe the initiative on my phone that way I can turn off the init window and also the phone could alert me when its my turn -- some times its hard not to zone out when certain people spend 15 minutes describing what sort of boots they are wearing -- or even a character sheet and initiative on a tablet. So in this case I think the other device would be handy in conjunction with a PC. I could see the gaming table type setup with character sheets displayed on tables as being very handy.

though I LOVE my wife's(1st gen) Kindle for reading..

LIES!!!
No one likes the 1st gen kindle, I remember almost weeping when I got mine, it looks like some sort of weird alien surfboard for midgets, and was designed horribly, oh how many times did I curse that thing after accidentally turning the page because the next/last page buttons where exactly where you wanted to hold the thing. It was quickly relegated to the back of my cupboard in favour of the aging Sony eink reader I had before it.

Another consideration(which may very well be BS and never to appear), Oracle said several months ago that the were planning to try to create a "runtime" which would allow java code built for desktop (ie, Swing/AWT user interface) to be "auto converted" to use iOS's GUI.

Not quite, as part of JavaFX 2 (nothing at all to do with JavaFX Script, but the replacement for Swing) they have introduced a new rendering framework/pipeline. Because of they way they have abstracted the GUI they were able to very quickly get a prototype up and running where you could run JavaFX GUI programs on an iPad but just replacing a small part (this required bundeling a JRE with the app, I think it was a Java Micro Edition one). Their desire is to be able to run JavaFX GUI based programs on tablets -- and phones? -- who knows if it will bear fruit though as there are more than just technical challenges they have to overcome -- did I hear some one say Apple's approval process?

Also, don't forget HTML5. Currently, there are a lot of things that are done on the server (macro exectution, etc), but if we convert that stuff to the server, then it makes it much easier to write a slimmer client side interface. Frankly, I would see us pushing to HTML5 on the client side FAR more likely than anyone learning a new language.

As far as MT goes I completely agree with this statement. Other supporting tools who knows, but I would suspect that those that people will download and run on their machines would be Java and those that ran on the MapTools domain -- I doubt that the community portal/tool thingy would be written in Java for example -- would be written in something else. One nice thing is that JavaFX when it is available for all platforms does have a HTML renderer, it can't be used in all places such as buttons and tooltips like the current one, but it would be really nice to have HTML windows that can render current content.


Also to address another problem with mobile. Say that we did at some stage have RPTools written and supported tools on tablets and or phones. I am not saying that we will or we have even discussed it -- because we haven't discussed anything more than literally "wouldn't that be a nice feature to have phone or tablet support". There is the problem of resources and which platforms to support. I think both Android and iOS are no brainers, WP7 probably not, blackberry playbook ahahahahahaha.

I have no idea why anyone would still be reading this post, surely you have something better to do right? right?

The easiest to support platform would be Android simply because we could control when updates happen. For iOS, it can take weeks or months to get things approved and they can be knocked back for the oddest things, worse still just because a feature gets in doesn't mean on the next update your app won't get knocked back for that feature. Plus at the moment none of the code would be reusable since iOS apps are written in Objective C (at least with Android a lot of the non GUI desktop code would be usable). Already that sounds like a lot of extra work, so you know it may be better/easier to make it easy for other developers to create their own (partial) clients that can connect.

TL;DR what wolph42 said.

[CoveredInFish]

I have no idea why anyone would still be reading this post, surely you have something better to do right? right?

Because I can Still 15 minutes until I have to go to work ... so ...

no, thanks it is/was an interesting discussion and a good read.

[wolph42]

TL;DR what wolph42 said.

yeah I know I, my post can get a bit lengthy...

[jfrazierjr]

Frankly, I really don't see the appeal of trying use Maptool on a mobile device(yes, I have an IPad, and mostly still prefer using my Laptop for most tasks,

I don't see much appeal with running MT on a tablet/phone -- I am sure several people will though -- one thing I think would be nice is if I could could connect to MT and run just certain parts, maybe the initiative on my phone that way I can turn off the init window and also the phone could alert me when its my turn -- some times its hard not to zone out when certain people spend 15 minutes describing what sort of boots they are wearing -- or even a character sheet and initiative on a tablet. So in this case I think the other device would be handy in conjunction with a PC. I could see the gaming table type setup with character sheets displayed on tables as being very handy.

Exactly my point in my sentence after the one you quoted. I could totally see having CT on an tablet logged into a MT server instance over the network and the player using CT for the character management stuff (such as run attack macro X) and have that show up in the MT Chat. Of course, there would need to be some more stuff added to CT so allow for things like "showing list of available target tokens", etc but that is IMHO, a great scenario for a tablet and MT to "talk"(the map and movement stuff... not so much IMHO)

though I LOVE my wife's(1st gen) Kindle for reading..

LIES!!!
No one likes the 1st gen kindle, I remember almost weeping when I got mine, it looks like some sort of weird alien surfboard for midgets, and was designed horribly, oh how many times did I curse that thing after accidentally turning the page because the next/last page buttons where exactly where you wanted to hold the thing. It was quickly relegated to the back of my cupboard in favour of the aging Sony eink reader I had before it.

See... the button placement(and the HAVING of buttons is what I actually like about it. With an IPad + Kindle app, I am forced to use two hands (assuming I am holding in one hand rather than using some type of untouched holder piece of furniture/appliance) with the second hand being used to "swipe" to change page. The tactile response of a button is satisfying to me both because it only requires a single hand(the hand I am holding it with), as well as the actual "feel" of pushing a button....(perhaps I am just getting to old....)

Another consideration(which may very well be BS and never to appear), Oracle said several months ago that the were planning to try to create a "runtime" which would allow java code built for desktop (ie, Swing/AWT user interface) to be "auto converted" to use iOS's GUI.

Not quite, as part of JavaFX 2 (nothing at all to do with JavaFX Script, but the replacement for Swing) they have introduced a new rendering framework/pipeline. Because of they way they have abstracted the GUI they were able to very quickly get a prototype up and running where you could run JavaFX GUI programs on an iPad but just replacing a small part (this required bundeling a JRE with the app, I think it was a Java Micro Edition one). Their desire is to be able to run JavaFX GUI based programs on tablets -- and phones? -- who knows if it will bear fruit though as there are more than just technical challenges they have to overcome -- did I hear some one say Apple's approval process?

Also, don't forget HTML5. Currently, there are a lot of things that are done on the server (macro exectution, etc), but if we convert that stuff to the server, then it makes it much easier to write a slimmer client side interface. Frankly, I would see us pushing to HTML5 on the client side FAR more likely than anyone learning a new language.

As far as MT goes I completely agree with this statement. Other supporting tools who knows, but I would suspect that those that people will download and run on their machines would be Java and those that ran on the MapTools domain -- I doubt that the community portal/tool thingy would be written in Java for example -- would be written in something else. One nice thing is that JavaFX when it is available for all platforms does have a HTML renderer, it can't be used in all places such as buttons and tooltips like the current one, but it would be really nice to have HTML windows that can render current content.


Also to address another problem with mobile. Say that we did at some stage have RPTools written and supported tools on tablets and or phones. I am not saying that we will or we have even discussed it -- because we haven't discussed anything more than literally "wouldn't that be a nice feature to have phone or tablet support". There is the problem of resources and which platforms to support. I think both Android and iOS are no brainers, WP7 probably not, blackberry playbook ahahahahahaha.

And that is exactly why I was thinking HTML5 might be about the only remotely possible viable alternative. Yes, it has it's limitations, but compared to everything else short of writing targeted platform code, it offers the best chance of actually being able to execute "something" on pretty much all of the platforms. It also totally circumvents Apple's lockdown on app updates.

I have no idea why anyone would still be reading this post, surely you have something better to do right? right?

Well.. it's not like I have anything better to do, like say my job or something...

Already that sounds like a lot of extra work, so you know it may be better/easier to make it easy for other developers to create their own (partial) clients that can connect.

Yep, if we decide NOT to go down the HTML5 route, I would at least hope we would clean up/change the networking code (specifically the way objects are serialized) so that it's generic enough for an application built in any language could create objects of the appropriate type and have non RPTools people write clients in whatever language/OS they choose. Of course, there are tons of other things to nail down such as where to macros run(IMHO, we should switch to running on the server) and of course all this would be a TON of work...

[groveborn]

I seriously doubt anyone would do this, but an alternative to the current system is a VNC style client/server. Instead of having the mobile devices running their own maptools client, they simply connect to a socket built into the server which would send an image just like VNC would, except that it's private to the client connecting. I suppose this can already be done using VirtualBox... Probably a lot of work.

I have no idea what those requirements would be, in terms of the server, but I'm betting it'd be quick and easy to write the client side stuff (which is worthless without the far more complex server side!). I'd be surprised if this could even be done in Java. I'm no programmer.

Edit:
I like the idea of using a VM so much that I'm going to mess around with it and try it. If I get a modicum of usable success, I'll upload the machine. I'm going to use Puppy Linux, as it's cheap on ram and harddrive (thus downloading). I'll try to keep it as a minimalistic install, so it can just be for this specific purpose. I'll also post instruction on how to connect with IOS and Android, as I have access to both devices .

[Azhrei]

Well, you could just run VNC with different X instances on the server for each client. There are browser-based VNC clients (written in Java, I think) so no software would be needed client side.

But you're likely to need a pretty beefy server.

[groveborn]

Well, you could just run VNC with different X instances on the server for each client. There are browser-based VNC clients (written in Java, I think) so no software would be needed client side.

But you're likely to need a pretty beefy server.

Yeah, I haven't worked out the specific requirements yet...haven't even gotten anything streaming yet. Puppy doesn't like VNC very much. I might have to cave and use something with a larger foot print. That's unfortunate, being as it'll already require quite a bit of ram per instance.

On the other hand, just how many people in a single group would really want to run the thing on their phones? It's going to be wonky at best. If figure in a group of 6, only 2 would bother with a mobile device, the rest would either use a computer of their own, or else a shared system.

I just output to a tv with a second computer so everyone can see. They don't generally need to directly interact anyway.

All the same, I'll get this working. Or someone else will. Whatever.

[groveborn]

Ok, I've figured out a nice, easy method.

This requires Virtual Box, a free software.

Virtualbox > set up a new machine (or even reuse an existing machine!) > download Puppy Linux on ISO. Boot the virtual machine with the puppy linux iso in the "drive".

Navigate to quickpet (it's on the desktop) and install Java Runtime, and then go up to the menu at the top and choose more pets.

Search under the internet tab for Teamview Wine. Install.

Download Maptools.

Run Maptools.

Connect Maptools to your host (or wherever).

Run Teamview (it's in the menu under Internet).

Download Teamview for IOS or Android, and follow the prompts.

Poof.

If you make multiple instances of the virtual machine, you can have multiple phones/tablets connecting to your system. As mentioned above, it may slow your system down. You may be able to change resolution and colors at the phone/tablet side to reduce the lag.

Why Puppy Linux?
Because it's small, uses little ram, and has basically nothing in the install. It's also handy to have lying around in case you need to fix your computer.

What do you do when you're done?
You can either shut down the vm and save the session (it'll give you that option at shutdown), or else you can just save the state of the vm and be done with it. You'll need a virtual harddrive available for the first option. Just about any size over 256mb will work, so it doesn't really matter what size it is. You will need to format it, I'd use gparted for it. Fat/Fat32 works just fine.

There you go, have a happy game, on your phone.

This will even work at a friend's house, provided you have access to the internet. You can connect your phone to your home pc, if left running. . Yep, people don't have to share a single computer, if they don't wanna.