I used jdk8 to compile my java program to use some latest feature.
Can JRE 8 be shipped before final release ?
Looks like JRE 8 is not available standalone.So can I ship JDK8 before it it's final release
JRE8 and JDK8 are currently in Early Adopter version (EA). It's license terms follow: http://www.oracle.com/technetwork/licenses/ea-license-152003.html
We grant You a revocable, nonexclusive, nontransferable, royalty-free and limited right to (a) use one (1) copy of the binary portions of the Programs and any Supplemental Programs for the sole purpose of internal non-production and non-commercial evaluation and testing of the Programs, including, developing no more than a single prototype of each of Your applications;
Now, of course, I'm no lawyer nor is this legal advice, but as this says, you can't ship a jre8 software (as that would include binary portions of jre8) to your production or commercial non-evaluation nor testing multiple non-prototypes of your application.
Additionally, you'd be subject to their Export Controls, found in the above address.
The GA is available as of March 18th:
http://www.oracle.com/technetwork/java/javase/downloads/index.html
Related
Some Win32 API function documentation (for example this and this) contains the following note:
Starting with TBD Release Iron, the behavior of this and other NUMA
functions has been modified to better support systems with nodes
containing more that 64 processors. For more information about this
change, including information about enabling the old behavior of this
API, see NUMA Support.
What exactly is the "TBD Release Iron"?
Which Windows versions does it support?
What modifications does the note refer to?
Elsewhere, for example on https://learn.microsoft.com/en-us/windows/win32/procthread/numa-support, it's called
Windows 10 Build 20348
In the same note.
So it looks like the folks at MSDN MS Docs Learn have some mass replacing to do.
As for the actual change, there now are (as is tradition) Ex methods for NUMA that add support for processor groups, allowing you to specify affinity for more applications running on machines with more than 64 logical processors, if I interpret it correctly.
"To Be Determined (TBD) release" means Microsoft has not decided exactly when this feature is going to be shipped. Iron is a branch codename. According to Betawiki, Iron was 21H1 and included Windows Server 2022.
Why Microsoft expects people to keep up with their internal codenames and if the changes have shipped and they just forgot to update the page to use the publuc name or if the feature/change has not shipped yet, I don't know.
The changes as compared with Windows 7 are listed under "Behavior starting with TBD Release Iron" on each page...
I want to know whether the official Java core API is part of JDK or JRE.
According to my understanding of Java, I think that the core API should be part of the JRE, as the application should be runnable without the additions provided by the JDK.
I also found some information on the web that says the 3 basic components of the JDK are,
Java Compiler
JVM
Java API
(As the JRE is the implementation of JVM, does the Java API belong to JRE or JDK?)
Edit: actual question: Is the Java API included in JRE?
Your facts are a bit inaccurate.
I also found some information on the web that says the 3 basic components of the JDK are: 1. Java Compiler, 2. JVM, 3. Java API.
That's not a good summary. There are certainly other things in a JDK apart from that.
As the JRE is the implementation of JVM
In fact the JRE includes an implementation of the JVM. And it also includes the core Java APIs, and a few other things.
As Holger points out, a JDK consists of a JRE plus some additional Java development tools. Or as he succinctly puts it:
"JDK = JRE + development tools"
So to answer your question:
does the Java API belong to JRE or JDK?
The Java APIs are included in both a JRE distribution or JDK distribution, but the phrase "belong to" doesn't have much meaning in this context.
(Now one could debate whether a JDK "contains" a JRE (or not), and whether the JRE "contains" the Java APIs. But to be honest it is a pointless debate. What really matters is that the Java APIs are present in both kinds of distribution.
Also, this is substantially moot in Java 11, since Oracle no longer provides JRE distributions for either Oracle or OpenJDK Java. It is now JDK only.)
A picture is worth a thousand words.
However, please note, the above diagram reflects the structure of JDK 8 and for later editions it is different.
I am quite confused as to the proper way of distributing Bonjour as a part of a Windows application that would publish a service for a client iOS app.
No matter how much I google around, I cannot find a clear how-to guide. It would be great if someone could provide guidelines.
The main reasons of my confusion are:
Is it mandatory to distribute the entire bonjour Win SDK as a part of my Win application?
Since Apple provides source code to build mDNSResponder.exe, is it sufficient to only distribute such file along with dns-sd.dll?
What is the intended purpose of providing sources for mDNSResponder.exe otherwise?
What is the recommended way to handle the possibility of having Bonjour already installed on the system?
Also, where can I find the latest Bonjour SDK (3.x I guess?), I can only find 2.0.4. Is it only accessible if I am enrolled in the OSX developer program? (I am enrolled in iOS developer program for now.)
Many thanks.
This is information I gathered from various sources, including communications with official Apple support. I report it in the way I believe to be accurate, I hope it can be useful (no liability assumed!).
For Bonjour-enabled Windows application you have basically two main options:
Bundle the Bonjour Installer with your application (which is not the Bonjour SDK, the SDK if for your own developer use only).
If you choose to do so, the Bonjour installer must be called from your own installer during the installation process. The possibility of Bonjour being already installed in the system is totally handled by the Bonjour installer.
And here come some bad news: you must include de Bonjour Logo on your physical distribution medium (like a DVD cover sleeve) according to the Apple guidelines specified in the Windows Bundling Agreement, and you need Apple approval before distributing your product.
Do not bundle. I.e., do not distribute Bonjour with your application but simply use it if already present in the system. If you do not distribute Bonjour in any form the whole Windows Bundling Agreement simply does not apply. You application should search for the dnssd.dll and load it dynamically if found.
Consider that most of Windows users would have Bonjour already installed due to the fact that some popular apps use it (for example iTunes and Skype).
While the source code of Bonjour is released under an open-source library (Apache License, Version 2.0) this does not require Apple to do anything. In particular, they do not need to document how you'd use this license.
The license allows you to use and adapt Apple's source code, including its copyright, but not including its trademark "Bonjour(TM)". Since this is the standard Apache license, you don't have the requirement either to show the trademark.
So, to answer your questions:
No, you can build your own version of Bonjour from source and use that under the Apache license. You can't call it Bonjour, but why do you need a name in the first place? "mDNS" would be a reasonable choice, possibly prefixed with your trademark.
It seems sufficient to distribute the DLL and EXE. Arranging how they find each other might benefit from some tailoring, so your own build of Bonjour doesn't clash with Apple's.
(I won't speculate on Apple's motives)
The design problem here is that Bonjour acts as a system service, and services are inherently singletons. If you install it unmodified, Apple wouldn't be able to install its own build. That's not a legal problem, probably, but it is a bad customer experience. Installing your own build as a distinct service would avoid the clash, allowing both versions to co-exist.
(Resource request, off-topic)
we use UrbanCode's AnthillPro build and CI server to build our C++ multi platform applications in a number of environments: linux, windows, solaris, hp-ux and aix. Yes, I know that AnthillPro was initially not designed to build C++ applications - rather for Java applications, but we've managed to make it do what we need :).
Now, UrbanCode belongs to IBM and it looks like they're about to discontinue AnthillPro. That's why we're now looking for an alternative solution.
The key features we appreciate in Anthill / expect to be supported by the new solution:
support of multiple C/C++ compilers (see above)
good and efficient dependency management and resolving
support of JavaC (very important in the future)
own "artifactory" / Anthill's CodeStation anologon
work distribution between build stations (Anthill's Agents concept)
logging and reporting tools (obvoius)
Can anybody recommend a solution, which complies to this feature list? If one or two features are not supported out of the box, but can be implemented with on-board tools or with help of unix' shell and other admin-tools, that's OK!
I've been debating whether or not to bundle a JRE with my application. I've listed some reasons below why I think it would be useful, but I'm also hesitant to do this because it makes the app much larger.
Why I think it would be useful:
Right now the app is run by running a batch file (well, a shortcut to a batch file, it is run via a batch file). It just calls java -jar XXX, which requires Java to be in the path, which is not always the case.
We're a small team and not fully running on Java 7 (there are some strange errors we are trying to debug still). If a user has Java 7, they may have an unpleasant software experience - this is not good for us. Packaging a specific version of the JRE ensure we've fully tested on it.
We support 32 and 64 bit Windows platforms. When the user downloads the software, they choose 32 or 64-bit, but this is asking which version of Java are they using. Most users don't know if 32-bit java is installed on their 64-bit platform, and it can be confusing to download 32-bit even though their OS is 64-bit.
There are some good reasons why not to package it though:
If a security hole is in Java or other significant updates are made to the JRE, we need to distribute a new version of our app with a new Java version. We are generally updating our app every couple of weeks, so I'm not too concerned about this one right now.
The app will now be much larger because it includes a packaged JRE.
Can anyone provide some guidance as to whether or not (based on these requirements) they think it is a good idea to package the JRE? If not, what are some alternatives to just hoping that java is in the path (and more importantly if it's not, it is possible our users may not know how to add it).
Java Web Start. The JRE will be on the path.
For version control, see Java Web Start - Runtime Versioning & particularly Earlier Version.
JWS can partition resources between a 64 bit & 32 bit JRE.
So, 'bad idea to bundle JRE'. Use web-start instead.
I would suggest to NOT bundle the JRE although I often see it as a common practice.
Instead I would either use webstart (can be used offline as well) or some other installer or pacakge manager solution that ensures that Java is installed including the correct version. This will widely depend on the operating system you expect to run on.
Going down the way of including Java begs the question what else you want to include, just to be sure... which will lead you to the whole operating system and everything needed thought to the end.
I would also suggest to closely look into what types of users will install the app and adapt to that and make some sort of estimate on how capable they will be.