Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (121)
games submitted by our members
Games in WIP (577)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Interfaces you'd like to see in the jdk  (Read 1430 times)
0 Members and 1 Guest are viewing this topic.
Offline i30817

Junior Duke





« Posted 2012-05-02 18:59:17 »

As we all know, there are plenty of good ideas that would be nice to have standardized, but don't get even get a time of day because it never would get implemented in the jdk (and maybe they shouldn't).
Still, i think it's a good idea to have a well thought out interface (as if that was possible without 3 prior implementations!), so as to subtly pressure the library authors to support it, so you can change tools.

I've got a "hate-hate-love" relationship with this stuff, because it inevitably ossifies and leaks, but it does sometimes allow to change implementations. Exe:
JAXP, corba, java speech api etc.

Still, i've recently thought it would be nice to have a "bug report" interface, so that i could use a library that would report to my project google page bugs on uncaught exceptions and filter duplicates with the stacktrace.
Such a simple interface would be nice encouragement for library writers.

Do you have any such jdk interface longings?

//is there any library that does this stuff for google code?
Offline sproingie

JGO Kernel


Medals: 202



« Reply #1 - Posted 2012-05-02 19:08:11 »

I'd like to see them focus on the JVM and leave library design to people who are better at it.  Other than jdbc, java.util.concurrent and a few collections classes (but not all), I'm hard pressed to think of anything bundled with the JDK that I don't tend to prefer a third-party implementation for.  Not sound, not GUI, not XML processing, not logging ...
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 818
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #2 - Posted 2012-05-03 04:22:08 »

Regardless of who is better at it, I think it's most important that whatever you include in the JVM has to be supported forever and is basically feature frozen.

Adding a new JAR to the classpath is so easy that you'd wonder why there is even a demand for adding libraries to the JVM.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Evil[1]

Senior Newbie


Medals: 1



« Reply #3 - Posted 2012-05-03 05:53:41 »

java.lang
java.math
java.sql
java.util
java.net
Offline lhkbob

JGO Knight


Medals: 32



« Reply #4 - Posted 2012-05-03 05:59:56 »

java.io
maybe java.nio

Offline Roquen
« Reply #5 - Posted 2012-05-03 08:51:55 »

Regardless of who is better at it, I think it's most important that whatever you include in the JVM has to be supported forever and is basically feature frozen.
I serious dislike these kinds of notions. Lucky (IMHO) there are moving in the opposite direction and modularizing and versioning the various libraries and making it non-monolithic.  Backward compatible is preserved (which I assume is your real motivation) without forever & ever handcuffing future versions.  If you don't like a newer version of something, you can always specify the specific previous version you want to utilize.

Pretty much everything I want is at the VM level, which would need to be exposed at both the language and library level.

Examples:
  • VM support of structures with library structures that expose SIMD operations.
  • VM support of concrete arrays with operations which expose caching hints

For java in the wider sense:

  • Mutable primitive wrapper classes (I'm still at a loss why we've never had this.)
  • High level IR framework (scripting languages, runtime compiling, ease other languages on JVM).
  • Lots and lots of contracts via metadata (annotations)

Offline princec

JGO Kernel


Medals: 409
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #6 - Posted 2012-05-03 09:07:49 »

The only ones I think that should be part of the JVM are java.lang, java.math, java.io, java.nio, java.net and java.util and their subpackages. Those are the bare basics to make a VM work with whatever language may actually be on top of it all. It might be nice if they ditched all the legacy deprecated methods and classes one day and drew a line in the sand for backward compatibility - after all it's trivial to rewrite and recompile Java code to use newer methods.

When I chopped the VM down back in 2003 ish I got the entire thing down to a 2.5mb payload (1.4.2 Hotspot client) capable of running fully featured games. I asked Sun a lot about licensing such a VM but apparently there was so much political red tape involved in actually doing so it never happened. I fear there was an opportunity missed.

Cas Smiley

Offline nsigma
« Reply #7 - Posted 2012-05-03 09:28:57 »

When I chopped the VM down back in 2003 ish I got the entire thing down to a 2.5mb payload (1.4.2 Hotspot client) capable of running fully featured games. I asked Sun a lot about licensing such a VM but apparently there was so much political red tape involved in actually doing so it never happened. I fear there was an opportunity missed.

Of course, with OpenJDK there wouldn't be any political shenanigans about doing this.  But are many people doing that now? 

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Offline Roquen
« Reply #8 - Posted 2012-05-03 09:34:53 »

From the hand-waving future directions stuff I've seen that seems to be exactly the direction that they're intending on moving in.  No more multiple JVMs (from Oracle).  Just HotSpot with various different components depending on if it's ME, SE or EE.  How is not clear (conditional compile or broken into shared libraries).  On the classpath side, no more monolithic single version (forever backward compatible), but broken into chunks (granularity is unclear) which are versioned.  It seems logical that the minimum required to execute would be a single chuck...but stuff isn't always logical to me.

Quote
Of course, with OpenJDK there wouldn't be any political shenanigans about doing this.  But are many people doing that now?
I don't see how this really changes anything (for the moment), unless there as been some licensing changes of which I'm unaware.  But (again from hand-waving papers) addressing the issue of minimal embedded (from a distribution standpoint) is one of the stated reasons for the above moves.
Offline nsigma
« Reply #9 - Posted 2012-05-03 09:41:16 »

Quote
Of course, with OpenJDK there wouldn't be any political shenanigans about doing this.  But are many people doing that now?
I don't see how this really changes anything (for the moment), unless there as been some licensing changes of which I'm unaware.  But (again from hand-waving papers) addressing the issue of minimal embedded (from a distribution standpoint) is one of the stated reasons for the above moves.

Because as long as you keep it GPL w/CPE you can strip it down as much as you want!  And use it wherever you want as well for that matter.  Interesting side note - GPL cannot have field of use restrictions - so if Android had been forked off OpenJDK there wouldn't be a problem.  Just can't call it Java.

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Pages: [1]
  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.

theagentd (19 views)
2014-10-25 15:46:29

Longarmx (52 views)
2014-10-17 03:59:02

Norakomi (46 views)
2014-10-16 15:22:06

Norakomi (34 views)
2014-10-16 15:20:20

lcass (39 views)
2014-10-15 16:18:58

TehJavaDev (68 views)
2014-10-14 00:39:48

TehJavaDev (68 views)
2014-10-14 00:35:47

TehJavaDev (60 views)
2014-10-14 00:32:37

BurntPizza (74 views)
2014-10-11 23:24:42

BurntPizza (45 views)
2014-10-11 23:10:45
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

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