Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (775)
Games in Android Showcase (230)
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 3100 times)
0 Members and 1 Guest are viewing this topic.
Offline princec

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Posted 2018-08-22 21:54:31 »

So here I am after 20 years coding in Java without any problems... because it is basically one of the easiest platforms around to make stuff work with. Usually. Once upon a time.
Up till now it was just, java -cp <a bunch of jars> and maybe a -Djava.library.path and stuff worked. It really wasn't complicated. Compiling worked in the same way too. It is this very simplicity that has made java just so excellent for everyone and productivity in general. I use C at work on a day to day basis and I cannot describe just how much bullshit there is to making anything in C. It is literally insane - that is, no rational person would start out today trying to make the C toolchain behave the way it does. I spend days - actual whole, multiple days - just pulling my hair out trying to figure out what bullshit thing has gone wrong and how to fix it. Then I do a bit of java and it's all "ahh it just works, job done, move on".

Until, that is, today.

Today I decided to try and use JDK10 (OpenJDK10 to be precise), and OpenJFX11, which comes in the form of "jmods" as well as an SDK download.

Little did I realise as I poked my little nose into the rabbit hole how deep it would go.

The module system is just batshit insane. It is the most crazily over-engineered complex bollocks I've seen for a while, and it seems to have been designed by the sorts of people who enjoy tools like Maven and Gradle and J2EE. I don't think it really solves any problems and it creates so much complexity in using Java I just don't even know what to say.

So ... 20 years Java vet here, and I can't even f**king make Hello World run in JavaFX. I spent all day trying. Someone help me out. FWIW I'm using Eclipse Photon 4.8.

Cas Smiley

Offline mudlee

Junior Devvie


Medals: 6
Exp: 5 years



« Reply #1 - Posted 2018-08-22 22:00:45 »

Probably you have at least double years experience in java then I have, but for learning the new java modules for me the best was this course:
https://www.udemy.com/whats-new-in-java-9/

I tried to read lots of tutorials/docs, but all of them fail somewhere. This guy clearly explains everything, starting with jars on class path and sublime editor. This is my best recommendation for you.

I finished it yesterday and successfully migrated my tiny engine to java9, even solving automatic module jlinking stuff, so if you specify your problem, I might be able to help you too Smiley
Offline princec

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #2 - Posted 2018-08-22 22:06:55 »

So, bearing in mind the code has all actually compiled perfectly successfully, when I run it I get a single line of output:

Error: JavaFX runtime components are missing, and are required to run this application

All the JavaFX .jar files from OpenJFX are present in the classpath. I had it briefly working using the modulepath instead but there seemed to be some sort of weird problem with Eclipse and it would fail to run the second time so I've just reverted back to jars-on-the-classpath.

With the jars on the classpath, it's compiling just fine. At runtime though - derp. Just that one line of output.

Cas Smiley

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 #3 - Posted 2018-08-22 22:15:45 »

When using modules, you have to compile with module path kinda parameters, just almost the same as you used javac before. I really recommend to take a look on that course as before I thought the same about jigsaw, after I’m happy that java introduced it Smiley Also, it clearly explains the diff between the old way and the new way. Grab a beer and go watch it Smiley

If you wont succeed, I’ll create a javafx demo for you tomorrow, but without ecliose Smiley
Offline princec

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #4 - Posted 2018-08-22 22:17:56 »

Thing is I've actually got my head round the whole module-info.java thing. I successfully made a module out of my hello world and it ran. Once. Then Eclipse sort of got confused and it wouldn't work any more and I don't know why, which is why I've reverted to using jars on the classpath instead.

How do I get this crap working in Eclipse, properly, the way it's meant to work?


Cas Smiley

Offline princec

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #5 - Posted 2018-08-22 22:23:47 »

So, I just added a module-info.java thusly:

1  
2  
3  
4  
5  
6  
7  
8  
9  
/**
 *
 */

module hello {
   exports hello;

   requires javafx.base;
   requires javafx.graphics;
}

... and now it runs ok. However this module-info.java is located in the default package, not in the "hello" package which is where I was expecting it to have to be located. In fact I was expecting it to not work.

Cas Smiley

Offline princec

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #6 - Posted 2018-08-22 22:29:56 »

