• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Series of Java OpenJDK 1.7 Questions.

 
Ranch Hand
Posts: 51
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have a series of Java questions that I wish to pose, probably for a person with a bit more experience within that technology domain.

-OpenJDK now comes with modules support.  Will a Java3D program, namely with a main method and in the requisite main method module,
still compile and run the same, with some other library, say, a 2D graphing library, such that the library was not built or compiled
with in any module,  but in an earlier version of java without modules?

-Why did Java even have to have a modules system, anyway?  Given that

-If I wanted a 3D Java library, as an alternative to Java3D 1.7, one that has more support for special effects, that is used in industry,
but approaches something like C++ OSG (Object Scene Graph), with many more options and powers that Java3D 1.7,
what comes recommended for Java?

-Java .class files and .jar files have always been very easy to decompile.  Excelsior Jet is now defunct, and older versions of that
will cease to be compatible with Java going into the future.  There is the Bisguard tool, which I am aware of.  Will
java likely ever be compilable into different binary OS files?  What can be done now to protect any of .class, .jar, .war, .ear classes?
May this area be likely improved into the future, and how?

-The JSTL, Java Standard Tag Library, part of the JSP, Java Server Pages system, has always been incomplete.  What
state is JSTL in nowadays?  Will anyone ever complete it, or likely?

-It has been suggested that Java may likely name mathematics operator overriding into the future, maybe within project
Valhalla.  I have plans on applying that upon so-called Arbitrary precision classes, either the default ones with Java
or those available through Open Source on the public internet.  Is Operator Overriding very likely to be put into openJDK in the future?

-There now is no longer any Java Applet system.  Will there likely be something in the future, that will run inside web browsers,
supporting something similar, or even better, into the future, for Java?

-I have always found that Java development for mobile devices is very tricky.  Particularly if you want to do something
like emulate the mobile phone environment in Netbeans, on a Desktop PC, as you program.  Is there a java android app
at the Google Play App store?  If I am against programming in the Android language for an Android smartphone, but
want to program in Java, how does Java for smartphones, presently, work, also given openJDK v 17?
If I want to combine the previous 3D Java library on Android or Windows smartphone software, how may one do that?


 
Saloon Keeper
Posts: 7585
176
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

If I wanted a 3D Java library, as an alternative to Java3D 1.7, one that has more support for special effects, that is used in industry,
but approaches something like C++ OSG (Object Scene Graph), with many more options and powers that Java3D 1.7,
what comes recommended for Java?


I don't follow 3D programming closely, but check out  JOGL.

The JSTL, Java Standard Tag Library, part of the JSP, Java Server Pages system, has always been incomplete.  What
state is JSTL in nowadays?  Will anyone ever complete it, or likely?


In which way is it incomplete that tag files or custom tags can't address?

It has been suggested that Java may likely name mathematics operator overriding into the future, maybe within project
Valhalla.  I have plans on applying that upon so-called Arbitrary precision classes, either the default ones with Java
or those available through Open Source on the public internet.  Is Operator Overriding very likely to be put into openJDK in the future?


Whoever suggested that is likely misinformed. Guy Steele, one of the principal architects of Java, has long ago stated that operator overloading/overriding was considred, but decided against wrt. Java.

There now is no longer any Java Applet system.  Will there likely be something in the future, that will run inside web browsers,
supporting something similar, or even better, into the future, for Java?


Various folks are working on making Java work with WASM: https://github.com/appcypher/awesome-wasm-langs#java

Is there a java android app at the Google Play App store?  If I am against programming in the Android language for an Android smartphone, but
want to program in Java, how does Java for smartphones, presently, work, also given openJDK v 17?


There is no such thing as the "Android language". If you're against using Java or Kotlin (which has some semblance of Java) you'll have a hard time on Android, unless something like Fluttr/Dart appeals to you.

If I want to combine the previous 3D Java library on Android or Windows smartphone software, how may one do that?


Android has OpenGL bindings, that's the main way to go with 3D programming.
 
Rancher
Posts: 326
14
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you fear someone steal your intellectual property (ip) don't publish any of it. If you fear stealing of credentials: Don't hard-compile credentials in your source.
If for any other reason: What's the point in obfuscation anyway? You're either business to business - it doesn't matter cause you just deny it in license terms - or business to customer: Have a look at pretty much any video game: All machine code can be reverse engineered back into readable source. Otherwise a computer wouldn't be able to run it.

Also: Don't even try anything with encryption. Even GTAV got cracked ... and it has quite some strong crypto. So, not even professionals are able to prevent their content gets abused - just accept it. If you fear it you're in the wrong industry.
 
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The purpose of modules was to extend and improve attempts that had been made with OSGi - keeping the internal details inaccessible and invisible to components that didn't need to access them and didn't need the extra complexity of knowing about them.

