Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (778)
Games in Android Showcase (231)
games submitted by our members
Games in WIP (856)
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]
  ignore  |  Print  
  OpenJDK10, OpenJFX 11... wtf  (Read 3653 times)
0 Members and 1 Guest are viewing this topic.
Offline princec

« JGO Spiffy Duke »


Medals: 1060
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #30 - Posted 2018-08-24 09:03:42 »

Oh, I disagree about that. Encapsulation is a hint. The fact is, if there's code running on my computer, I want absolute and total control over that code. Most of Java's historical and entirely stupid, avoidable problems and massive overengineered are geared towards that one, utterly stupid decision to get Java to run as applets in browsers. All that security manager stuff... all that encapsulation... all that "no you can't have access to Unsafe because it's unsafe and you might hurt yourself"... all that refusal to just simply add a runtime flag to the VM to turn off bounds checking ... that was all borne of a totally pointless desire to attempt (and indeed, fail) to get signed or unsigned Java code to run in the browser.

Every other use case for Java's security mechanisms has been and still is and always will be a total, complete, waste of everyone's time. If I ruled the world right now I'd go through the whole of OpenJDK and remove every last scrap of code security from it. It has only ever been a massive hindrance to Java's adoption.

Cas Smiley

Offline nsigma
« Reply #31 - Posted 2018-08-24 13:17:39 »

All that security manager stuff... all that encapsulation... all that "no you can't have access to Unsafe because it's unsafe and you might hurt yourself"... all that refusal to just simply add a runtime flag to the VM to turn off bounds checking ... that was all borne of a totally pointless desire to attempt (and indeed, fail) to get signed or unsigned Java code to run in the browser.

That's not just about security though, it's about efficiency and provability of code.  It's another reason Java has been successful.  I'd rather Java adopted more from things like Rust than attempted to chase C/C++ down a rabbit hole.  Who needs a VM flag to turn off bounds checking when the VM can do that itself.

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline CommanderKeith
« Reply #32 - Posted 2018-08-24 13:20:20 »

I'm not entirely clear on what the module system achieves?
...
It seems like this explicit declaration of module dependencies is fragile data duplication that increases the manual overhead of maintaining a code base.
Moreover it seems like it's treading on the toes of packages, and jars.

I agree, the module system appears to be a gross duplication of permissions. In particular the need for explicit 'exports some.package;' for every single module's packages and sub-packages that are meant to be public. And then on top of that, any other module using that first module's packages must also declare that it 'requires firstmodule;' in its module-info.java file. Thank goodness, at least not every package needs to be explicitly required.

I actually couldn't believe the need for export statements so I checked out the jdk 9 source for the java.base module and yes, there's pages and pages of boilerplate export statements:

http://hg.openjdk.java.net/jdk9/client/jdk/file/65464a307408/src/java.base/share/classes/module-info.java

Here's some info on the export statement:
http://tutorials.jenkov.com/java/modules.html#module-exports

The idea of small custom JVM's and the ability to ditch bloated API's like AWT and Swing is fantastic. I suppose the module concept helped the JVM developers achieve this.

But for us consumers of the JVM, it's not clear how multiple layers of encapsulation security in the private/protected/public classes and fields and now the matching 'export' and 'requires' statements in multiple module-info.java configuration files achieves anything more than duplication. Or more accurately, triplication.

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

JGO Ninja


Medals: 106



« Reply #33 - Posted 2018-08-24 13:35:41 »

Hm, it makes me a little sad that the topic is discussed that harshly here. We're talking about modules and information hiding, and I thought it is generally accepted that it's better to be private to others by default. And explicitly open up things one wants to be an interface for others. Not agreeing on that makes a discussion some kind of hard - really reminds me of young programmers making everything public because who cares about visibility. Encapsulation and information hiding is key to reliable, safe software.

Also, I think we mix up things here. We have again a lively discussion about unsafe, which is just an example for something where it probably would have been better if it wasn't ever reachable for anyone (and I'm again, not saying that we shouldn't have the features like unchecked buffer access etc). And the security stuff doesn't relate to JPMS directly in the same way. If I write a module that runs in an environment at a customer, like modules from other third party companies, than my module shouldn't be allowed to write to their config directories. And I shouldn't be allowed to use reflection on the runtime and make everything accessible - simple as that.
Offline nsigma
« Reply #34 - Posted 2018-08-24 14:19:41 »

I agree, the module system appears to be a gross duplication of permissions.
...
But for us consumers of the JVM, it's not clear how multiple layers of encapsulation security in the private/protected/public classes and fields and now the matching 'export' and 'requires' statements in multiple module-info.java configuration files achieves anything more than duplication. Or more accurately, triplication.

Whether or not the module system should be in the JDK, it isn't a duplication of existing permissions.  You'll see the same mechanism in OSGi and the NetBeans module system, and maybe elsewhere.  And it's really useful!  There is no way within the private/protected/public system to define code that should work together but not be exposed as API across different modules.  Unless you use the horrible approach of splitting packages across modules / JARs, which is error prone and explicitly not supported by the JDK module system.  If you're writing an application framework or library (or JDK!) that has optional or OS specific parts this handles not exposing implementation details to the world.  It also allows you to have packages that serve multiple other packages in your API.

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline CommanderKeith
« Reply #35 - Posted 2018-08-24 14:26:00 »