Eclipse suffered another funny turn when I tried to move module-info.java into the correct package location. Eventually I did it just using the system explorer and did a clean and build. So far so good. Still works.

... Noticed that Eclipse has now moved all my jars out of the project's classpath and into the modulepath instead, automatically. Gah. Fine.

To confound matters I now realise that I was using OpenJDK11 EA and not JDK10 as I first thought (accidental misconfiguration). I will now try it with OpenJDK 10...

<edit>Aaaaand... it's broken again.. Switched to OpenJDK10. Eclipse now says there's an error in module-info.java -  exports hello apparently is now an empty package. (That's where the HelloWorld.java lives, obviously). Clean/build doesn't fix it. Grr. Switch back to OpenJDK11....

Error: JavaFX runtime components are missing, and are required to run this application

I have no words.

Cas Smiley

Offline princec

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #7 - Posted 2018-08-22 22:48:05 »

Welp, it looks like most of the problems I'm having are that Eclipse is basically broken when it comes to modules.

If I put the module-info.java back in the wrong place - in the default package - everything settles down again (after having manually deleted the one in the right place and cleaning and building again because Eclipse throws a bunch of exceptions and doesn't work).

I am not filled with confidence. But at least... I've got OpenJDK10 now running OpenJFX11.

Cas Smiley

Offline Spasi
« Reply #8 - Posted 2018-08-22 23:49:21 »

If I put the module-info.java back in the wrong place - in the default package -

That IS the correct place, you can't put module-info.java anywhere but in the default package. There's a module per source root. If you need to work with multiple modules, then you need multiple source roots with a module-info.java in each one. You can't have a "hello" package and a "world" package under the same root and make those two different modules.

On Eclipse, my understanding is that they basically ignored Java 9 & 10 and are waiting for Java 11 - the first LTS release after Java 8 - to properly support modules. LWJGL users have reported all kinds of issues and for many months (before and after Java 9) module support was entirely broken. Even now you can't get LWJGL to work in a modular build (Bug 534624), will be fixed in 2018-09 M3 apparently.
Offline princec

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #9 - Posted 2018-08-22 23:56:43 »

I tried the Java 11 beta with Photon 4.9 M2 but it was even buggier so I've left that alone for now.

Explanations about the module-info.java are shall we say... mixed. But yes, thanks Spasi, you've confirmed my suspicions that it belongs in the root folder, and that's what's working. So a combination of massively overengineered design, totally broken IDEs, and misleading tutorials on the internet got me here. I've already come across the LWJGL issues too :| But it'll be nice when it works.

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline philfrei
« Reply #10 - Posted 2018-08-23 03:26:24 »

I couldn't get modules to work with Eclipse. This is why for the tutorial I just posted, I manually created the module structure and copied over the source. I don't know if NetBeans has done any better.

The sooner the IDE's get up to speed on this the better.

Looking forward to reading tutorial cited above by mudlee.

I suspect you don't actually need javax.base in your module-info, but it doesn't hurt to have it there.

A posting of info on setting up a project with OpenJFX 11 could be very helpful. Seems like there must have been quite a few gotcha's to create that much aggravation.

music and music apps: http://adonax.com
Offline orange451

JGO Kernel


Medals: 444
Projects: 7
Exp: 7 years


Your face? Your ass? What's the difference?


« Reply #11 - Posted 2018-08-23 03:45:23 »

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

First Recon. A java made online first person shooter!
Offline mudlee

Junior Devvie


Medals: 6
Exp: 5 years



« Reply #12 - Posted 2018-08-23 05:59:40 »

So many confusion here... Guys, the course I linked above, has a module system section, which takes you around 2hours to check. Like a good movie Smiley

But anyways, here are what I know:
  • You don't have to use modules. It's just an option
  • If you use modules, you can define strictly visibility for packages, even for reflections, which is really cool, I've programmed in Rust, C#, C++, PHP, Typescript, etc, but never seen a better solution
  • You can use it for services with ServiceLoader
  • As the whole JDK is now modularised, you can create your own JRE with jlink, ship your game with it without expecting the user having java. In my experience, I built a JRE that took 28MB only!
  • If you use modules, but one of your dependencies is not modularised, java handles it, and treats it as an "automatic module", which mean it will export all of its packages by default
  • You can't jlink automatic modules, but there is a solution for that, I wrote about it here: https://medium.com/@mudlee/java9-module-system-and-self-contained-apps-af26424fccae
  • Intellij IDEA supports modules, as maven

I see mixed feelings on the internet, but I see negative ones where the author has not checked it out in detail, how it really works. One who spent some hours to learn it just wrote positive thoughts on this (me too).
Offline Spasi
« Reply #13 - Posted 2018-08-23 06:52:25 »

Yes, IDEA works perfectly with modules and NetBeans also has full support since the recent 9.0 release. IDEA practically writes module-info.java for you (adds missing requires or even missing exports for inter-module dependencies) and any error messages are very clear. I don't think moving off Eclipse is an option for princec though, that's why I didn't mention it.

For Maven projects, I recommended the moditect plugin. Can be used to add custom module-info to non-modular libraries for jlink builds.
Offline Catharsis

JGO Ninja


Medals: 75
Projects: 1
Exp: 21 years


TyphonRT rocks!


« Reply #14 - Posted 2018-08-23 08:12:04 »

I pity the poor "fool" that hasn't been using Idea for the last 15+ years.  Grin

Check out the TyphonRT Video Suite:
http://www.typhonvideo.com/

Founder & Principal Architect; TyphonRT, Inc.
http://www.typhonrt.org/
http://www.egrsoftware.com/
https://plus.google.com/u/0/+MichaelLeahy/
Offline princec

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #15 - Posted 2018-08-23 08:54:57 »

Believe me I've tried to get into IntelliJ a few times but I'm just several times more productive with Eclipse. And besides we use Eclipse at work.

It is a shame the modules stuff is so broken after all this time - I thought I'd leave it a safe period before jumping in. It reminds me of the colossal clusterf*ck that Eclipse made of generics back in about 2005 ish which must have set a third of the Java developer base back by about 2 years in understanding generics.

Regardless, the whole module system is just daft. The problems 99% of developers had were almost entirely related to JDK licensing not technology. We had a complete game - with OpenGL and everything - packaged into just a 5mb, that had the entire JVM embedded into it. Or rather just the bits we needed. It was of course against the license, but it just goes to show. This was 15 years ago.

Quote
You don't have to use modules. It's just an option

Quote
Error: JavaFX runtime components are missing, and are required to run this application

So... boom. Yes, you do have to use modules.

Cas Smiley

Offline Catharsis

JGO Ninja


Medals: 75
Projects: 1
Exp: 21 years


TyphonRT rocks!


« Reply #16 - Posted 2018-08-23 09:34:21 »

I went from Visual Café to Idea and was relieved to find an IDE evolved from what I used before; I never spent much time w/ Eclipse. I haven't been in the Java space as far as proggy proggy goes for a few years, but will return for the 2nd gen Android video engine effort w/ LWJGL hopefully!  Cheesy!!  Re: your latter sentiment.. I can't comment on the official module system as of yet, but definitely don't discount the daftness possibility and agree that there "could have been" a streamlined way to expose the bare minimum + OpenGL long ago.

Check out the TyphonRT Video Suite:
http://www.typhonvideo.com/

Founder & Principal Architect; TyphonRT, Inc.
http://www.typhonrt.org/
http://www.egrsoftware.com/
https://plus.google.com/u/0/+MichaelLeahy/
Offline nsigma
« Reply #17 - Posted 2018-08-23 09:34:43 »

Yes, IDEA works perfectly with modules and NetBeans also has full support since the recent 9.0 release.

I remember playing with NetBeans support for modules almost 2 years ago - the transition to Apache was really done at the worst possible time in that regard.  And a lot of other stuff has only just been donated.  Still, it's getting there!  Smiley

Personally, having worked a lot with NetBeans, and the odd passing glance at OSGi, I like module systems a lot.  Not sure about Java 9+ modules though.  If anything it's under-engineered - missing some actually useful stuff.  And not sure whether it belongs at the core of the language.

Since the existence of OpenJDK there's not really been a licensing problem in shipping a slimmed down JVM in whatever way you see fit!

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

JGO Ninja


Medals: 75
Projects: 1
Exp: 21 years


TyphonRT rocks!


« Reply #18 - Posted 2018-08-23 09:49:29 »

"odd passing glance at OSGi"

Yep and yep... One of the years that I had a BOF selected (~'04) for JavaOne I attended an OSGi session that Peter Kriens was involved with and approached the fellow and asked if he was free for lunch; we then grabbed some food at the Metreon food court. At this time OSGi was just trying to break beyond a possible embedded use case into the Java mainline direction, so he was surprised of my interest. I never got around to figuring out how it could work for my efforts then and to now though was a bit bummed I suppose that from a design perspective the NIH syndrome created the module system that we have now for better of for worse...

Check out the TyphonRT Video Suite:
http://www.typhonvideo.com/

Founder & Principal Architect; TyphonRT, Inc.
http://www.typhonrt.org/
http://www.egrsoftware.com/
https://plus.google.com/u/0/+MichaelLeahy/
Offline princec

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #19 - Posted 2018-08-23 10:34:01 »

It is my undeniably contrary opinion that the whole mechanism should have been nothing whatsoever to do with the JVM or the Java language.

Cas Smiley

Offline nsigma
« Reply #20 - Posted 2018-08-23 10:41:17 »

It is my undeniably contrary opinion that the whole mechanism should have been nothing whatsoever to do with the JVM or the Java language.

Not contrary to me, certainly!  I disagree with you on module systems or Maven being complex bollocks in general (Gradle is obviously!  Wink ) Work with either long enough and the gains generally outweigh the pains.  But yes, Java 9+ modules do seem to introduce a massive amount of complexity without solving very much.

I am intrigued to know what adoption of modules is going to be like when Java 11 is finally out.

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

JGO Kernel


Medals: 636



« Reply #21 - Posted 2018-08-23 11:15:06 »

I can totally understand @princec's stance and I share it. Jigsaw or the Java 9 Module System is for modularizing the JRE and thus being able to only include the used parts of it in order to keep the footprint of a deployed application small, which is definitely a thing for cloud-based (micro-)services. But that's about it.
Java probably does not want to get left behind in the language/platform popularity fight when it comes to microservices or cloud services, where JavaScript with Node is apparently gaining kilometers every day. So, everything needs to be small, including the JRE.
But user applications already use other means for modularity, be it either a big folder of jar files or dependency management systems like Maven, Ivy or Gradle. So, Java 9's Module System does not help anything here. It just becomes a necessity iff you want to strip down the JRE, since then you need to declare and modularize your own application and express their JRE module dependencies as well.
As for myself, I (or any German customers I work for) is soooo many lightyears away from migrating into any cloud or microservice architectures, and everything is deployed on a big server either in-house or a single VPS from a data center with massive amounts of HDD, that it is never a concern whether the deployed application weighs in at 20MB or 200MB. That's why the Module System is currently completely ignored by me. Heck, most customers still run on Java 5, most on 7 and veeery few on 8. For the reason: It just freakin' works! Most don't even use Java but run COBOL on IBM mainframe systems, which work even better.

Also I NEVER understood the "we must strongly encapsulate the internal JDK classes even more" thing. Can someone please explain to me why the JDK classes and my application classes and all controlled dependencies - that I know I am using and what they are doing - must be shielded away from each other? When I use an internal API then this is freakin' my own decision/fault. Yes, of course I can --add-opens everything to everything, but why the hell is this not the default? Who needs to be protected from whom and why exactly? This is exactly the same as the SecurityManager which no one is actually using. Is anyone here using the Java SecurityManager? That was only invented to protect the user from running unknown and potentially malicious code they download from somewhere off the Internet and ran in an Applet. Has anyone actually done this? No one certainly does this today and everyone knows their dependencies. Java is not an "Internet Language" where everyone runs untrusted/unknown/insecure code all the time.
Offline mudlee

Junior Devvie


Medals: 6
Exp: 5 years



« Reply #22 - Posted 2018-08-23 11:53:58 »

Unfortunately I have to work in javascript/nodejs/typescript in my dayjob now, and what I see that because javascript and "doing it strict" are almost the opposite meaning, everyone does everything. Therefor I have to face with bugs, when one my dependency's dependency's dependency fails, because of a wrongly architected visibility/permission.
Of course, hacking was always been a habit, but nowadays it's getting more popular, especially in the mentioned field.

I might be too young with my 32 years and 15 years work experience, but I do love how strict the new module system is. And as its not obligatory to use, everyone will be happy. And I think, trying to stay on the track with other languages in today's development rush is good, because I don't want to see more nodejs applications on the server side then I see now Smiley

But this is my opinion only.
Offline h.pernpeintner

JGO Ninja


Medals: 106



« Reply #23 - Posted 2018-08-23 12:34:05 »

Disclaimer: My opinion too is, that the module system shouldn't have been introduced, at least not in the way it happened.

Also I NEVER understood the "we must strongly encapsulate the internal JDK classes even more" thing. Can someone please explain to me why the JDK classes and my application classes and all controlled dependencies - that I know I am using and what they are doing - must be shielded away from each other?
Ahhh common, you know why Cheesy Did you forget about unsafe? It's the best example why one wants to decide which classes one wants to expose from a module and which ones not.

Same for every other dependency that wants to give you an api and hide all implementations from you. Or if you operate on a platform where other people add their own modules. Once you work in such an environment, you learn to appreciate it, at least that's what I think about it. I think it's a typical problem that people tend to not understand as long as they don't have such a need to be solved. I also guess that there wouldn't be so much discussion about it if the module system would have existed since ever, because than, there wouldn't be any incompatibility/breaking changes thingies.

When I use an internal API then this is freakin' my own decision/fault. Yes, of course I can --add-opens everything to everything, but why the hell is this not the default? Who needs to be protected from whom and why exactly? This is exactly the same as the SecurityManager which no one is actually using. Is anyone here using the Java SecurityManager? That was only invented to protect the user from running unknown and potentially malicious code they download from somewhere off the Internet and ran in an Applet. Has anyone actually done this? No one certainly does this today and everyone knows their dependencies. Java is not an "Internet Language" where everyone runs untrusted/unknown/insecure code all the time.
Yes, I work for a company that uses it. But honestly I have no knowledge about it, I think we use it for file access restriction and reflection restriction.

Counter question: Do you always make all your fields public?Smiley Or your constructors, and never use factory facades? The answer is simply encapsulation. Not what against whom, but simply everything from everyone. It makes everything more reliable and reduces leaking of things.
Offline gouessej
« Reply #24 - Posted 2018-08-23 13:02:59 »

As the whole JDK is now modularised, you can create your own JRE with jlink, ship your game with it without expecting the user having java. In my experience, I built a JRE that took 28MB only!
It was already possible to create your own JRE without jlink before Java 1.9 and it was already possible to ship your game with a custom JRE before Java 1.9. Java 1.8 introduced some profiles and in the past, you could already take a binary build of OpenJDK and remove the "useless" stuff (nsigma already mentioned that more or less).

I find the module system a bit difficult to use and it's not enough reliably supported in the most major IDEs (Eclipse, Netbeans, ...) to encourage me to use it in my projects.

Some internal APIs will become impossible to use in a later release whereas there aren't any replacements for some of them. I stick with Java 1.8 for now.

Julien Gouesse | Personal blog | Website | Jogamp
Offline Abuse

JGO Ninja


Medals: 70


falling into the abyss of reality


« Reply #25 - Posted 2018-08-23 13:12:40 »

I'm not entirely clear on what the module system achieves?

Static class dependencies are automatically resolved at compile time & listed in the constants pool of each class.
Dynamic class dependencies (e.g. Class.forName(String) ) aren't made less fragile by this module system, you just get an extra layer of runtime errors.

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.

Is the sole gain just added security against versioning conflicts?
I honestly had no idea this even existed until I read this thread Smiley
Offline nsigma
« Reply #26 - Posted 2018-08-23 13:14:30 »

Is the sole gain just added security against versioning conflicts?

If only!  Versioning is one of the things I had in mind when I said it was missing a lot of things that would make it actually useful!   Wink

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

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #27 - Posted 2018-08-23 13:25:49 »

One of Java's great strengths was the ability to, if necessary, completely bypass the compile-time checks for access to stuff and get at it with reflection if you needed to. It is after all, your computer, doing your bidding. I don't see that someone should be allowed to say "no you can't see this" and actually have it strictly enforced by the JVM. It's my bastard machine, I'll do with it what I will. The 0.01% of users for whom this might be an issue should maybe have come up with some other solution that didn't involve buggering everything up for everyone else.

And as for modularisation... as @gouessej says, we've had a trivial solution for years. You just delete native binaries and remove packages from rt.jar until your JRE is small enough. It was trivial. I even had a utility which took the output from -verbose:class and automatically stripped everything else out of rt.jar to make it even more trivial. Until I just simply stopped bothering when bandwidth and disk space became effectively unlimited. All that really needed doing in this respect was a little moving around of classes to fix some odd cross-package dependencies that had been in the JDK base libraries for years.

As for the "exports" feature of the module system... would have been perfectly well served with a class annotation to suggest that classes were default hidden in code suggestions to IDEs. Then you can have a jar with all sorts of internal classes of no real interest to anyone else not cluttering up your ctrl-space suggestions list.

Cas Smiley

Offline KaiHH

JGO Kernel


Medals: 636



« Reply #28 - Posted 2018-08-23 13:32:18 »

Did you forget about unsafe? It's the best example why one wants to decide which classes one wants to expose from a module and which ones not.
No I have not at all forgotten about sun.misc.Unsafe, since like every freakin' library depends on it and I use it myself. This is the biggest question mark in my head: Why does everyone argue about Unsafe being bad and should never have been introduced and should be put behind ten meters of concrete. I completely do not get that. It always had a stable API (albeit undocumented, but who cared) and it served its freakin' purpose. But NO, Oracle/the JCP suddenly thought that eventually, Unsafe should be hidden away, which thankfully did not yet happen (even with the current JDK 12 EA), because everyone is relying on it and it never was an issue.
But noooo... we have to create object-oriented freakin' abstractions for half of the things Unsafe exposed in a much cleaner/direct way. VarHandles access to off-heap ByteBuffers, which will take Oracle months if not years to efficiently down-level to fast native code, so that it is not like 2x slower than Unsafe. So they decided to put massive amounts of effort into destroying what had already worked and trying to come up with unnecessary abstractions for it.
Offline h.pernpeintner

JGO Ninja


Medals: 106



« Reply #29 - Posted 2018-08-24 07:21:47 »

Beforehand, I would like to say again that I don't agree with the JPMS and all the unsafe stuff Smiley

No I have not at all forgotten about sun.misc.Unsafe, since like every freakin' library depends on it and I use it myself. This is the biggest question mark in my head: Why does everyone argue about Unsafe being bad and should never have been introduced and should be put behind ten meters of concrete.
You answer the question by yourself. It was and is a dangerous implementation detail that should be completely hidden from anyone. If it never had been accessible somehow, no core JVM framework would rely on it and we wouldn't have any problems now, because the problems never existed.

I completely do not get that. It always had a stable API (albeit undocumented, but who cared) and it served its freakin' purpose. But NO, Oracle/the JCP suddenly thought that eventually, Unsafe should be hidden away, which thankfully did not yet happen (even with the current JDK 12 EA), because everyone is relying on it and it never was an issue.
But noooo... we have to create object-oriented freakin' abstractions for half of the things Unsafe exposed in a much cleaner/direct way. VarHandles access to off-heap ByteBuffers, which will take Oracle months if not years to efficiently down-level to fast native code, so that it is not like 2x slower than Unsafe. So they decided to put massive amounts of effort into destroying what had already worked and trying to come up with unnecessary abstractions for it.

No, it never had an API. And it is no API. It is a mixed bag of different, partly totally unrelated things that don't conform to the rest of the Java platform.
Don't get me wrong: People's demands are totally right and understandable, we all have them. For example they want fast and unchecked direct buffer access. Then the answer is not Unsafe, but an official API with defined boundaries and with a common understanding. And this API won't give you the possibility to create an object instance without calling its constructor - if a demand for this feature is strong enough, this should be another official API, well designed and accepted by everyone.

Of course, since everything was f**ked up already, but worked extremely well, I tend to just leave it as it is and give people all the Unsafe. And if it wouldn't have been available all the time, maybe the JVM wouldn't be as strong as it is today, because people (really, not only officially) lacked features they sincerely want to have.

All that said, this is really just one example of why modules make sense: Encapsulation should be a decision of the writer, not the user.
Pages: [1] 2
  ignore  |  Print  
 
 

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

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

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

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

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

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

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

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

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

nelsongames (2009 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!