I don't believe in "copy protoction". Aside from the misleading name (you can usually copy just fine, whether you can use the copy or not), the more time and resources spent on making "impenetrable" software products, the less time and resources are going to be available for producing and supporting a quality product. Also, as Matthew has noted, DRM is frequently cracked - and it's often invasive to the point of annoying legitimate customers. As they say, locks are for honest people.

I try to avoid buying products packaged in "laceration packs" - my name for those hard moulded transparent packages which are so hard to open that you risk cutting through the product itself to get into and which result in jagged knives that could potentially literally sever tendons.

I don't shop at stores whose distrust for customers (and cashiers) is so high that you have to have your purchases inspected by a guard 5 feet from the register and 5 from the door.

I don't buy Nook books anymore, since the Nook DRM keys are no longer easily available and they encrypt even books which state explictly on their flyleaves that the book was sold without DRM (which is probably a violation of Barnes & Nobles' license from the publisher).

On the other hand, If I retire wealthy, it will be because I invested in companies like Red Hat, which absolutely refuses to bundle restricted-code systems in their products.

Yes, people will steal. But it has been proven time and time again that if you provide a good product at a price that customers deem reasonable, they'll gladly pay. Trying to squeeze those last dimes of profit out by adding barriers can cost more than it saves.
 
Bartender
Posts: 1737
63
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The title was very misleading.

I opened it wondering "Why can't this poor chap at least get on to Java 8??  Must have a lot of very old dependencies that are no longer maintained and have never been upgraded to even Java 8!"

The last version that used any form of Java 1.X versioning was 8/1.8, Java "1.7" was Java SE 7.

Java 9 is just 9, Java 11 is just 11, Java 17 is just 17.

-OpenJDK now comes with modules support.  Will a Java3D program, namely with a main method and in the requisite main method module,
still compile and run the same, with some other library, say, a 2D graphing library, such that the library was not built or compiled
with in any module,  but in an earlier version of java without modules?

-Why did Java even have to have a modules system, anyway?  Given that


Java 9, 10, 11, 12, 13, 14, 15, 16 all pretty much had total backwards compatibility.

With Java 17, there are certain dependencies on jdkinternals that someone sitting out all those versions without addressing them could have problems with.

There are ways around those issues, even now, that should have been addressed during one of the previous eight upgrades, both correct ways and hacky ways.

In general, .Jar files can be places on the --module-path and will be treated as "automatic modules".  An automatic module exposes all of its packages to every module on the module path that requires it, and can also be seen by code running in "the unnamed module" (on the --class-path).  More can be found in the Project Jigsaw and modules forum here...

Why did it even have to have a module system anyway?

It was in the works for a very long time before it came out in Java 9and was considered by many very overdue.

In no particular order:
1. Requiring the immense ball of mud rt.jar for every single Java program to run was ridiculously heavy weight.  All kinds of unwanted and unmanageable interdependencies was holding the platform back from evolution.  Every pre-Java-9 Java program was dependent on countless classes, exposing them to security risks and need of upgrade despite making no use of them, etc. etc. etc., there was no easy user-accessible way to build a custom JDK/JRE with just what you wanted...
2. Encapsulation was based on the package level.  Because all non-trivial Java programs consisted of countless packages, everything that needed to be accessed from any other package, including sub-packages and packages that contained them even, had to be made public, and could be accessed from any other code on the --class-path, whether it was intended to actually be public or was internal implementation.  This totally broke encapsulation and caused endless headaches when something outside became dependent on what was logically intended to be an internal implementation detail and therefore subject to change at the author's whim.  There was no way, prior to JPMS, to decide what to expose to whom, either by reflection or even directly.  This was all a horrible mess, and many people tried to partially solve this using Maven or whatever, which leads us to
3. Maven and other partial solutions couldn't be used for the JDK itself.  Also, if you work mostly in C++ you may be used to DLL Hell and consider it normal, but the fact that there was no higher-level organizational structure understood by the JVM beyond a mess of likely-incompatible and conflicting .jar files sitting on --class-path was a giant mess.  It was very easy to have logically invalid deployments that would only be noticed at run time.  There were no runtime checks that everything your program required was actually available in exactly one version (rather than three of them) on start up.  Searching the whole classpath for things was also very inefficient even in the absence of logical errors, there are good performance reasons for this that overlap a bit with #1

There's a bunch of others, but those are the three I would spit out on an interview without much time available.
reply
    Bookmark Topic Watch Topic
  • New Topic