Oh, I disagree about that. Encapsulation is a hint. The fact is, if there's code running on my computer, I want absolute and total control over that code.
I agree. I was reading a blog that proposed making fields and methods accessible as public by default rather than protected.
It wouldn't matter if this was implemented now anyway since this low level public encapsulation is over ruled in Java 9 and onward if the public method's class's package's module has no module export statement in its module-info.java.

Would be interesting to hear James Gosling's opinion about modules, but I can't find anything on Google.

Mark Reinhold outlines the laborious and tedious migration problems with modules here:
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-March/011763.html


Offline CommanderKeith
« Reply #36 - Posted 2018-08-24 14:38:37 »

Whether or not the module system should be in the JDK, it isn't a duplication of existing permissions.  You'll see the same mechanism in OSGi and the NetBeans module system, and maybe elsewhere.  And it's really useful!  There is no way within the private/protected/public system to define code that should work together but not be exposed as API across different modules.  Unless you use the horrible approach of splitting packages across modules / JARs, which is error prone and explicitly not supported by the JDK module system.  If you're writing an application framework or library (or JDK!) that has optional or OS specific parts this handles not exposing implementation details to the world.  It also allows you to have packages that serve multiple other packages in your API.
Ok, I see your point about there being no way of hiding things without modules. Some see strict encapsulation as a feature, but princec and I regard it as a pain in the neck. Means I have to copy your entire source code if I want to make some small change that you didn't foresee in your library.

There is still triplication of permissions to make a method public beyond the module. The method must be public, the method's module must export the package with an export statement in its module-info java file, and the module where I'm using the library's module must have a requires statement in its module-info.java. And I also have to include the library module in the module path when compiling and running the public method. Quite laborious for little gain in my opinion. Hopefully the tooling will eventually make it invisible.

Offline nsigma
« Reply #37 - Posted 2018-08-24 16:08:25 »

Ok, I see your point about there being no way of hiding things without modules. Some see strict encapsulation as a feature, but princec and I regard it as a pain in the neck. Means I have to copy your entire source code if I want to make some small change that you didn't foresee in your library.

Not necessarily, it means you have to do something explicit to depend on implementation details - eg. --add-exports or --add-opens.  This is a good thing!  It's not about disabling all access, just an obvious here-be-dragons, and a good pointer to the fact that it's probably going to break if you upgrade.  I have a number of native binding libraries that I maintain that have a lowlevel package where all the actual interaction with the native layer happens, and is definitely not intended to be a stable API.  No matter how much you tell people to keep their mitts off it, I'm still answering queries about breakage!  Wink

All encapsulation should be overridable by the consumer - I agree with you both there.  In fact, have been arguing that exact point in a review of the Apache NetBeans module system recently.  Explicit but possible is what I'm arguing for.

As for patching code, if that's what you mean rather than access, then absolutely that should be done and compiled with the whole source code IMO.

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline modernmarl

Innocent Bystander





« Reply #38 - Posted 2018-10-08 22:43:07 »

Does this mean I can't write simple applications and compile via old-fashioned terminal commands?

Offline whitewoodcity

Junior Newbie





« Reply #39 - Posted 2018-10-09 01:52:11 »

Oh, I disagree about that. Encapsulation is a hint. The fact is, if there's code running on my computer, I want absolute and total control over that code. Most of Java's historical and entirely stupid, avoidable problems and massive overengineered are geared towards that one, utterly stupid decision to get Java to run as applets in browsers. All that security manager stuff... all that encapsulation... all that "no you can't have access to Unsafe because it's unsafe and you might hurt yourself"... all that refusal to just simply add a runtime flag to the VM to turn off bounds checking ... that was all borne of a totally pointless desire to attempt (and indeed, fail) to get signed or unsigned Java code to run in the browser.

Every other use case for Java's security mechanisms has been and still is and always will be a total, complete, waste of everyone's time. If I ruled the world right now I'd go through the whole of OpenJDK and remove every last scrap of code security from it. It has only ever been a massive hindrance to Java's adoption.

Cas Smiley

java 11 has been modularized, so the whole jvm has been dispatched into small modules(in jmod format)
and javafx 11 is distributing their own jmods
so in order to use javafx 11, you have to integrate jfx jmods with default jmods to create you own customized jre
by using jlink tool
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline mudlee

Junior Devvie


Medals: 6
Exp: 5 years



« Reply #40 - Posted 2018-10-09 05:23:53 »

You can
Pages: 1 [2]
  ignore  |  Print  
 
 

 
hadezbladez (349 views)
2018-11-16 13:46:03

hadezbladez (183 views)
2018-11-16 13:41:33

hadezbladez (349 views)
2018-11-16 13:35:35

hadezbladez (85 views)
2018-11-16 13:32:03

EgonOlsen (2179 views)
2018-06-10 19:43:48

EgonOlsen (2221 views)
2018-06-10 19:43:44

EgonOlsen (1379 views)
2018-06-10 19:43:20

DesertCoockie (2012 views)
2018-05-13 18:23:11

nelsongames (1669 views)
2018-04-24 18:15:36

nelsongames (2309 views)
2018-04-24 18:14:32
Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45

Deployment and Packaging
by philfrei
2018-08-20 02:33:38

Deployment and Packaging
by philfrei
2018-08-20 02:29:55

Deployment and Packaging
by philfrei
2018-08-19 23:56:20

Deployment and Packaging
by philfrei
2018-08-19 23:54:46
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!